我们知道 ICANN 计划于 2026 年 10 月 11 日正式启用新的 DNS 根区密钥签名密钥 KSK-2024，以完成对 KSK-2017 的轮换。如果你在管理启用 DNSSEC 功能的递归服务器，你可能需要关注一下实际生效的根信任锚里是否已经存在 KSK-2024（Key Tag 38696）。

DNSSEC 与 KSK 密钥

关于 DNSSEC，不得不先区分两个概念：

• KSK（Key Signing Key）：用于签署所在区域的 DNSKEY 记录集。对于 DNS 根区而言，根 KSK 是验证解析器建立 DNSSEC 信任链的起点，也就是根信任锚。
• ZSK（Zone Signing Key）：用于对区域中的普通记录集进行签名，通常比 KSK 轮换得更频繁。

本次轮换的是 DNS 根区 KSK，不是日常轮换的 ZSK。所以本次影响的主要是启用递归功能且开启 DNSSEC 验证的服务器。或有些程序内置了 DNS 根信任锚时，才需要进行本次检查。

DNSSEC 通过数字签名，让验证解析器判断 DNS 数据是否真实、完整，以及是否在传输过程中被篡改。它的信任链从根区开始：解析器首先信任根区，再由根区验证顶级域，随后逐级验证下级域名。

2026 年 10 月 11 日，KSK-2024 将开始签署根区的 DNSKEY 记录集，同时 KSK-2017 将停止承担这项签名工作。新密钥的 Key Tag 为 38696。在 IANA 的轮换时间表中，这一天被列为 rollover 日期。

RFC 5011

对于主流 DNS 服务组件，均以支持 RFC 5011 自动信任锚更新机制。早在 2025 年 1 月 11 日 KSK-2024 就已经进入 DNS 根区，正常工作的 DNS 服务组件在结束 30 天保持期后，从 2025 年 2 月 10 日起就应当自动接受并信任这把新密钥了。

KSK 切换后，如果 DNS 服务组件仍然只信任 KSK-2017，就无法验证由 KSK-2024 签署的根区 DNSKEY 记录集。信任链会在根区断裂，查询结果通常表现为大量 SERVFAIL。由于已有缓存和 TTL 的存在，故障一般不会在切换瞬间同时爆发，但可能随着缓存陆续过期逐渐扩大。

ICANN 的警告很明确：如果 DNSSEC 验证解析器没有配置 KSK-2024，所在网络可能出现全面的 DNS 解析失败。

切换前 checklist

我们列举了一些常见的 DNS 组件 如何检查 KSK。

BIND

开启 dnssec-validation auto 时，BIND 会走 managed-keys 自动维护信任锚。可查看：

rndc secroots
或：
rndc managed-keys status

如果输出里包含 key id = 38696，说明 KSK-2024 已经被接受。

信任锚文件通常位于 /var/cache/bind/managed-keys.bind 或 /var/named/managed-keys.bind，也可以直接 grep 确认：

grep -i "38696\|KSK-2024" /var/cache/bind/managed-keys.bind

PS：如果你使用的是静态 trusted-keys 配置，而不是 managed-keys/dnssec-validation auto，RFC 5011 自动更新不会生效，需要手动把 KSK-2024 加到配置里。

Unbound

Unbound 使用 auto-trust-anchor-file 指向 root.key。可查看：

unbound-anchor -l

或在配置中查看 root.key 路径：

grep "auto-trust-anchor-file" /etc/unbound/unbound.conf
unbound-anchor -l -a /var/lib/unbound/root.key

如果信任锚文件里没有 KSK-2024，可尝试手动更新：

unbound-anchor -a /var/lib/unbound/root.key

Knot Resolver

Knot Resolver 默认通过 RFC 5011 自动维护信任锚，缓存在运行时数据目录中（如 /var/lib/knot-resolver/）。检查方式：

kresctl -s /var/run/knot-resolver/control.sock trust-anchors

具体命令取决于版本和 socket 路径。

用 dig 直接验证根区 DNSKEY

无论使用哪种解析器，都可以先向根服务器确认 KSK-2024 是否已在根区发布：

dig +dnssec . DNSKEY @a.root-servers.net

现代版本的 dig 输出中通常会标注每把密钥的 key id，如果看到 38696 且为 257 类型（KSK），说明根区已经携带这把新密钥。

应急处理

如果检查后发现信任锚里确实没有 KSK-2024，可采取以下措施：

1、升级 DNS 软件到支持 RFC 5011 的最新稳定版

2、将 dnssec-validation auto 或 auto-trust-anchor-file 等自动更新机制打开

3、手动更新信任锚文件，或从 IANA DNSSEC 信任锚页面 获取最新 XML

4、切换前在测试环境验证 DNSSEC 验证结果是否正常，避免直接上生产

参考文档

• Root Zone KSK Rollover - ICANN
• DNSSEC Trust Anchors - IANA
• RFC 5011 - Automated Updates of DNS Security (DNSSEC) Trust Anchors