The keys to the Internet change on October 11. Are you ready?

互联网的密钥将于10月11日变更。你准备好了吗？ | Cloudflare 博客

post

DNSSEC

可靠性

1.1.1.1

密码学

DNS

2026年10月6日

互联网的密钥将于10月11日变更。你准备好了吗？

Sebastiaan Neuteboom 和 James Godlewski

9分钟阅读

复制链接

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 继续对集合进行签名，因此解析器可以使用已信任的密钥验证包含替换密钥的记录。

在将新密钥接受为信任锚点前，解析器至少等待 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 被信任

KSK-2024 未被信任

is-ta-38696

返回有效响应

返回 SERVFAIL

not-ta-38696

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

Sentinel 标签（如 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 名称是否被拒绝，以及解析器是否能对当前根密钥的 Sentinel 查询做出响应。这些验证机制有助于区分有效结果与查询失败或协议不支持的情况。如果无法确认 Sentinel 功能支持，测试结果将无法得出明确结论，这并不表示新密钥缺失。

浏览器测试会检查你浏览器使用的解析器，这可能受到 Secure 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。与当前使用的 RSA 算法相比，ECDSA 生成的密钥和签名更小。该提议与今年十月的密钥更换是独立的，且 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 的指南和软件供应商的说明。

目录栏

讨论栏

相关标签及社交媒体链接

相关标签

关注社交媒体

• Cloudflare

电子邮件订阅