摘要

  • 2026 年 5 月 8 日发布的 RIPE-859，为 K-root 如何满足 RSSAC001v2 提供了第一份逐项公开说明。
  • 每项预期还应附范围、方法、期间、结果、例外和整改状态；敏感拓扑与门限可以留在受保护证据中。

十六个答案不是十六份证明

基础设施条目链接 K-root 网站、AS25152 和 PeeringDB；运行变更会进入技术邮件列表与状态页；测量条目指向 RSSAC002 文件。文件还说明使用 TSIG、持续监测、公开联系人，并借助一万多个 RIPE Atlas 观测点。

这些对象中，有些可以在文件之外核验。日度文件有日期、格式和指标；状态通知有时间；路由身份可交叉比对。它们不证明整个服务，却划清了观察边界。

另一些回答只是高层保证。容量被称为充足，却没有需求情景和测试期间；业务连续性计划据称定期审查与演练，却没有最近日期和结果；运营方通信渠道据称通过日常使用或会议测试，却没有公开回执。公开未见回执不等于内部控制不存在，只说明公众无法判断保证是否仍然新鲜。

需要的是逐项证据矩阵

每一行应记录 RSSAC 版本、负责职能、服务范围和期间，并把基础分为公开观察、受保护测试、控制说明或独立保证。随后写明方法、最近日期、结果类别、未结例外、整改和下次复核。

敏感细节不必公开。连续性演练可以只说明某季度覆盖若干故障类别，达到验收条件，仍有两项行动待完成。精确门限、恢复通道和站点拓扑可由授权审查者检查。

实现多样性说明了这种分层的必要。RIPE-859 说 K-root 使用至少两套、通常三套 DNS 代码，两套软件 BGP 路由器代码和两种硬件实现。数字表达设计意图，却没有说明分布、共同依赖或最近评估日期。安全的保证回执可以补齐这些元数据。

陈旧区数据的处理同样需要时间边界。隔离站点可继续提供根区，待区过期后自动撤回服务；RIPE 92 的 DNS 工作组纪要也提到相关自动撤回机制。公众无需知道如何绕过它，只需知道何时演练、覆盖哪些站点类别、是否还有例外。

证据不能抹平权限边界

RFC 7720 规定协议与部署要求，把运行预期留给 RSSAC001。RSSAC 提出预期，RIPE NCC 运营 K-root，根区维护方提供数据，外部探针只能观察自身路径。矩阵不会让 RSSAC 取得执法权，也不会让 RIPE NCC 成为根区内容的所有者。

ICANN 自管根服务器的答复称自己至少每年复核两次。这不是性能排名，只说明公开答复可以声明更新节奏。RIPE-859 也应保存修订日期、被替代证据和纠错历史。

这份文件不是失败，而是一份尚未完成的问责底稿。下一步应诚实标记：这里是指标，那里是说明，另一处是受保护测试，还有一处仍依赖机构信誉。K-root 需要的是信心来源地图，而不是礼仪性的合规印章。

来源