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
