Hi Mark!!!
Thanks again!!!. Very very thankful really. Please allow me to answer
you something more as we found a guru here :) :)
But then Mark, what does a key deletion time of a key mean?. I
understood that when the deletion time was overtaken in a ZSK, the key
dissapeared from the DNSKEY and so... it should not exist RRSIGs with
that ZSK (because that RRSIG could not become validated with a valid/in
effect ZSK) key because all should have been renewed between the key
inactive time and the delete time. I assume I am wrong then. I read the
ARM and understood that. What I'm missing or what I have misunderstood
if you are so kind as to clarify me?.
By the way, when you say "sig-validity-interval and re-signing is
independent of inactive and delete dates" I understand but I assume,
then I don't have clear the concept of "key delete time", because I
thought that sig-validity-interval and the fact of re-signing, was just
applied to in effect keys.
I would be very thankful if you could help me clarifying the delete time
of a key then... I'm going to try to do it by my own, reading the ARM
relevant parts again too...
As said before, extremely thankful Mark :)
Regards,
El 2022-01-25 02:48, Mark Andrews escribió:
> On 25 Jan 2022, at 11:55, ego...@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@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@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
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