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, ego...@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, 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