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