I think the problem is that if you do a : 

dig +multi @dnssecserver thedomain.thetld dnskey +dnssec | grep 44526 

You then see still that key id exists in DNSKEY records (and an RRSIG of
that ZSK, the 44526, but outdated!!!!). 

But I don't really understand why because you see the delete date of
44526 is very old.... 

Anyway that could explain the error : "dns_dnssec_keylistfromrdataset:
error reading .........private: File not found", because it seems Bind
source code, checks the DNSKEY and later tries to load that keys. As the
files for keyid 44526 don't exist, that could (are renamed) that could
explain the error. 

But why has this happened??. Sometime ago, it happened to me that in
this machine (it's more than nothing a learning machine), the ZSK got
outdated because the script in charge of renewing the zsk was stopped.
So the only supposed valid key could have been in that moment the KSK
(which does not get expired). Could perhaps, those ZSK become
everlasting or similar, although in the file the date sais it's totally
outdated.... 

I can't understand what's happening there... 

Regards,

El 2022-01-24 15:04, ego...@ramattack.net escribió:

> In fact... in a domain for whom I have seen these errors, it's arguing about 
> key id 44526 (it's private file) saying "File not found". But if I perform an 
> axfr request of the signed zone with pipe grep the key id, no matches 
> appear... so should not exist rrsigs for that key.... 
> 
> These are the contents of a cat of the private file I have renamed to 
> samename.private-OLD : 
> 
> Created: 20211031230338
> Publish: 20211110220241
> Activate: 20211110220341
> Inactive: 20211215230338
> Delete: 20211217230338 
> 
> Not understandable.... 
> 
> Cheers,
> 
> El 2022-01-24 14:58, egoitz--- via bind-users escribió: Hi Klaus, 
> 
> Thank you so much for your answer but when Bind deletes a key from a zone, if 
> I remember correctly, there should not be any rrsig still active, signed 
> previously by the deleted key. Isn't it?. So I assume in that case, I should 
> be doing it properly but still see these messages. 
> 
> Am I wrong Klaus in some statement?. If a ZSK is deleted (I'm not renewing 
> KSK at the moment) no RRSIG with that key should exist... 
> 
> Cheers!
> 
> El 2022-01-24 13:08, Klaus Darilion escribió: 
> 
> IIRC, Bind needs the key as long as there are signatures in the zone 
> generated by this key. After key deactivation I waited the RRSIG lifetime 
> before deleting them. 
> 
> regards 
> 
> Klaus 
> 
> VON: bind-users <bind-users-boun...@lists.isc.org> IM AUFTRAG VON egoitz--- 
> via bind-users
> GESENDET: Montag, 24. Jänner 2022 13:00
> AN: bind-users@lists.isc.org
> BETREFF: Bind 9, dnssec, and .key .private files physical deletion after the 
> key id becomes deleted from zone (the key becomes outdated) 
> 
> Good morning, 
> 
> I have a DNSSEC "bump in wire" server, which uses "inline-signing yes;"  and 
> "auto-dnssec maintain;" for that reason. 
> 
> I do the task of ensuring always are valid keys in the zone with an script 
> that generates them whenever is needed. All fine until here and all working. 
> 
> I have seen, that Bind logs in messages log file sometimes the following 
> error logs : 
> 
> _dns_dnssec_keylistfromrdataset: error reading 
> /xxx/xxx/xxx/xx-domain/named.aaa/aaa.xx.+008+41919.private: file not found_ 
> 
> That "file not found" is due to a rename of ".key" and ".private" files to 
> ".key-OLD" and ".private-OLD". 
> 
> I did the rename, because I have seen that the ZSK key 41919 was set to be 
> deleted (and obviously always renamed after that deletion date) from the 
> zone, so I renamed the ".key" and ".private" files to ".key-OLD" and 
> ".private-OLD". 
> 
> I do this rename, because this way my key checking script differentiates, any 
> needed (in effect) key with the "supposedly" (I say supposedly because I 
> would have said that Bind should not be using nowadays that non finding files 
> for nothing!) non needed keys, in order to check that each zone, has always 
> the needed keys for keeping properly signed by Bind (else it would generate 
> them). 
> 
> As I previously commented, I check with a script the existence of all needed 
> keys for each domain. Obviuosly, it's not the same checking a couple of ZSK 
> or just one ZSK and a KSK (per domain), than them plus all outdated keys that 
> each month become outdated. 
> 
> So, how many time should I wait in order to rename that files?. Should I 
> handle them with another dnssec-______ command instead of renaming?. All 
> seems to be working well but I see these errors and was wondering if I could 
> improve the way of handling outdated keys. 
> 
> I have been taking a look at the source code of Bind (the tag of version I'm 
> using), and I have seen that Bind seems not remove any of that key files when 
> they become outdated. Or does it with some param?. I have not been able to 
> find it. I have been taking a look too the ARM, but still no luck on finding 
> the answers I was trying to. 
> 
> Any help very appreciated, 
> 
> Best regards, 
> ATENCION
> ATENCION
> ATENCION!!! Este correo se ha enviado desde fuera de la organizacion. No 
> pinche en los enlaces ni abra los adjuntos a no ser que reconozca el 
> remitente y sepa que el contenido es seguro.
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users 
> 
> ATENCION: Este correo se ha enviado desde fuera de la organización. No pinche 
> en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y 
> sepa que el contenido es seguro.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to