Re: Changing the DNSSEC algorithm
I read several articles regarding algorithm rollover, including: * https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html * https://downloads.isc.org/isc/bind9/9.16.6/doc/arm/html/advanced.html#dnssec-dynamic-zones-and-automatic-signing Unfortunately I can't find all of them in my browser history... For re-signing I have a Bash script running once a month through cron. With only a few zones to manage I think I'll stick with the simple way of editing them by hand. Thanks for your thoughts, Danilo On 6.4.2022 13:18, Petr Menšík wrote: Hi Danilo, I think the way you have describe should work. But can I ask what source this recipe has? I have seen recently similar signing in one of our test. I guess this should be from public recipe. Would you share its origin, please? I would recommend having DNS server do the job of maintaining signatures. If you do it this way manually, you have to resign your zone each time your signatures expire. Do you have set some kind of reminder to remind you? I would try DNSSEC guide [1] with bind 9.16 or more recent. It provides a policy inside named. It depends on what version do you have. Even 9.11 can maintain signatures [2] and resign them, but the process is more complicated. You would have to just regenerate keys, otherwise it will maintain your signatures. But yes, it won't be able to edit zone file by hand this way. Read dnssec-settime manual page and way to set times, when each key should be activated or deactivated. It should be more safe if done the right way. You can use dnssec-signzone -S to use smart signing and then omit step 2. Just provide correct directory to keys. But I admit it might be simpler to do it manually if you would upgrade just single zone, which has no high impact in case of error. Btw. it seems really clumsy to read 1000 characters from proper entropy source and then use just 16 hexcoded chars from it. /dev/urandom might be better source and 16 bytes should be enough. Regards, Petr 1. https://bind9.readthedocs.io/en/v9_16_27/dnssec-guide.html 2. https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/Bv9ARM.ch04.html#dnssec.dynamic.zones On 4/5/22 09:07, Danilo Godec via bind-users wrote: Hello, I implemented DNSSEC for my personal domain a good while ago with an older Bind and back then, I used RSASHA1-NSEC3-SHA1 algorithm, which by now is not recommended... So I'm going to change the algorithm, probably to ECDSAP256SHA256, which should also be NSEC3 capable. Since my domain is small and rarely changes, I'm not using any fancy updating features - I manage it manually, by editing the non-signed version of the zone file and then signing it to create a signed version. 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 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 4. ask the registrar to add new DS record to TLD (I have to do this by mail, there is no 'self-service' UI) 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) 7. wait another TTL period 8. remove old keys from zone 9. re-sign the zone Will that be OK? Best regards, Danilo -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB --
Re: Changing the DNSSEC algorithm
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
Re: Changing the DNSSEC algorithm
Hi Danilo, I think the way you have describe should work. But can I ask what source this recipe has? I have seen recently similar signing in one of our test. I guess this should be from public recipe. Would you share its origin, please? I would recommend having DNS server do the job of maintaining signatures. If you do it this way manually, you have to resign your zone each time your signatures expire. Do you have set some kind of reminder to remind you? I would try DNSSEC guide [1] with bind 9.16 or more recent. It provides a policy inside named. It depends on what version do you have. Even 9.11 can maintain signatures [2] and resign them, but the process is more complicated. You would have to just regenerate keys, otherwise it will maintain your signatures. But yes, it won't be able to edit zone file by hand this way. Read dnssec-settime manual page and way to set times, when each key should be activated or deactivated. It should be more safe if done the right way. You can use dnssec-signzone -S to use smart signing and then omit step 2. Just provide correct directory to keys. But I admit it might be simpler to do it manually if you would upgrade just single zone, which has no high impact in case of error. Btw. it seems really clumsy to read 1000 characters from proper entropy source and then use just 16 hexcoded chars from it. /dev/urandom might be better source and 16 bytes should be enough. Regards, Petr 1. https://bind9.readthedocs.io/en/v9_16_27/dnssec-guide.html 2. https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/Bv9ARM.ch04.html#dnssec.dynamic.zones On 4/5/22 09:07, Danilo Godec via bind-users wrote: > > Hello, > > > I implemented DNSSEC for my personal domain a good while ago with an > older Bind and back then, I used RSASHA1-NSEC3-SHA1 algorithm, which > by now is not recommended... So I'm going to change the algorithm, > probably to ECDSAP256SHA256, which should also be NSEC3 capable. > > Since my domain is small and rarely changes, I'm not using any fancy > updating features - I manage it manually, by editing the non-signed > version of the zone file and then signing it to create a signed version. > > > 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 > > > 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 > > > 4. ask the registrar to add new DS record to TLD (I have to do this by > mail, there is no 'self-service' UI) > > 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) > > 7. wait another TTL period > > 8. remove old keys from zone > > 9. re-sign the zone > > > Will that be OK? > > > Best regards, > > Danilo > > > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- 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
Re: Changing the DNSSEC algorithm
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 -- 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
