Cloudflare 详解 10 月 11 日 DNS 根 KSK 轮换：如何检查解析器是否信任 KSK-2024

2026年10月11日，DNS 根区计划进行历史上仅第二次的密钥签名密钥（KSK）更换。该密钥是 DNSSEC 信任链的锚点，使 DNS 解析器能够使用加密签名验证应答。这一更换称为 KSK 轮换。验证型解析器需要在切换前信任新密钥，否则原本正常的网站可能变得无法访问。

当我们在2018年撰文介绍首次根 KSK 轮换时，我们曾看到解析器在软件升级或跨机器迁移过程中丢失对新密钥的学习信任。提前发布密钥只是工作的一部分。我们还需要知道解析器是否保留了该密钥，而当时我们无法为用户提供实用的检查方法。

大多数网站运营者无需为此次轮换做任何更改。如果你运行 DNSSEC 验证型解析器，请检查它是否信任新的根密钥 KSK-2024，如果密钥缺失，请按照软件供应商的说明更新其信任锚。 如果你使用 Cloudflare 为你的域名提供 DNS 服务，或依赖 1.1.1.1 和 Gateway DNS，则无需采取任何操作——我们的系统已经信任 KSK-2024。

要提前检查，请访问我们的轮换就绪测试。它会询问你的浏览器所使用的解析器是否信任新密钥。该测试使用RFC 8509：DNSSEC 根密钥信任锚哨兵，我们已在轮换前于 1.1.1.1 中实现该规范。

DNSSEC 信任从何处开始

DNS 解析器为你的设备查找网站和其他服务的地址。DNSSEC 使其能够检查 DNS 记录上的数字签名，以验证这些记录真实且未被更改。解析器还需要检查用于验证这些签名的公钥是否属于正确的域名。

对于cloudflare.com，这遵循一条从 DNS 根到.com、再到cloudflare.com的信任链。每个父级都会发布一条委派签名者（DS）记录，其中包含其子级公钥的指纹。例如，.com 发布cloudflare.com的 DS 记录，使解析器能够检查该域名的密钥。

这条链需要一个起点。然而，根没有父级来确认哪些密钥属于它。因此，检查 DNSSEC 的解析器从它已经信任的根公钥或其指纹开始。这称为信任锚。

根的签名密钥有两种不同职责。区域签名密钥（ZSK）对根的 DNS 记录进行签名，包括.com等顶级域的 DS 记录。密钥签名密钥（KSK）对根发布的公钥列表（称为 DNSKEY 记录集）进行签名。解析器使用其信任的 KSK 验证该列表，然后使用列表中的 ZSK 验证根的其他记录。

下图展示了一个典型已签名区域的安排。对于根而言，信任来自解析器的信任锚，而不是父区域中的 DS 记录。

我们关于.de 和.al 轮换失败的博文展示了 DNSSEC 检查失败后的后果：网站可能运行正常，却仍然无法访问。根 KSK 轮换改变了这些检查的起点。如果解析器不信任替换密钥，其用户可能无法访问任何 顶级域下的网站。

新密钥是 KSK-2024，其密钥标签为 38696。它将取代 KSK-2017（密钥标签 20326），成为根 DNSKEY 集的签名者。在该切换之前，验证解析器需要信任新密钥。

解析器如何获取新的根密钥

RFC 5011 让解析器能够自动获知新的根信任锚。根在其 DNSKEY 集中将新 KSK 与现有 KSK 一同发布。现有 KSK 继续对该集签名，因此解析器可以使用它已经信任的密钥来验证包含替代密钥的记录。

在接受新密钥作为信任锚之前，解析器至少等待 30 天，并持续检查根已签名的 DNSKEY 记录。在此期间，新密钥必须始终保留在其检查的记录中。等待期结束后，解析器必须再次成功验证包含新密钥的记录，才能接受它。

对于本次轮换，KSK-2024 自 2025 年 1 月 11 日起已发布在根的 DNSKEY 集中。这让具备自动信任锚更新的解析器有时间在计划于 2026 年 10 月 11 日进行的签名变更之前发现并接受它。每个解析器的等待期从它首次看到并验证新密钥时开始。

对于我们的解析器，我们于 2024 年 7 月将 KSK-2024 直接添加到软件的内置信任锚中，与 KSK-2017 并列。因此，运行更新后软件的解析器从启动时起就拥有新的信任锚。

我们选择这种方法，是因为在首次轮换准备期间的经验。正如我们 2018 年的文章所述，软件升级和机器迁移导致一些解析器丢失了它们已获知的信任锚状态。我们通过更新软件默认包含新信任锚解决了这个问题。同样，将 KSK-2024 包含在软件中，避免依赖每个解析器保留它自动获知的密钥。

尽管我们于 2024 年 7 月将 KSK-2024 添加到解析器的内置信任锚中，但 1.1.1.1 和 Gateway DNS 的用户无法直接检查回答其查询的解析器是否信任新密钥。

这一次，直接询问解析器

RFC 8509 定义了根密钥信任锚哨兵，这是一种询问支持该功能的解析器是否信任特定根密钥的方法。它使用带有特殊命名域名的普通 DNS 查询。

我们的就绪测试网站 使用该协议检查 KSK-2024。两个名称提出相反的问题：is-ta-38696 询问该密钥是否受信任，not-ta-38696 询问该密钥是否不受信任。

这两个名称都有有效的 DNSSEC 签名地址记录。支持哨兵的解析器会先验证这些记录，然后根据其是否信任该密钥，直接返回响应或将答案替换为 SERVFAIL。

对于支持哨兵的验证解析器，预期结果如下：

对于支持哨兵的验证解析器，当 KSK-2024 受信任时，对 not-ta-38696 的 SERVFAIL 是预期结果。解析器会故意拒绝“不受信任”的查询。

像 root-key-sentinel-is-ta-38696 这样的哨兵标签可用于任何 DNSSEC 签名的域名。我们在测试中使用 dnstest.dev。你可以直接针对 1.1.1.1 运行这两个查询：

$ dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer

; <<>> DiG 9.10.6 <<>> @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44476
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; ANSWER SECTION:
root-key-sentinel-is-ta-38696.dnstest.dev. 300 IN A 104.18.6.197
root-key-sentinel-is-ta-38696.dnstest.dev. 300 IN A 104.18.7.197

$ dig @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev. A +noall +comments +answer

; <<>> DiG 9.10.6 <<>> @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev. A +noall +comments +answer
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3285
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232

该网站还会检查一个普通签名名称能否解析、一个故意无效的 DNSSEC 名称是否被拒绝，以及解析器是否响应针对当前根密钥的哨兵查询。这些控制措施有助于区分有意义的结果与查询失败或协议不受支持。如果无法确认哨兵支持，则结果不确定；这并不意味着新密钥缺失。

浏览器测试检查的是你的浏览器所使用的解析器，它可能受到安全 DNS 或 VPN 的影响。上面的 dig 命令显式查询 1.1.1.1。两者都提供了应答这些请求的解析器路径的快照。

新密钥，同一算法

KSK-2017 和 KSK-2024 都使用 RSA/SHA-256。此次轮换替换了密钥对，同时保持创建和验证签名的方法不变。

在我们 2018 年的文章中，我们写道，一次成功的轮换将为讨论算法变更打开大门。八年之后，根仍然使用 RSA。

替换密钥仍然有用。它限制了单个私钥的使用时长，并演练了分发新信任锚、更新解析器和停用旧密钥的过程。正如第一次轮换所表明的，即使密码学本身工作正常，这些步骤也可能失败。

互联网号码分配机构（IANA）计划采用理想化的三年轮换间隔，在定期演练与过于频繁更换根密钥所带来的工作和风险之间取得平衡。自 2018 年以来的间隔更长。互联网名称与数字地址分配机构（ICANN）将延迟归因于 疫情干扰以及保护私有签名密钥的硬件升级。

更换算法意味着解析器既需要新的信任锚，也需要能够验证新签名的软件。定期的密钥轮换让运营者可以在保持算法不变的情况下测试信任锚更新。

十月之后会怎样

10 月 11 日的切换改变了由哪个 KSK 签署根的 DNSKEY 集。轮换将持续到 2027 年，届时ICANN 计划撤销 KSK-2017、将其从根区移除并删除其私钥。停止某个密钥签名与移除对该密钥的信任是分开的步骤。

ICANN 还提议未来将根算法轮换为 ECDSA P-256。ECDSA 生成的密钥和签名比目前使用的 RSA 算法更小。该提议与今年十月的密钥替换是分开的，而且 ECDSA 不是后量子算法。

1.1.1.1 现在验证 ML-DSA-44 签名，该签名旨在抵御使用量子计算机的攻击。要使 DNSSEC 的整个信任链具备后量子安全性，已签名域、其父区和根都必须采用后量子密码学。在根层面，这意味着引入后量子 KSK 并让解析器信任它。

这将需要另一次根密钥轮换。我们现在执行的轮换让运营者测试他们如何分发替换信任锚、检查解析器是否已接受它们，并停用旧密钥。今年十月的轮换保留 RSA，但演练了当根迁移到后量子密码学时我们将需要的信任锚更新。哨兵为我们提供了一种检查解析器是否遵循这些更新的方法。

我们鼓励 DNS 提供商和解析器开发者支持 RFC 8509 信任锚哨兵。如果你的解析器不支持它们，请要求你的提供商或软件供应商添加支持。用户应该能够在轮换之前检查他们的解析器是否信任下一个根密钥。

目前，下一个截止日期是 10 月 11 日。你可以在 https://dnstest.dev/ksk-2024 检查你的解析器是否就绪。如果你运行的是 DNSSEC 验证解析器，请确认它信任 KSK-2024，密钥标签为 38696，如果密钥缺失，请遵循 ICANN 的指导 以及你的软件供应商的说明。