Updating a DNSSEC config to use a different algorithm

Matthijs Mekking matthijs at isc.org
Tue Feb 2 09:23:12 UTC 2021

On 01-02-2021 17:34, @lbutlr wrote:
> On 01 Feb 2021, at 07:14, Matthijs Mekking <matthijs at isc.org> wrote:
>> Depends on what your DNSSEC configuration is. Are you using
>> dnssec-signzone/named? auto-dnssec maintain? inline-signing?
>> dnssec-policy? dnssec-keymgr?
> These are all good questions, and when I set this up I could have
> answered with some degree of confidence.
> What I have in named.conf is simply dnssec-validation auto; and
> domains have auto-dnssec maintain, so I guess that answers that
> question.
>> Yes there are a lot of ways to maintain DNSSEC in BIND. The
>> recommended way forward is to use dnssec-policy. Migrating to it
>> may still be a bit tricky*, but once you use it, changing a new
>> signing algorithm is pretty simple:
>> 1. Update your dnssec-policy, reload config.
> Assuming there is no dnssec-policy (there is not) what would I update
> it to?
> This did give me enough to DDG on, does this link look reasonable?
> <https://serverfault.com/questions/1007899/how-to-migrate-bind-configuration-to-dnssec-policy-from-auto-dnssec-maintain-wit>
>  #v+ dnssec-policy alg13-ksk-unlimited-zsk-60day { keys { ksk
> key-directory lifetime unlimited algorithm ECDSAP256SHA256; zsk
> key-directory lifetime P60D algorithm ECDSAP256SHA256; }; }; #v-

If you switch to dnssec-policy, before you change your algorithm you 
have to migrate the old keys.

You can use two methods:

1. Create a dnssec-policy that matches your current keys (so in your 
case algorithm 7, also make sure you use the same length).

So I guess something like:

     dnssec-policy alg13-ksk-unlimited-zsk-60day {
         keys {
             ksk key-directory lifetime unlimited algorithm 7 2048;
             zsk key-directory lifetime P60D algorithm 7 1024 ;

This is an assumption. Check the key length with your existing keys.

2. You can also initialize the key states manually with dnssec-settime:

Key state options:
     -s: update key state file (default no)
     -g state: set the goal state for this key
     -d state date/[+-]offset: set the DS state
     -k state date/[+-]offset: set the DNSKEY state
     -r state date/[+-]offset: set the RRSIG (KSK) state
     -z state date/[+-]offset: set the RRSIG (ZSK) state

dnssec-settime -s -g OMNIPRESENT now -d OMNIPRESENT now \
     -k OMNIPRESENT now -r OMNIPRESENT now <kskfile>
dnssec-settime -s -g OMNIPRESENT now -k OMNIPRESENT now \
     -z OMNIPRESENT now <zskfile>

It is a bit technical, but this would make your existing key files ready 
to for dnssec-policy. Use this if your zone is correctly signed at the 
moment, and the DS is in the parent for some time.

Algorithm rollover:

Now that you have migrated your existing key files (they will now have a 
.state file), you can reconfigure your dnssec-policy with a new 
algorithm,. The alg-7 keys will be gracefully removed from the zone, 
while new keys with a new algorithm will be introduced.

> If so, what are the possible values for the algorithm? And for the
> actual policy (alg13-…)? I also see mention of a dissed-policy
> default but that is out of context so I don't know if that is simply
> telling the domain to use the policy defined separately in the the
> named.conf as above. Alg13-ksk gives two hits on DDG, and the second
> one is in Japanese.

Algorithm 13 (ECDSAP256SHA256) is a good choice. It is becoming best 
practice, it is as popular as algorithm 8 (RSASHA256)*, and the majority 
of resolvers can validate with this algorithm**

* https://stats.dnssec-tools.org/
** https://blog.apnic.net/2018/08/23/measuring-ecdsa-in-dnssec-an-update/

>> 2. Wait a little bit. 3. When the new DS is in the parent, run
>> "rndc dnssec -checkds published on the right key id." 4. Also run
>> "rndc dnssec -checkds withdrawn" on the id of the key that has its
>> DS removed from the parent. 5. Have a celebratory drink.
> Way ahead of you there! 🥃
>> *In principal you can just switch to dnssec-policy with your
>> existing key files and BIND will initialize key state files for
>> those keys. But there is at least one known bug that deleted keys
>> may be used again for signing (those deleted keys still have their
>> key files in the key directory). [GL #2406]
> Hopefully that will not be an issue as there are no old key files. Or
> rather they are all about the same age of Jan-Feb of 2019,

This bug affects key files that exist but have their "Inactive" and/or
"Delete" timing metadata in the past.

Best regards,


More information about the bind-users mailing list