Changing the DNSSEC algorithm

Mon Apr 11 07:33:19 UTC 2022

Hi,

BIND 9.16 has dnssec-policy that makes algorithm rollover much easier. I 
recommend you start using that.

Read more on migrating to dnssec-policy here:

   https://kb.isc.org/docs/dnssec-key-and-signing-policy

Best regards,

Matthijs

On 06-04-2022 21:47, Danilo Godec via bind-users wrote:
> 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:pemensik at redhat.com
>> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>>
> 
> -- 
> Danilo Godec | Sistemska podpora / System Administration
> AGENDA d.o.o. | Ul. Pohorskega bataljona 49, Sl-2000 Maribor
> E: danilo.godec at agenda.si | T: +386 (0)2 421 61 31 | F: +386 (0)2 420 06 90
> Agenda OpenSystems <https://www.agenda.si/> | Največji slovenski 
> odprtokodni integrator
> Red Hat v Sloveniji <http://www.redhat.si/> | Red Hat Premier Business 
> Partner
> ElasticBox <http://elasticbox.eu/> | Poslovne rešitve v oblaku
> Agenda d.o.o. <https://www.agenda.si/>
> Izjava o omejitvi odgovornosti / Legal disclaimer statement 
> <https://www.agenda.si/index.php?id=228>
> 
> 