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,
Matthijs
More information about the bind-users
mailing list