BIND 9.16 引入了一项新dnssec-policy功能，作为对长期建立的功能的进一步自动化的 DNSSEC 密钥管理和签名工具auto-dnssec maintain。
该文档似乎没有涵盖从旧的迁移到新的，但相关的 wiki 页面似乎表明已经存在的密钥将被dnssec-policy.
也就是说，设置一个新区域dnssec-policy很简单，但是将现有区域从 迁移auto-dnssec maintain到dnssec-policy似乎并不像人们预期的那样工作。
我所期望的是与现有密钥兼容的策略将继续使用这些密钥。
似乎发生的情况是，所有现有密钥都立即从区域中删除，因为它们已经“过期”并被新密钥替换，即使新策略要求一组兼容的密钥（相同的算法和大小）并且现有密钥具有未定义生命周期结束的属性（仅.key 文件中的Created,Publish和Activate时间）。
我在测试时使用的策略如下所示（命名以反映测试期间的内容）：
dnssec-policy alg13-ksk-unlimited-zsk-60day {
keys {
ksk key-directory lifetime unlimited algorithm ECDSAP256SHA256;
zsk key-directory lifetime P60D algorithm ECDSAP256SHA256;
};
};
这是配置从更改为时的日志auto-dnssec maintain;输出dnssec-policy alg13-ksk-unlimited-zsk-60day;：
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
可以看出，现有密钥立即被删除（甚至没有遵循正常的翻转程序！）并替换为相同类型的新密钥。
考虑到只是立即更换密钥而不是遵循预期的翻转过程会破坏一切，显然简单地将配置切换到dnssec-policy是不行的。
查看密钥文件，我注意到一个附加.state文件与旧密钥和新密钥并排添加。
我不知道这个文件是否需要以dnssec-policy某种方式正确操作？事先创建这些文件会以某种方式避免这种行为吗？
其核心问题是：有没有办法以dnssec-policy非破坏性方式迁移到使用？如果是这样，怎么做？
问题中描述的行为是一个错误，应该从 BIND 版本 9.16.2 开始解决。
来自BIND 9.16.2 发行说明：