Changing the DNSSEC algorithm
Matthijs Mekking
matthijs at isc.org
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>
>
>
More information about the bind-users
mailing list