On 6.4.2022 8:52, Daniel Stirnimann wrote:
Hello Danilo,

A simple schema to change DNSSEC algorithms is as follows:

1. Add new KSK/ZSK and double sign DNSKEY and all zone RRs
    with both the new and old algorithm
2. Replace DS at parent
3. Remove old DNSKEY and all RRSIGs from the old algorithm

Before step 2 wait the max zone TTL to expire.
Before step 3 wait the DS TTL to expire.

Here I'd like to verify that I understand the steps required to change
DNSEC key / algorithm without disruption:


1. create new keys for my zone

   * dnssec-keygen -a ECDSAP256SHA256 -n ZONE mydomain
   * dnssec-keygen -f KSK -a ECDSAP256SHA256 -n ZONE mydomain


2. include new keys in my zone while keeping old keys too:

     $INCLUDE Kmydomain.+008+14884.key         <- old key
     $INCLUDE Kmydomain.+008+27618.key         <- old key
     $INCLUDE Kmydomain.+013+10503.key         <- new key
     $INCLUDE Kmydomain.+013+39532.key         <- new key

Looks good to me.


3. sign the zone file

     /usr/sbin/dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum
| cut -b 1-16) -e +3024000 -o mydomain -t mydomain.hosts

Not related to the algorithm rollover but you may want to reconsider the
use of NSEC3 using opt-out, the use of NSEC3 salt or the use of NSEC3
all together. Please have a look at:

https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-nsec3-guidance

This is currently an IETF dnsop working group document.


4. ask the registrar to add new DS record to TLD (I have to do this by
mail, there is no 'self-service' UI)

As you use a Double-Signature [1] KSK roll, you can replace the DS
record in a single step. While your procedure does not break anything it
does not need to be more complicated then necessary. You description is
a mix of the Double-Singature / Double-DS KSK rollover.

I would suggest you go directly to step 5 instead and in step 6 you
*replace* the DS record.


5. wait at least one TTL (making sure to use the longest TTL in my zone)

6. ask the registrar to remove old DS record(s) (I don't quite remember
why, but I had two)

As mentioned above, in step 6 you can *replace* the DS record.


7. wait another TTL period

You need to wait at least for the DS TTL to expire.


8. remove old keys from zone

9. re-sign the zone

Looks good to me.


Daniel


[1] https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.1.2


Thank you, it seems I was close enough (it would've worked).


I read the draft-ietf-dnsop-nsec3-guidance and while it's a bit above my level of understanding, I think the gist is that one should not use 'advanced' NSEC3 features like iterations and salt - achieved by setting NSEC3PARAM to 1 0 0 - .


    Regards,
      Danilo


--
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

Reply via email to