Non-disruptive migration to dnssec-policy possible?

Matthijs Mekking matthijs at
Wed Mar 25 13:03:21 UTC 2020

Hi Håkan,

First of all, thanks for trying out the new dnssec-policy feature.

I'll admit there is insufficient documentation and tooling around
migration to dnssec-policy, possibly there is a bug too.

Existing keys do not have a .state file, and so named will try to match
those keys with the policy by looking at the data in the .key and
.private files. However, perhaps some metadata is different? If so the
keys don't match the policy and named will try to replace them (I
suspect the DNSKEY TTL is different).

You can use the dnssec-settime tool to write the state file, but it is
more intended to be a method for debugging and testing.

It is odd that it immediately deletes the existing keys. I would like to
follow-up on this. Would you be able to rerun the experiment with the
dnssec log category set to debug? That way we can see what the internal
keymgr decided about those keys.

If so, could you create an issue for it on our GitLab repository?

There exists a system test that tests this case and it passes, so either
or test is wrong, or your setup uncovers a scenario we did not anticipate.

Thanks for reporting, best regards,


On 3/25/20 12:53 PM, Håkan Lindqvist via bind-users wrote:
> Hello,
> 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
> (
> does not appear to cover this this scenario and the DNSSEC Guide
> ( does not
> mention dnssec-policy at all.
> However, the wiki
> (
> 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:
> Created:
> Publish:
> Activate:
> 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?
> Regards,
> Håkan Lindqvist
> _______________________________________________
> Please visit to
> unsubscribe from this list
> bind-users mailing list
> bind-users at

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the bind-users mailing list