Skip to content
Published on

2026 年 10 月 11 日，根 KSK 将会更换 — 现在根区里到底有什么

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
分享
Authors

引言 — 87 天后会发生的事

2026 年 10 月 11 日，DNS 根区的密钥签名密钥(KSK)将从 KSK-2017 变为 KSK-2024。今天是 7 月 16 日，也就是还剩 87 天。

这句话可以有两种读法。如果你用的解析器不做验证(validation)，这就不是新闻，什么都不会发生。如果你运行的是做 DNSSEC 验证的解析器，而它的信任锚没有更新，那么那一天，这台解析器会开始对所有域名返回 SERVFAIL。因为信不过根，也就信不过根下面的一切。

ICANN 的 FAQ 对这个情形的措辞很克制 — 如果在没准备好的情况下开着 DNSSEC，可能会遭受「重大财务影响(significant financial impact)」，终端用户在每次查询域名时都会看到错误，进而可能引发客服电话。

本文不打算从抽象的解释讲起，而是直接打开根区看看。

现在根区里到底有什么

直接问根服务器就行。下面是我在 2026 年 7 月 16 日亲自跑出来的结果。

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

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8931
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
.  172800  IN  DNSKEY  256 3 8 AwEAAeCYD6Z7WWKVLeuWgowKP+3g...   ; ZSK
.  172800  IN  DNSKEY  257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WS...   ; KSK-2017
.  172800  IN  DNSKEY  257 3 8 AwEAAa96jeuknZlaeSrvyAJj6ZHv...   ; KSK-2024
.  172800  IN  RRSIG   DNSKEY 8 0 172800 20260801000000 (
                                         20260711000000 20326 . ...

;; MSG SIZE  rcvd: 1139

这里有几点值得细看。

一共 4 条记录：一个标志位为 256 的 ZSK，两个标志位为 257 的 KSK(KSK-2017 和 KSK-2024)，还有一个 RRSIG。两把 KSK 已经并排放在区文件里好几年了。

但 RRSIG 只有一个，签名所用的密钥标签是 20326 — 这是 KSK-2017。也就是说，截至今天，唯一在给根 DNSKEY 记录集签名的密钥仍然是 KSK-2017。KSK-2024 只是被放进了区文件，还没有签署任何东西。10 月 11 日要变的正是这一点 — 签名者会从 20326 换成 38696。

签名的有效期也能看到：从 20260711000000 到 20260801000000，也就是从 7 月 11 日到 8 月 1 日。根 KSK 的签名是在每季度举行的密钥签署仪式(key ceremony)上提前生成，再按插槽逐步发布的。

而且响应大小是 1139 字节。这个数字后面还会再出现。

这两把密钥是什么 — IANA 信任锚文件

把 IANA 发布的信任锚文件拿下来实际解析一下，是这样的。

id=Kjqmt7v  tag=19036  alg=8  validFrom=2010-07-15  validUntil=2019-01-11  (无公钥)
id=Klajeyz  tag=20326  alg=8  validFrom=2017-02-02  validUntil=(无)       RSA 2048 位，e=65537
id=Kmyv6jo  tag=38696  alg=8  validFrom=2024-07-18  validUntil=(无)       RSA 2048 位，e=65537

有三点值得指出。

第一，文件里包含三把密钥。19036 是 KSK-2010，2019 年就已经退役，标注了 validUntil。如果你要自己写代码解析这份文件，务必检查 validFrom 和 validUntil。那种「把文件里的密钥全部当信任锚载入」的天真实现，会把一把早已作废的密钥也塞进去。

第二，KSK-2024 的 validFrom 是 2024-07-18。这是它出现在 IANA 文件里的日期，不是它被发布到根区的日期。这个日期后面还会再有意义。

第三，也是最重要的一点 — 三把密钥全都是算法 8。而且把公钥直接解码一下，KSK-2017 和 KSK-2024 都是指数为 65537 的 RSA 2048 位密钥。也就是说这次更换换的是密钥本身，加密算法保持不变。这个话题后面再单独展开。

8 个阶段，6 年

根据 ICANN 的 FAQ(2026 年 5 月 22 日版本)，KSK 的生命周期由约跨 6 年的 8 个阶段组成，密钥实际用于签名的时间大约是 3 年。每个阶段都绑定在一次密钥签署仪式上。

阶段 A  生成密钥          2024 年 4 月    在第一个密钥管理设施生成 KSK-2024
阶段 B  复制密钥          2024 年 7 月    复制到第二个设施 -> 获得投入运行的资格
阶段 C  生成初始签名       2024 年 10 月   预先生成阶段 D 要用的签名
阶段 D  发布              2025 年 2 月    KSK-2024 出现在根区中
阶段 E  更换              2026 年第 4 季度  只有 KSK-2024 为根区签名   <- 2026-10-11
阶段 F  吊销              2027 年第 1 季度  将 KSK-2017 从根区中移除
阶段 G  销毁 1            2027 年第 2 季度  在第一个设施的 HSM 中销毁 KSK-2017
阶段 H  销毁 2            2027 年第 3 季度  在第二个设施的 HSM 中销毁 KSK-2017

这里有一处虽小但值得诚实指出的不一致。ICANN 的 FAQ 把阶段 D(发布)记为「2025 年 2 月」，但负责运营根区的 Verisign 明确指出，KSK-2024 出现在根区的日期是2025 年 1 月 11 日。Verisign 一方的日期与其自身数据吻合，因为它正好和后文提到的「30 天保持期结束后，采纳率从 2 月 10 日起飙升」这一观测精确对应。实际落地区文件的日期，应该以 1 月 11 日为准。

那么为什么偏偏总是 10 月 11 日 呢。这不是巧合。ICANN 的算法更换提案解释了这个结构 — 每个季度被切成 9 个约 10 天长的发布插槽，密钥变更会在该季度的第 11 天发布，也就是插槽 2。第 4 季度从 10 月 1 日开始，所以插槽 2 正好是 10 月 11 日。这就是为什么原定在 2017 年的更换日期、以及实际执行的 2018 年更换日期，都是 10 月 11 日。

RFC 5011 — 为什么大多数人什么都不用做

根区没有父区。.com 的密钥由根区里的 DS 记录来担保，但没有更上层的区来担保根区自己的密钥。所以解析器必须把根 KSK 直接配置成信任锚。那当这把密钥变化时该怎么办呢 — 这就是 RFC 5011(Automated Updates of DNS Security (DNSSEC) Trust Anchors，现已成为 Internet Standard)。

工作方式是这样的。当一把新的 KSK 第一次出现在信任点的 DNSKEY 记录集中时，解析器会把它记作候选。如果这把密钥持续以有效签名的状态存在，添加保持期计时器(Add Hold-Down timer)就会开始运行。照搬 RFC 5011 的定义，添加保持期的时长是「30 天，或首次包含该新密钥的信任点 DNSKEY 记录集原始 TTL 到期时间，两者中较长的那个」。这个条件的目的很明确 — 让解析器在接受密钥之前，至少看到两次包含该新密钥的、经过验证的 DNSKEY 记录集。由于根 DNSKEY 的 TTL 如上面 dig 结果所示是 172800 秒(2 天)，实际上是 30 天在起主导作用。

30 天过后，解析器会把新密钥加入永久性的信任锚配置。运营者什么都没做。

这就是为什么这次更换对大多数人来说是一件无关紧要的事。KSK-2024 从 2025 年 1 月起就已经在根区里，实现了 RFC 5011 的解析器早在 2025 年 2 月就已经接受了它。即便 10 月 11 日签名者发生变化，那些解析器早就已经认识新密钥了，所以什么都不会发生。

RFC 5011 还有两条值得了解的条款。一是，合规的解析器必须能够为每个信任点管理至少 5 把 SEP 密钥。另一个是吊销(revocation)规则，这正是下一节的核心。

10 月 11 日的悬崖 — 以及一个常见的误解

我在好几篇讲这次更换的文章里都看到过这样的说法：「10 月 11 日之后 KSK-2017 依然留在 DNSKEY 记录集里，要到 2027 年 1 月才会被吊销，所以错过截止日期的运营者在那之前还有最后的补救机会。」

这是错的。 更准确地说，「还有时间」这部分没错，但「在那之前还能正常工作」这个言外之意是错的。

顺着 DNSSEC 验证链看下去就能明白原因。解析器要信任根 DNSKEY 记录集，就必须在附着于该记录集的 RRSIG 中，找到一个由自己持有的信任锚密钥所签署的。ICANN 的 FAQ 用一句话描述了阶段 E — 「只有 KSK-2024 用于给根区签名(Only KSK-2024 is used to sign the root zone)」。也就是说，从 10 月 11 日起，DNSKEY 记录集上只会有一个 RRSIG，来自 38696。

对于只信任 KSK-2017 的解析器来说，DNSKEY 记录集里能看见 KSK-2017 这件事本身毫无帮助 — 因为它没有办法验证这个记录集，压根没有由它认识的密钥所签的 RRSIG。这台解析器会在 10 月 11 日当场死掉，而不是等到 2027 年 1 月。

那为什么还要特意把 KSK-2017 留在区文件里呢？答案在 RFC 5011 的吊销规则里。RFC 5011 的设计使得单纯把密钥从记录集里去掉，并不构成吊销。照搬文档自己的解释，如果没有吊销位，任何密钥 B 都能仅仅通过发布一个不含 A 的密钥集就使 A 失效；为了防止这一点，机制加入了一条要求 — 只有知道某个 DNSKEY 对应私钥的一方，才能吊销那个 DNSKEY。

具体来说，RFC 5011 规定：一把密钥要被视为已吊销，解析器必须在一个自签名(self-signed)的 RRSet 里看到它，并且其中 REVOKE 位被置为 1。而所谓自签名的 RRSet，指的是一个包含该 DNSKEY、并且附有可用该同一把密钥验证的 RRSIG 的记录集。

也就是说，要在 2027 年第 1 季度把 KSK-2017 妥善吊销，那个时间点的 DNSKEY 记录集就必须同时由 KSK-2024 和已吊销的 KSK-2017 双方签名，这样一台仍把 KSK-2017 当作信任锚的 RFC 5011 解析器才能看到这次吊销，并把它从自己的存储里删掉。KSK-2017 在 10 月之后还留在区文件里，是为了日后按规矩被吊销，而不是为了让没能更新的解析器继续存活。

顺带一提，这也会让 DNSKEY 响应多附加一个 RSA 2048 签名(仅签名数据就是 256 字节)。也就是说今天测得的 1139 字节到时候会因此再大出这么多。这个响应大小的问题，正是本文后半部分的主角。

RFC 5011 还有一个细节。设置了 REVOKE 位的 DNSKEY，指纹(fingerprint)会和没设置这个位时不一样，意味着密钥标签会变。如果在吊销阶段还写死指望 20326 这个标签不变的监控，那时候就会出问题。

2017 年的教训 — 遥测数据真正揭示了什么

要理解这次更换计划为什么设计得如此谨慎缓慢 — 近两年的预发布期，长达 6 年的生命周期 — 得回到 2017 年去看。

原本从 KSK-2010 到 KSK-2017 的更换，计划定在 2017 年 10 月 11 日。可是到了 9 月 27 日，ICANN 宣布推迟。直接读一下当时的公告，就能看到判断依据。

基于使用 DNSSEC 验证解析器的互联网用户数量估计，ICANN 表示全球四分之一的互联网用户、约 7.5 亿人，可能受到这次更换的影响。(这是一个暴露规模的估计，不是对实际受害人数的预测 — 原文用词本身就是「could be affected」。)推迟的理由是这样写的 — 新获取的数据显示，ISP 和网络运营商所使用的相当数量的解析器还没有准备好。

公告里也解释了那份「新获取的数据」是什么 — 一项非常新近才加入的 DNS 协议特性，让解析器能把自己配置的密钥回报给根服务器。虽然没有点名，但那就是 RFC 8145(Signaling Trust Anchor Knowledge in DNSSEC)。它是在 2017 年 4 月发布的 — 也就是说，这项标准问世才五个月，它所产生的数据就让全球规模最大的一次密码密钥更换踩下了刹车。

不过，这里真正的教训藏在下一句话里。ICANN 说，运营者没有拿到新密钥的原因可能有好几个，其中一条是这样写的 — 在一款广泛使用的解析器程序里，最近发现了一个问题，它似乎没有按理应有的方式自动更新密钥，原因仍在调查中。

这才是关键。遥测数据揭示出来的不是「运营者偷懒了」，而是实现了 RFC 5011 自动更新的软件本身有 bug。自动化已经打开了，自动化在悄无声息地不起作用，要不是有遥测数据，本该等到 10 月 11 日才会有人发现。

时任 ICANN CEO 的 Göran Marby 是这么说的 — 与其硬按已宣布的 10 月 11 日日期强行推进，不如谨慎而理智地行事。

这次更换最终在整整一年后的 2018 年 10 月 11 日实施。

我的解析器现在准备好了吗 — 以及这项确认为什么比想象中难

最可靠的方法是直接问解析器本身。BIND 的话用 rndc managed-keys status，Unbound 的话打开根锚点文件(通常是 root.key)，看里面有没有 38696 就行。如果你能访问自己的基础设施，这就是答案。

如果要从外部探测一台你无法访问的解析器(比如上游 ISP 的解析器)，可以用 RFC 8509(A Root Key Trust Anchor Sentinel for DNSSEC)。这是一种让客户端从自己这一侧，判断解析器是否把某个特定密钥当作信任锚的机制。

工作原理是这样的。如果查询名称最左边的标签是 root-key-sentinel-is-ta-<key-tag> 或 root-key-sentinel-not-ta-<key-tag>，解析器就会做特殊处理。RFC 给出的真值表如下。

标签         | 信任该密钥              | 不信任该密钥
--------------------------------------------------------
is-ta       | 返回原始响应             | 返回 SERVFAIL
not-ta      | 返回 SERVFAIL           | 返回原始响应

有两点要注意。密钥标签必须补零到五位(按 RFC 的例子，42 要写成 00042)。38696 和 20326 正好本身就是五位数，直接用即可。而且要触发特殊处理，所有前提条件都必须满足 — 响应必须经过 DNSSEC 验证，验证结果必须是 Secure，CD 位必须关闭，QTYPE 必须是 A 或 AAAA，OPCODE 必须是 QUERY。只要有一项不满足，解析器就不会对响应做任何处理。

这些前提条件在实战中很容易绊倒人。我最初在 iana.org 下面加上哨兵标签测试时，结果全是 NXDOMAIN — 因为那是个不存在的名字，根本没触发哨兵的条件。得用一个能返回 Secure 响应的名字打底才行。

于是我搭了一个像样的对照组重新测量。用一个确定不存在的密钥标签 00000 作对照组。如果哨兵确实在起作用，is-ta-00000 就必须返回 SERVFAIL。如果没出现，那这次测量就什么都证明不了。

以下是我在 2026 年 7 月 16 日实测的结果。

Quad9 (9.9.9.9)
  is-ta-38696   x12  ->  NOERROR 12
  is-ta-00000   x12  ->  SERVFAIL 9,  NOERROR 3      <- 结果混杂
  not-ta-38696  x14  ->  SERVFAIL 5,  NOERROR 9      <- 结果混杂

Cloudflare (1.1.1.1)
  is-ta-00000   x14  ->  NOERROR 14                  <- 未观测到哨兵行为

Google (8.8.8.8)
  is-ta-00000   x14  ->  NOERROR 14                  <- 未观测到哨兵行为

读法是这样的。

Quad9 上 is-ta-00000 曾经返回过 SERVFAIL，这本身就是部分后端确实实现了 RFC 8509 的证据(对照组通过)。在那些后端上，not-ta-38696 是 SERVFAIL，按真值表意味着它们信任 KSK-2024，这也和 is-ta-38696 始终是 NOERROR 不矛盾。三个结果彼此一致。

不过说句实话，这次测量真正的教训并不在那个结论上，而在于结果本身就是混杂出来的这个事实。同样的查询反复发送，SERVFAIL 和 NOERROR 会交替出现。这可以用「一个任播地址背后有多个后端实例，其中只有一部分实现了哨兵机制」来解释。事实上，我最初只各查询一次时，得到了一张干净的真值表，差点就据此下结论了。反复测了几次之后，结果并不总能重现。

所以正确的总结应该是这样：哨兵是针对单个解析器实例的测试，面对大型任播解析器时，它不是一个决定性的诊断工具。 查一次什么都证明不了，至少需要重复测量加上一个对照组密钥标签。而在 Cloudflare 和 Google 上没观测到哨兵行为，完全不意味着它们不信任 KSK-2024 — 只是这种方法看不出来而已。

现在的采纳率是多少 — 没有公开的数字

那么全球解析器里到底有百分之多少信任 KSK-2024 呢。

目前公开的最新数字，来自 Verisign 的 Duane Wessels 在 2025 年 3 月 19 日写的一篇文章：截至 2025 年 3 月 3 日，91.3% 的解析器发出信号表示信任 KSK-2024。这个数字是厂商自测的，前提条件需要说清楚 — 它针对的是发出 RFC 8145 信号的解析器样本(a sampling of resolvers)，不是全体，而没有实现 RFC 8145 的解析器一开始就是不可见的。Verisign 还补充说，这个采纳速度和上一次更换同一时间点的情况精确吻合。

2026 年年中的最新采纳率没有被公开。 就我能查到的范围而言，在距离更换还剩 87 天的此刻，没有任何官方数字被发布出来。所以我不会在这里编一个数字。

同一篇文章里，反而有另外两个观测更有意思。

第一，100% 的解析器都把 KSK-2017 当作信任锚，Verisign 预计这个状态会一直持续到 2027 年初 KSK-2017 被吊销为止。这不难理解 — 因为那是目前唯一的签名密钥。

第二，仍有相当数量的解析器信任早在 2019 年就已退役的 KSK-2010。 Verisign 认为，这很可能是因为操作系统的软件更新里残留了这把密钥。一把七年前就已经死掉的密钥，如今还留在信任存储里。这就是 DNSSEC 部署的现实 — 协议是干净的，被部署出去的世界却是杂乱的。

还记得 IANA 文件里 KSK-2024 的 validFrom 是 2024-07-18 吗。Verisign 观察到，从 2024 年 7 月，也就是密钥刚被加进 IANA 信任锚文件之后不久，就有少数解析器开始把 KSK-2024 加入信任锚了，他们认为这是运营者手动配置的结果。两个独立的信息来源，在同一个日期上对上了。

这次更换不会改变什么 — 算法

前面提到过，两把 KSK 都是算法 8、RSA 2048 位。现在该聊聊这个话题了。

ICANN 的算法更换提案对这个情况做了平静的总结 — 根区的 DNSSEC 签名始于 2010 年，用的是基于 RSA 的算法；KSK 在 2018 年更换过一次，但加密算法本身从未变过；已经在进行中的 2026 年 10 月 11 日这次更换，同样维持相同的算法。然后是关键的一句话 — 目前不存在把根区迁移到另一种签名算法的既定机制。

这个空白由 ICANN 在 2021 年发布的第二次安全、稳定性与韧性审查(SSR2)指出，理事会在同年 7 月采纳了这项建议。其结果是 2024 年的根区算法更换研究，在此基础上，2026 年 3 月 2 日被提交公开意见征询的，就是 Proposal for Root Zone KSK Algorithm Rollover。

计划是这样的：从 RSA/SHA-256(算法 8)迁移到 ECDSA P-256 with SHA-256(算法 13)。从 2027 年生成新的 ECDSA 密钥开始，一直持续约 4 年，到 2030 年最终销毁被替换下来的 RSA KSK 为止。方式是双重签名(double-signing)。

这里有一点需要指出。这不是因为 RSA/SHA-256 弱才迁移的。

算法建议的权威来源是 2025 年 11 月发布的 RFC 9904(DNSSEC Cryptographic Algorithm Recommendation Update Process，废止了 RFC 8624)。直接打开这份文档里的表格，是这样的。

No. Mnemonics        Use/Signing   Use/Validation  Impl/Signing  Impl/Validation
 8  RSASHA256        RECOMMENDED   RECOMMENDED     MUST          MUST
13  ECDSAP256SHA256  RECOMMENDED   RECOMMENDED     MUST          MUST

两种算法的评级完全相同。 RSASHA256 既没有被废弃，也没有被列为不推荐。ECDSA P-256 之所以被选中，是因为它满足 ICANN 研究里的标准 — 已在 IETF 完成标准化，并且在 DNSSEC 验证上被列为必须实现(MUST) — 同时它已经部署在众多 TLD 上，而且 BIND、Unbound、Knot Resolver、PowerDNS 等主要软件都支持它。

那到底为什么要迁移呢。提案给出的实际动机是响应大小的管理，以及从根本上讲，「证明这个迁移流程确实存在」。如果从来没做过算法更换，那么在真正需要的那一刻(某个算法被攻破的时候)，就做不了。SSR2 指出的空白，正是这一点。

再补充一点，RFC 9904 把算法要求的权威来源，从一份 RFC 文档转移到了一个 IANA 注册表。也就是说，上面那张表只是一个快照，以后建议等级如果变化，更新的是注册表，而不是需要修订 RFC。如果你的代码或文档里还在引用 RFC 8624，现在就是该改的时候。

算法更换的悖论 — 1536 位之争

现在到了本文最有意思的部分。

想走向 ECDSA P-256 的理由之一是它的签名更小，但要走到那一步，得先让响应变得大得多。 因为用的是双重签名方式，在过渡期间根区会同时用 RSA 和 ECDSA 签名，DNSKEY 记录集里也会同时装着两套密钥。

提案正面回应了这个问题。2018 年那次以及之后的 KSK 更换之所以没有响应大小的问题，是因为在不改变算法的更换里，只有 DNSKEY 响应的大小会受影响。而根服务器接收的全部查询里，DNSKEY 查询占比连 0.5% 都不到。即便 DNSKEY 响应被截断、退回到 TCP 重试，对根服务器系统的影响也可以忽略不计。

可是在双重签名的算法更换里，连委派(referral)响应和 NXDOMAIN 响应都会变大。 这才是根流量的大头。再加上 2020 年 DNS Flag Day 把默认最大 UDP 缓冲区大小推到了 1232 字节，两者叠加在一起。提案的结论很冷峻 — 如果用 2048 位 ZSK 做双重签名，大多数根服务器响应都会被截断，最终转为 TCP 重试。

于是有了这样的对策：在算法更换开始之前，先把 RSA ZSK 从 2048 位降到 1536 位。 1536 是 1024 和 2048 的中间值，只有这个尺寸才能让(除了季度 ZSK 更换期间的 DNSKEY 响应之外)几乎所有响应都保持在 1232 字节以下。

也就是说，为了守住响应大小，故意把加密密钥削弱。而且这一削弱要持续大约 3 年。

公开意见征询中争论最多的地方，正是这里。根据意见征询结果报告，一共提交了 12 份意见，其中包括 ICANN 安全与稳定性咨询委员会(SSAC)一份迟交的意见。RSSAC、RySG、Verisign 三个组织表示支持；四位在支持的同时附上了建议；四位提出了担忧或反对。

反对方的论据很具体。1536 位不是 NIST 认可的标准 RSA 密钥尺寸，这次缩减会把 ZSK 的有效安全强度从大约 112 位降到大约 90 到 96 位，而这种被削弱的状态会持续整个约 3 年的更换周期。

ICANN 的回应也值得一读。要点在于暴露窗口(exposure window)。它认同 SSAC 的分析，认为每一把 ZSK 密钥实际投入使用、并可被公开观测到的时间大约是 110 天，而这个窗口对于以当前能力对 1536 位密钥发起暴力破解来说太短了，不具可行性。它这样写道 — 「相对于 2048 位密钥的安全性下降是真实存在的，但受限于这个操作窗口(The security reduction relative to a 2048-bit key is real but bounded by this operational window)」。这句话在翻译时不能被软化 — ICANN 并不否认安全性确实降低了这件事本身。

针对「不是 NIST 标准尺寸」这一点，回应是：NIST 的密钥管理指南确实把 1024、2048、3072 位列为参考尺寸，但在 DNSSEC 运营中，非标准的 RSA 密钥尺寸并非没有先例 — 根区自己的 ZSK 过去就曾是 1280 位。

在数字方面，Verisign 也一并提交了基于 RSSAC-002 流量数据的实证分析，结果显示 1536 位 RSA ZSK 与 ECDSA ZSK 的组合会把约 1% 到 5% 的响应推到 1232 字节以上。ICANN 的判断是，虽不完美，但相比维持 2048 位而言实质上是更好的结果。这同样是提交方自己的测量，是基于 RSSAC-002 这一特定流量数据集的估计值。

还有一个被提出的担忧是，触发阶段日程调整的判断标准没有被定义。 这指的是何时该延长、何时该回退，缺少明文写下的判断依据。考虑到 2017 年的那次推迟归根结底也是一次主观判断，这个批评是站得住脚的。

结果是这样的：计划没有出现结构性的改变。 ICANN 表示会按提案继续推进，但会另行发布阶段过渡的判断标准，并对运营者社区做有针对性的宣讲。

还有一个技术上很有意思的反对意见。提议中的阶段 DD 会先发布 ECDSA签名，而对应的 ECDSA DNSKEY 还不发布；对此有人指出，只发布签名在安全上没有任何好处，因为反正ECDSA 公钥本来就能从签名中恢复出来。这在密码学上是对的。

什么时候这不是你的问题

老实说，读到这里的大多数人，其实什么都不需要做。

不用操心的情况

  • 你不做 DNSSEC 验证。(大多数企业内部解析器都属于这一类。)
  • 你用的是 Cloudflare、Google、Quad9 这类公共解析器。那是他们的问题，不是你的问题。
  • 你用的是托管解析器，信任锚由厂商负责管理。
  • 你用最新版的 BIND/Unbound/Knot、默认配置运行，RFC 5011 自动更新已开启，并且从 2025 年 2 月起一直不间断运行到现在。这种情况下你已经拥有 KSK-2024 了。

需要检查的情况

  • 你自己运营验证解析器。
  • 你手动配置了信任锚，或者用配置管理工具分发 root.key 文件。如果 RFC 5011 是关闭的，自动更新就不会发生。这正是 ICANN 要在 IANA 网站上为不使用 RFC 5011 的软件发布信任锚文件的原因，建议是在解析器启动时、以及根 DNSKEY 记录集里的 KSK 发生变化时去获取这份文件。
  • 容器镜像或一体机里把信任锚固化进去了。如果镜像是在 2025 年 2 月之前构建的、之后再也没有重新构建过，而且 RFC 5011 的状态文件存在容器层里而不是持久卷上、每次重启都会被重置，那么 30 天的保持期就永远不会走完。这是现代部署环境里最有可能出现的失败模式。
  • 你处于气隙(air-gapped)环境，或者到根服务器的出站访问受到限制。

检查方法很简单。看解析器的信任锚存储里有没有 38696 就行。有的话就没事了。

结语

总结一下：2026 年 10 月 11 日，根 KSK 将从 KSK-2017 变为 KSK-2024。今天打开根区看看，两把密钥已经并排放在里面，签名的仍是 KSK-2017。开启了 RFC 5011 的解析器早在 2025 年 2 月就已经接受了新密钥，所以那天它们什么都不会经历。没能接受新密钥的解析器，会在那一天当场死掉 — 不存在延续到 2027 年 1 月的宽限期。KSK-2017 留在区文件里，是为了日后被按规矩吊销掉，不是为了保活别的什么解析器。

2017 年的教训依然成立。当年让那次更换停摆一年的，不是偷懒的运营者，而是一款广泛使用的解析器的自动更新 bug，发现它的是一项才问世五个月的遥测标准。「打开了自动化」和「自动化真的在起作用」是两回事。所以这一次的计划特意留出了将近两年的预发布期。

而且这次更换不会改变算法。真正困难的那部分工作 — 从 RSA 到 ECDSA — 是从 2027 年开始、一直持续到 2030 年的另一个独立项目，而这个计划因为提议把 RSA ZSK 故意削弱三年、以守住响应大小，招致了最多的反对意见。ICANN 承认这种削弱「真实存在，但有限度」，并按计划继续推进。

这两点或许才是本文真正的要点。更换互联网的信任锚，不是一个密码学问题，而是一个部署问题 — 在被部署出去的世界里，一把七年前就死掉的密钥依然留在信任存储里。而设计一次安全的迁移时，总会有那么一个瞬间，你必须接受在迁移进行的这段时间里变得没那么安全。诚实的计划不会把这一点藏起来，而是把它写进文档。

如果现在有什么事要做，那就只有一件：如果你运营着验证解析器，打开信任锚存储，确认一下有没有 38696。还剩 87 天。

参考资料

Discuss on Twitter • View on GitHub