Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)
Mark Andrews
marka at isc.org
Tue Jan 25 01:48:09 UTC 2022
> On 25 Jan 2022, at 11:55, egoitz at ramattack.net wrote:
>
> Hi Mark!!
>
>
>
> Thank you so much for your answer!! and your time!!.
>
>
>
> I have a couple of questions. I ask them between your lines and in blue for instance... for emphasizing and being easier to see what I'm referring to. I'm talking about ZSK keys in the questions I am asking in blue.
>
>
>
>
> El 2022-01-25 00:36, Mark Andrews escribió:
>
>>
>> How 'named' manages DNSSEC is very different to how 'dnssec-signzone' manages DNSSEC. When you tell named to
>> inactivate a DNSKEY it stops re-signing the zone with it and it stops signing new records added to the zone
>> with it.
>>
>>
>> The fact is, I don't tell named nothing really. It maintains the zone signatures (I'm using inline-signing yes; auto-dnssec maintain; per zone). I just provide it keys and then I wait, until the ZSK key's delete time arrives, then I remove it's files (.key and .private). I don't wait until the inactive time. I wait until the delete time (not the inactive time). After the delete time of the key, can still records (rrsigs) exist signed with that key then?.
Yes.
>> It DOES NOT immediately replace all RRSIGs generated using that key. Those records will be replaced
>> over the sig-validity-interval as they fall due for re-signing. Once all those RRSIG records have been
>> replaced and they have expired from caches, you can then delete the DNSKEY record.
>>
>> With the default sig-validity-interval (30) that takes up to 22.5 days to which you have to add the record TTL.
>>
>> Ok, but does sig-validity-interval affect too, after the key deletion date?. Or does it affect only from the inactivation date to the deletion date of a key?.
sig-validity-interval and re-signing is independent of inactive and delete dates.
>> Mark
>>
>>
>> Best regards
>>
>>> On 25 Jan 2022, at 05:21, egoitz--- via bind-users <bind-users at lists.isc.org> wrote:
>>>
>>> Hi!!
>>>
>>>
>>>
>>> Thanks a lot for your answer!!
>>>
>>>
>>>
>>> I tried before the fact of renaming back and rndc sign... but does not work.... just has removed the error from the log....
>>>
>>>
>>>
>>> I have changed my key managing code, for not renaming to "-OLD" the ZSK (.key and .private) until have passed at least 2 days from the deletion time... Let's see if this way works better....
>>>
>>>
>>>
>>>
>>> Any more ideas mates?.
>>>
>>>
>>>
>>> Thank you so much for your time :)
>>>
>>>
>>>
>>> Best regards,
>>>
>>> El 2022-01-24 17:51, Tony Finch escribió:
>>>
>>>> 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.
>>>>
>>>> egoitz--- via bind-users <bind-users at lists.isc.org> wrote:
>>>>>
>>>>> 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
>>>>
>>>> Yes, it can be confusing when the state of the key files doesn't match the
>>>> state of the zone.
>>>>
>>>> I think you said you have renamed all your key files back to their usual
>>>> non-OLD names. Good; that is necessary if named is still looking for a key
>>>> file even if it shouldn't need it any more.
>>>>
>>>> Then, try running `rndc sign <zone>`, to make named reload the keys. I
>>>> think that should also get it to make whatever updates might be necessary.
>>>>
>>>> Then look at the logs to see if there are errors, and look at the DNSKEY
>>>> RRset (with its RRSIGs) to make sure it matches what you expect.
>>>>
>>>> If that doesn't get things straightened out then, um, dunno :-)
>>>>
>>>> I guess it is possible to get into a muddle if you try to move a key out
>>>> of the way very soon after its delete time. By default, named does key
>>>> maintenance infrequently, so I guess if you move the key after its
>>>> deletion time but before the next key maintenance cycle, things will get
>>>> out of sync. But I have not checked whether my guess is right or not.
>>>>
>>>> Tony.
>>> _______________________________________________
>>> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the bind-users
mailing list