Updating a DNSSEC config to use a different algorithm

[@lbutlr]

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

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

-- 
'I don't see why everyone depends on me. I'm not dependable. Even I
	don't depend on me, and I'm me.'