I have seen essentially this same question/problem posed by others in other forums but never seen any proper answers to it. I have now tried this myself with BIND 9.16.1 and faced the exact same issue that I had previously read about.

How does one migrate an already signed zone from "auto-dnssec maintain" to "dnssec-policy x" in a non-disruptive manner?

The manual (https://ftp.isc.org/isc/bind9/cur/9.16/doc/arm/Bv9ARM.ch05.html#dnssec_policy_grammar) does not appear to cover this this scenario and the DNSSEC Guide (https://ftp.isc.org/isc/dnssec-guide/html/dnssec-guide.html) does not mention dnssec-policy at all.

However, the wiki (https://gitlab.isc.org/isc-projects/bind9/-/wikis/DNSSEC-Key-and-Signing-Policy-(KASP)#key-generation) appears to suggest that existing keys would be picked up.

With that in mind, one might naively think that switching to a keytype-compatible dnssec-policy should be safe, but in practice it appears to be anything but.

Eg existing KSK+ZSK algo 13 keys seem like they could (and arguably should) be carried over to a policy mandating KSK+ZSK and algo 13 (particularly if the policy has unlimited lifetime for the key, but even with limited lifetime one would hope that the regular rollover timers would be applied).

In practice when you change the zone configuration to use dnssec-policy, all existing keys are immediately yanked and replaced with new keys. No timers or anything seem to matter.

This is what my own test looked like:

Existing  KSK+ZSK keys with only these timings present in the .key files:


And a policy like this (named to reflect what is what while testing):

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

And this is the log output when first loading BIND after changing the configuration to use that dnssec-policy:

zone zone.example/IN (signed): reconfiguring zone keys
keymgr: DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) created for policy alg13-ksk-unlimited-zsk-60day keymgr: DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) created for policy alg13-ksk-unlimited-zsk-60day
Removing expired key 20481/ECDSAP256SHA256 from DNSKEY RRset.
DNSKEY zone.example/ECDSAP256SHA256/20481 (ZSK) is now deleted
Removing expired key 12506/ECDSAP256SHA256 from DNSKEY RRset.
DNSKEY zone.example/ECDSAP256SHA256/12506 (KSK) is now deleted
Fetching zone.example/ECDSAP256SHA256/49004 (KSK) from key repository.
DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) is now published
DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) is now active
Fetching zone.example/ECDSAP256SHA256/54646 (ZSK) from key repository.
DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) is now published
DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) is now active
zone zone.example/IN (signed): next key event: 22-Mar-2020 15:08:19.805

As can be seen, it immediately deleted the existing keys, claiming that they were "expired".

One could argue that the ZSK certainly was old enough to be expired (even though I would still maintain that it must do a proper rollover starting from now rather than just yanking the key), but the KSK policy was "lifetime unlimited" and nothing about end of life in the existing .key file. How can such a key even be "expired"?

I did notice that the key files (both old and new) also got a corresponding .state file created as part of this process. Is that relevant to the problem? Ie, do existing keys need this file to be used properly, if so is there tooling to generate these?

Any suggestions?

Håkan Lindqvist

Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list

Reply via email to