Hi Mark!
Very thankful again for your time. Sorry for answering so late, but I
was not at the office yesterday. I answer below in blue for instance...
El 2022-01-27 02:56, Mark Andrews escribió:
> DNSSEC involves lots of timing / co-ordination points and if any of them get
> delayed for any reason the
> following ones also need to be delayed. While dnssec-keygen will allow you
> to set all of the timers for
> all of a keys life, it is bad practice to do that.
>
> But as I have read in Michael Lucas book, it's recommended to refresh at
> least ZSK keys from time to time. For that purpose... it's required to set
> the needed date and times... isn't it?.
>
> If you are going to set the timers like this there needs to be much more time
> between the inactivation time
> and the deletion time.
>
> I see, so first and required value of sig-validity-interval <= deletion time
> - inactivation time then ?.
>
> As I said earlier about 30 days with default values for
> sig-validity-interval.
>
> This is the reason by which I have deduced the formula written above...
>
> Thanks again Mark!!!!
> Cheers!!!!
>
> Mark
>
> On 25 Jan 2022, at 18:46, ego...@ramattack.net wrote:
>
> Hi!!
>
> Don't really know if it could help, but I generate the ZSK keys this way :
>
> /usr/local/sbin/dnssec-keygen -3 -a 8 -b 1024 -P now -A now -I +45d -D +47d
> _____________
>
> Cheers!!
>
> 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
