摘要

  • APNIC 在 9 月 24 日刊出的服务公告中，把 2026 年 9 月 29 日 10:00—12:00（UTC+10）的 GCP 网络环境更新列为计划维护，所列服务是 DASH、notification、REx 和 AS0 ROA Service。公告正文称预计不会停机；维护尚未发生，不能把这句话读成事故报告。
  • 现行 APNIC 地址资源政策第 5.1.4 节规定，以 AS0 ROA 标识 APNIC 管理下仍为 Available 或 Reserved 的地址空间，并在委派给账户持有人时移除相应前缀。政策没有给出此次维护期间的更新时间指标。
  • APNIC 的 2020 年上线说明记载，当时系统在正常情况下以少于五分钟完成委派后的 AS0 移除和再发布。这是历史设计与当时的实施描述，不是已经核实的 2026 年 SLA。
  • AS0 使用独立的信任锚定位文件（TAL），由网络主动选择是否纳入验证。APNIC 建议把结果用于提示或告警，而非直接自动过滤 BGP 路由。即使某个环节出现延迟，路由后果也不能脱离验证器和运营者配置来推断。

同一张维护单，四种检查方法

这份公告最容易被误读的地方，不在“预计不停机”，而在把所有受影响服务放进同一个可用性指标。DASH 的页面可以加载，notification 的端点可以响应，REx 的界面可以访问，AS0 的仓库也可以返回一个有效对象；这几项观察都成立时，仍需另外问：对象所陈述的地址状态是不是最新的。这里并不假设 APNIC 为这四项服务设置了同一个后台、同一个数据库或同一条发布链。公告只说明它们属于这次 GCP 网络环境更新的影响范围。

2025 年 7 月 31 日的另一份公告也列出相同四项服务，彼时的工作是升级 Kubernetes。它说明 AS0 不是偶然写进一次维护名单，却不能证明一年后的系统拓扑未变。把两次名单叠在一起当成基础设施图，会给分析制造虚假的精度。同样，2026 年公告末尾惯用的“outage”致歉文字，也不能推翻正文对未来窗口“预计不停机”的判断；那不是已发生中断的记录。

对于普通信息页面，持续可访问通常就是最直接的检查。AS0 不一样。它是一个带签名的资源状态声明，其对象会随着委派事实改变。RFC 6483 第 4 节把 origin AS 0 的 ROA 描述为对所列前缀及更具体前缀的路由源发否认。APNIC 并非宣称自己控制所有互联网地址；它的现行政策把范围限定为自己管理、尚未委派且在扩展委派统计中标为 Available 或 Reserved 的 IPv4 和 IPv6 空间。委派发生后，原先的“未委派”判断就必须退出该声明。

因此，至少要分清四个时点：权威登记记录何时接受新委派；AS0 生成过程何时据此改变覆盖范围；新的签名对象何时公开；选择该 TAL 的外部验证器何时实际取到并使用它。后两者不是一回事。APNIC 可以控制自己的登记和发布，却不能替每家网络决定验证器的拉取节奏，更不能替它们决定是否将 Invalid 结果用于路由拒绝。运营者能够看到的对象版本，也未必能反向证明登记系统何时先行变化。

五分钟是历史线索，不是今天的承诺

APNIC 当年的实施报告说，生产系统把实时委派变化在五分钟内反映到主 RPKI 和 AS0 状态，并把从可分配池发出的资源从 AS0 ROA 中移走。报告当时描述了与登记事件紧密相连的内部组件、云端发布仓库和全天候监控。同期博客把“正常情况下少于五分钟”写成已部署系统遵循的目标。这些细节说明为何更新时钟值得问；它们不能证明六年后的架构、目标、实测延迟或本次维护期间的运行结果仍相同。

如果维护窗口内根本没有新委派，AS0 内容保持不变完全可能是正确结果。此时做两次抓取、发现哈希一致，并不能证明更新链“通过了五分钟测试”；也不能证明它出错。测试必须由事件触发。只有确定发生了哪一笔委派、登记生效时间为何、旧对象何时不再覆盖该前缀、新对象何时可被外部取得，才有资格讨论延迟发生在哪一段。若对外只公布“服务在线”，最多证明在某些观察点上能够连接，不能把没有发生的状态转换补造成测试样本。

反过来，一个外部验证器晚取到更新，也不能单凭这一点指控 APNIC 发布迟缓。验证器缓存、轮询、仓库获取与本地路由策略，各有不同操作者和时钟。能够追责的记录必须保留对象或清单版本、发布时间和外部观察时间，而不是把所有分钟都归在“APNIC 可用性”一栏。

风险来自采用方式，不来自公告本身

假设一个刚委派的前缀仍被较旧 AS0 对象覆盖，主动采用该独立 TAL 的验证器可能继续看到带签名的否认声明。但某条路由的最终验证状态还取决于全部相关 ROA、验证器实现和本地配置；路由是否被过滤又是运营者自己的决定。这里没有证据表明本次维护出现了这种延迟，更没有证据表明任何路由被误判、丢弃或造成用户断网。APNIC 的使用警示正因为这类配置依赖而强调告警用途，并警告错误可能在特定路由配置下造成中断。

独立 TAL 是一种重要的选择权：网络不会无意中把 APNIC 的 AS0 声明当作普通 RPKI 信任锚的一部分。它不是物理隔离证明，也不是维护期间的自动容灾方案。2020 年材料提及云端发布仓库，2026 年公告提及 GCP 网络环境；仅凭两个句子，仍不能还原今天仓库的部署图，更不能断定所有四项服务共享故障点。

一个比例适当的事后说明，可以分别交代接口是否持续可达、AS0 发布路径在窗口内是否经历了真实状态变更、若有变更其登记与发布版本如何对应、以及是否有外部观察样本。若没有合格的委派事件，就明确说更新时钟未被此次窗口检验。这是本文提出的可验证报告方式，不是 APNIC 已经承诺的产品或报告义务，也不是指控其缺少内部监控。

公告可能会被事实完全证明准确。要守住的只是词义：“不停机”回答服务有没有断开；对 AS0 这样会随委派变化的声明，还需要回答记录有没有及时变对。一个绿色状态灯不能承担两种证明。

来源