AW: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)

[egoitz at ramattack.net]

If you return the -OLD files to it's before name (without -OLD) and you
make changes to the zone or perform rndc loadkeys of the zone, error
dissapear but still the DNSKEY become outdated.... 

Any ideas mates?

El 2022-01-24 16:12, egoitz at ramattack.net escribió:

> 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, egoitz at 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-bounces at lists.isc.org> IM AUFTRAG VON egoitz--- via bind-users
> GESENDET: Montag, 24. Jänner 2022 13:00
> AN: bind-users at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220124/8d16c0a4/attachment.htm>