摘要

  • APNIC 10 月报告将 7 月的 RFC 8145 解析器信号概览，与新一轮 RFC 8509 终端测试并列。约 90% 和 70% 描述的是不同观测路径，不能相减或取平均。
  • 网络名单是后续核查线索，不是运营商准备度评分，也不是客户受影响人数估计。运营方仍需检查自己的验证型解析器。

分析

百分比必须说明观测路径

在根 DNSSEC 密钥计划切换前两天，“准备度百分比”看起来像是所有人都想要的答案：如果大多数解析器已经接受后继密钥，切换就应当安全；如果还不够，就该有人叫停。问题在于“大多数”到底指什么。解析器发出的信号、用户终端的一次测试，以及依赖该网络的人，并不是可互换的计量单位。

APNIC 在 10 月 9 日发布的报告（作者写于 10 月 8 日）呈现了关于 KSK-2024 的两种观测。第一种依据 RFC 8145：验证型解析器可在权威服务器运营方可见的查询中，报告其信任链使用的密钥标签。第二种使用 RFC 8509 的根密钥信任锚哨兵。测试从终端系统发起，再根据响应推断解析器的信任状态。两者讨论同一把根密钥，却没有测量同一对象。

RFC 8145 的文字说明里还有一个值得保留的差异。APNIC 将 7 月图表概括为约 90% 的报告解析器已加入 KSK-2024。Verisign 7 月 28 日的更新则称，约 500 天时，发送信号的来源中采用率已超过 95%。APNIC 将图表归于 Verisign，但两篇公开说明没有给出共同的精确抽取日期和指标定义，无法让读者对齐这两个数字。它们可能对应不同截面或概述；现有文字不足以裁定。这是应当保留的文档口径缺口，不是某项测量失效的证据。

最新的 70% 更不能直接与前两个数字相比。APNIC 表示，其基于广告的终端测量平台平均每天进行约 1,600 万次测试。约 600 万次显示终端位于执行 DNSSEC 验证的递归解析器之后；约 180 万次给出了明确的 RFC 8509 支持信号。在看起来支持哨兵机制的测试中，约 70% 报告 KSK-2024 已加载。其分母是能够明确分类的支持型测试子集，不是全部 1,600 万次测试、所有验证型解析器或所有互联网用户。

两种协议，两类问题

RFC 8145 允许验证型解析器报告其信任链中的密钥标签，提供 EDNS 选项和特殊查询两种可选信号方式。对于根区，权威基础设施运营方可以观测这些信号。数据能显示发送信号的来源所报告的密钥状态如何变化。

这并不说明每个解析器背后有多少家庭、企业或服务。有些递归解析器服务数以百万计的用户，另一些只服务一个组织或一台设备。转发链也可能改变根服务器运营方看到的内容。因此，报告信号的比例回答的是关于这些信号的问题，不是用户暴露程度的问题。

RFC 8509 使用另一条路径。测试发送特定格式的 DNS 查询；支持该机制的验证型解析器会根据是否信任某个根密钥作出不同响应。APNIC 通过广告测量平台，让这些测试经过一批终端系统。它更接近被测试终端实际经历的解析路径，但仍取决于路径上的解析器是否支持哨兵，以及响应能否被正确分类。它无法识别该终端背后的每一个解析器，也无法统计共用该解析器的全部用户。

10 月 5 日的 RIPE Atlas 测试又提供了第三种视角，但不是普查。来自 2,900 个自治系统的探针中，有 1,230 个表现出与新密钥已加载一致的行为，47 个表现出与尚未加载一致的行为。这些是相应网络中的探针结果，并不表示对这 2,900 个系统的完整检查，也没有说明任何一个结果背后的客户数量。

只要明确每种测量要回答的问题，局部样本仍然有用。RFC 8145 能显示向根区报告信号的解析器声称采用了什么密钥；RFC 8509 能测试支持型终端解析路径；RIPE Atlas 提供位置不同的观测点。但任何一种都不能单独给出覆盖整个互联网、并按用户数量加权的完整分母。

观察名单不是判决

APNIC 报告里最可操作的部分不是全球比例。表 3 列出过去一周观测到的 KSK-2024 接受率最低的 50 个网络，并筛掉了哨兵测试支持量不到 1,000 次的网络。这个过滤条件让条目比单次观测更有参考价值，却不等于完成了准备度审计。

名单中有亚太地区的网络，包括泰国 National Telecom 和孟加拉国 Teletalk。APNIC 报告，前者在 1,355 次哨兵支持型测试中的接受率为 48.4%，后者在 2,046 次中的比例为 48.2%。这些数据指出值得进一步检查的测试样本。它们不能证明两家运营商的所有解析器状态相同，也不能证明每个响应代表一个不同的人，更不能推断相同比例的客户会失去访问。

APNIC 建议名单中的网络自行测试解析路径，例如使用 Cloudflare 运营的检查页面，并复核 DNS 设置。这是名单的合理用途：为运营方提供一条线索，而不是外部判决。服务商可能运行多套递归服务、转发部分流量，或者依赖软件厂商分发密钥。公开表格无法裁定这些配置。

日历上有三个不同转换

IANA 当前日程显示，KSK-2024 于 2025 年 1 月 11 日加入根区；遵循 RFC 5011 的解析器预计在一个月后开始信任它。2026 年 10 月 11 日，KSK-2024 计划开始签署根区，KSK-2017 则停止签署。旧密钥计划于 2027 年 1 月 11 日撤销，并于 3 月 22 日移除。

这些日期代表不同状态。“新密钥开始签名”不等于“旧密钥已撤销”，撤销也不等于已从区域文件移除。RFC 5011 的新增保持期给解析器时间去观察并验证后继密钥，再自动接受它。但协议存在，并不能证明某个具体部署已启用自动更新、保存了可写状态，或收到了所需观测。

各机构的职责也不同。IANA 发布根信任锚文件和当前日期；ICANN/PTI 运行根 KSK 流程；Verisign 承担根区维护工作并运营一个根服务器观测点；APNIC 发布自己的测量分析。网络运营商仍要为客户使用的递归解析器负责。APNIC 能提供证据，但不控制根密钥，也不决定全球转换是否继续。

对运营方而言，眼下应当做的是本地检查：确认部署中的解析器信任正确的后继密钥，验证自动更新或经批准的手动流程确实有效，并测试生产用户实际使用的解析路径。IANA 发布信任锚文件，厂商提供各自的操作说明。公开测量可以提示从哪里查起，却不能代替组织自行验证。

截至 10 月 9 日，证据支持的是有限结论：后继密钥已发布一年多，大量被观测信号和测试路径报告已加载，APNIC 也指出了适合定向跟进的网络。90%、超过 95% 和 70% 不能合成一个准备度分数。10 月 11 日真正的操作问题，是某条验证路径能否接受新密钥签署的根区，而不是哪个比例更适合当标题。

来源

APNIC 10 月 9 日测量报告；IANA 信任锚与轮换日程；RFC 8145；RFC 8509；RFC 5011；Verisign 7 月 28 日更新；ICANN 2026 年运营方常见问题；Cloudflare 的 KSK-2024 解析器测试。