如何在不中断的情况下将 BIND 配置从 auto-dnssec 维护迁移到 dnssec-policy？

Question

BIND 9.16 引入了一项新dnssec-policy功能，作为长期建立的功能的进一步自动化的 DNSSEC 密钥管理和签名工具auto-dnssec maintain。

该文档似乎没有涵盖从旧版本到新版本的迁移，但相关的 wiki 页面似乎表明dnssec-policy.

也就是说，建立一个新区域dnssec-policy非常简单，但是将现有区域从 迁移auto-dnssec maintain到dnssec-policy似乎并不像人们预期的那样有效。
我所期望的是与现有密钥兼容的策略将继续使用这些密钥。

似乎发生的情况是，所有现有密钥都会立即从区域中删除，因为它们已经“过期”并被新密钥替换，即使新策略强制要求一组兼容的密钥（相同的算法和大小）并且现有密钥已未定义生命周期终止属性（仅Created、Publish和Activate.key 文件中的计时）。

我在测试时使用的策略如下所示（命名以反映测试期间的内容）：

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

As can be seen the existing keys were immediately deleted (not even following the normal rollover procedure!) and replaced with new keys of the same type.
Considering that just instantly replacing the keys instead of following the intended rollover procedure breaks everything, it's apparent that simply switching the configuration to dnssec-policy is a no-go.

Looking at the key files, I note that an additional .state file is added side by side with both the old and the new keys.
I don't know if this file is a requirement for proper dnssec-policy operation somehow? Would having these files created beforehand somehow avoid this behavior?

The question at its core is: is there a way to migrate to using dnssec-policy in a non-disruptive manner? If so, how?

Answer 1

问题中描述的行为是一个错误，应从 BIND 版本 9.16.2 开始解决。

来自BIND 9.16.2 发行说明：

Bug修复

[剪]

• 当尝试将已签名的区域从自动 dnssec 维护迁移到基于 dnssec 策略的区域时，现有密钥立即被删除并替换为新密钥。由于未遵循关键的轮转时间限制，因此某些客户端可能无法验证响应，直到所有旧 DNSSEC 信息从缓存中超时。BIND 现在查看现有密钥的时间元数据，并将其合并到其 DNSSEC 策略操作中。[GL#1706]