Sebastiaan Neuteboom 和 James Godlewski

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：A Root Key Trust Anchor Sentinel for 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。

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

| 查询 | KSK-2024 受信任 | KSK-2024 不受信任 |
| --- | --- | --- |
| is-ta-38696 | 返回有效响应 | 返回 SERVFAIL |
| not-ta-38696 | 返回 SERVFAIL | 返回有效响应 |

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

诸如 root-key-sentinel-is-ta-38696 之类的 sentinel 标签可以在任何经过 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 月之后会发生什么

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

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

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

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

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

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

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：Cloudflare Blog

原创地址：https://blog.cloudflare.com/root-ksk-2024-rollover/