摘要

  • 2025 年 11 月 13 日，ARIN 在美国东部标准时间 13:30 至 14:30 之间，主动阻断 Hosted 与 RPS 两类 RPKI 仓库的全部访问；14:35 确认完整冗余，14:50 报告系统已回到测试前水平。
  • 这次演练说明仓库访问中断后可以恢复，但公开记录没有交代 ACSP 建议 2025.7 所关心的外部依赖类别、共同故障域、循环依赖以及验证观察范围。
  • ARIN 无需公开可被攻击者利用的内部拓扑，也能给出充分说明：按服务和运行平面发布带版本的故障域说明，列明要守住的状态、演练边界、恢复节点、尚未覆盖的假设和变更通知门槛。

判断一场演练的价值，既不能只看“成功”二字，也不能因为它没有覆盖所有风险就将其贬为无效。ARIN 在 2025 年秋天留下的四个日期，恰好提供了一个更严谨的读法。

10 月 23 日，ARIN 收到一名客户关于 Hosted RPKI 的问题报告，问题出现在支持资源转移期间 ROA 的新功能上线之后。10 月 27 日公布的事故报告称，影响局限于一种特定 ROA 配置，受影响者为一名客户；ARIN 暂停正在处理的转移，确认底层代码缺陷，部署修复，并加入额外校验。

10 月 28 日，Ramakant Pandrangi 提交 ACSP 建议 2025.7。建议没有把问题局限在软件缺陷，而是要求 ARIN 按服务说明外部平台、CDN、DNS、IP 地址、BGP 路由、接入提供商等依赖，提前告知重要的运营或架构变化，并公开高层次的 RTO、RPO 与连续性安排。文中还明确提出系统性依赖和循环依赖。

11 月 12 日，ARIN 回复称正在制订计划，准备记录关键服务依赖、澄清变更管理办法、说明韧性与连续性目标，并在完成后交由社群反馈和验证。11 月 13 日，ARIN 随即在生产环境进行 RPKI 故障切换演练。

这些事情前后相接，却不是同一份证据。代码事故回答一次变更出了什么问题；建议书询问关键服务依靠什么条件；故障切换演练则说明某个被设定的中断场景能否恢复。

五个时间点，给出一个清楚的结论

ARIN 技术邮件列表中的通知写道，13:00 开始限制向 Hosted 和 RPS 仓库提供服务的网站；13:30 将所有访问主动阻断，模拟仓库完全不可达；14:30 恢复访问；14:35 确认 RPKI 服务的完整冗余；14:50 回到测试前水平。通知还解释，若只在非生产环境测试，无法如实反映仓库故障下的性能和准备情况。

这比笼统宣称“高可用”更有证据价值。读者可以区分限制开始、完全阻断、恢复访问、确认冗余和回到基线。演练确实触及真实生产环境，也确实公布了恢复节奏。

但通知所描述的注入条件，是“主动阻断访问”。它没有说明两个服务站点是否共用 DNS、CDN 控制面、上游链路、机房、电力或身份系统；没有说明后台究竟切断了哪个物理或逻辑故障域；也没有列出用于确认恢复的外部验证器范围，更没有测量路由结果。

这些缺口不是对演练的否定，而是演练结论的边界。它能证明这一场景下的恢复，不能自然外推为所有依赖都已经相互独立。

两条备援路径，也可能踩在同一块地板上

系统性依赖之所以难，不在于画出两条线，而在于确认两条线不会同时失去同一个前提。两个应用实例可以分开运行，却使用同一套域名解析或同一个管理入口。相反，使用外部服务也不必然意味着脆弱：依赖可以有多家来源，可以缓存，可以快速替换，也可以在设计上隔离。

因此，公开一家供应商的名字并不能回答问题；只列“DNS、CDN、网络”也过于空泛。真正有用的单位，是某一类依赖失效时，服务必须保持什么状态。

对 RPKI 仓库来说，这个状态可能是继续提供已经接受的材料，可能是限制最后一次发布的陈旧程度，可能是保持已发布内容的完整性，也可能是恢复后能够按顺序核对积压的写入。不同运行平面有不同答案。下载 RPKI 数据的依赖方、修改 ROA 的资源持有者、向 RPS 提交材料的委托 CA，以及负责恢复服务的 ARIN 运维人员，并不在执行同一种操作。

ARIN 2026 年 7 月的维护通知已经展示这种区分。ARIN Online、RESTful Provisioning、RPKI Up/Down 与 RPS 暂停服务；RPKI 仓库仍可读取，但不发布更新。Theo March 先前的文章已经讨论“可访问”与“数据新鲜度”两只时钟。本文关注的不是旧问题，而是每个平面依赖哪些故障域、哪一种组合真正经过演练。

Hosted、Delegated 与 RPS，责任落点不同

ARIN 当前的说明称，超过 95% 的 RPKI 部署采用 Hosted 模式。该模式下，ARIN 运行证书颁发机构，也负责高可用仓库。Delegated 模式允许资源持有者自行运行 CA 和发布仓库。RPS 又把责任拆开：资源持有者保留 CA 与私钥控制，ARIN 负责发布仓库。

这种拆分不是缺陷，而是服务价值。ARIN 的 RPS 页面明确指出，集中仓库可以位于签发 RPKI 内容的机构行政控制之外。有些机构希望保留密码学控制，却不愿承担全天候仓库运行。

连续性问题也必须随之拆开。签发方能否生成有效、可发布的材料？仓库能否接收并向外提供这些材料？仓库访问恢复测试为第二个问题提供了证据，却不能自动认证第一个问题，也不能同时覆盖发布协议、账户访问、签发授权和通知路径。

尤其在 RPS 模式中，密码学权力与发布可用性本来就属于两个不同的控制主体。把其中一方的测试结果当作另一方的证明，反而抹掉了这个服务刻意建立的责任边界。

99.9% 是成绩，不是架构图

ARIN 2025 年度报告为 RRDP 与 Rsync 仓库分别列出 99.9% 的可用性。这是一项有用的年度指标：它使服务表现可以比较，也使“可靠”不再只是形容词。

可用率不会告诉读者两条路径是否共用一个故障域，也不会给出 RTO、RPO、只读期间的数据年龄，或某次演练覆盖了哪些依赖。高可用与依赖说明尚未公开可以同时为真；结构清晰的服务也可能经历被记录的中断。

10 月份的软件事故同样不能被误用。ARIN 将其归因于上线后的代码缺陷，范围是一种配置和一名客户。它能帮助读者审视变更控制和修复过程，却不能被拿来证明外部平台或仓库备援失效。

最重要的证据纪律，就是让一份材料只承担它真正支持的结论。

不公开线路图，也能公开故障边界

详细披露供应商、机房、路由设计、控制端点和切换触发条件，确实可能增加安全风险；合同也可能限制披露。把内部架构原样放到网上，并不是负责任的透明。

但沉默不是唯一选项。ARIN 可以按关键服务及其运行平面维护一份短小、带版本的公开说明，其中包括：

  1. 服务面向谁、承担什么公共功能；
  2. 依赖类别和共同故障假设，而非敏感的供应商与地点；
  3. 某类依赖失效时必须保持的状态；
  4. 最近一次演练的场景与注入边界；
  5. 限制、恢复、冗余确认、回归基线的观测时间；
  6. 尚未覆盖的故障模式；
  7. 已采纳的可用性、RTO 或 RPO 目标；
  8. 触发成员通知的重要变更门槛；
  9. 版本、复核日期与修订记录。

公开层面可以只写“域名服务”“内容交付”“连接”“身份控制”“运行地点”等类别，不必说明厂商和坐标。精确性来自类别与受保护状态、演练结果之间的连接，而不是来自暴露内部细节。

这份说明还必须有有效期。架构变化之后，旧的“完整冗余”结论可能仍在网页上流传。若没有复核日期，一次真实的 2025 年测试会被错误套用到后来已经改变的边界。建议 2025.7 将依赖透明与变更管理放在一起，正好为这种漂移提供了解法。

“开放”是流程状态，不是工作结论

截至证据截点，建议 2025.7 仍标为 Open。ARIN 的回复说，计划完成后会交给社群反馈，建议在落实前保持开放。这允许我们描述公开进度，却不允许断言内部没有工作、进度已经延误，或某个风险被故意遮掩。

下一项有价值的公开成果，不必是一份无所不包的保证。先说明一个服务、几个运行平面、依赖类别、已测场景、剩余假设和复核日期，就能让下一次演练累积到同一套证据上。

ARIN 已经完成了最难得的一步：在生产环境实施明确干预，并公布分钟级恢复序列。依赖问题之所以仍然存在，是因为“某个故障场景可以恢复”与“整套架构没有共同依赖”本来就是两个命题。公开地把二者连接起来，才会让这次成功演练具有更长的制度寿命。

来源