摘要

  • RIPE NCC 于 2026 年 8 月 13 日 15:03 CEST 发布 NRTM 与 split 文件事故的复盘。
  • 报告称，无效 RPSL 对象使 NRTM 在读到该对象时停止，客户端从此处开始与数据库失去同步。
  • RIPE NCC 已说明写入处理、流容错和监控的变更，其中两项修复计划随 8 月 27 日的 Whois 1.124 发布。

一份坏对象，触发了两处失守

RIPE NCC 表示，RIPE Database 的 NRTM 镜像服务约在 8 月 2 日 00:06 UTC 至 8 月 4 日 12:30 UTC 期间受到影响。复盘给出的直接机制是：一个无效 RPSL 对象被写入数据库；NRTM 服务遇到该对象后停止工作；此后客户端与 RIPE Database 脱离同步。

状态页还记录了一个明确的下游依赖。反向 DNS 配置依赖 NRTM，因此调查期间，RIPE Database 中 domain 对象的更新没有出现在全球 DNS 中。RIPE NCC 随后表示，积压的 domain 对象更新已经处理并发布。该表述刻意有限：来源没有列出受影响镜像、域名或客户，也不能据此推断每一个下游消费者的实际状态。

修复的是写入规则与流读取规则

报告将无效对象追溯到 4 月引入的 Whois 1.122 代码变更。descr: 与 remarks: 属性中额外的换行符被意外允许，因而无效 RPSL 被写入数据库。RIPE NCC 说，UTF-8 代码点替换逻辑已经调整，不再写入这些额外换行。

另一处问题在 NRTM 服务器本身。它过去不会跳过无效 RPSL，而是以“内部错误”失败。RIPE NCC 公布的新版行为是跳过该对象并记录错误；数据库团队随后可以纠正对象，使更新在之后重新进入流。两项修复都被列为 Whois 1.124 的内容，计划日期为 8 月 27 日星期四。计划不等同于已完成部署。

监控的对象应是最近一段可读数据

RIPE NCC 还增强了监控：系统将请求 NRTM 的一段最近更新并验证响应。它关注的不是端点是否还在回答，而是近期更新是否能够实际被取得和校验。

这给数据消费者留下的操作问题很具体：告警是否能够区分“连接仍可达”和“镜像流仍在可验证地推进”。公开复盘没有提供受影响客户端清单或独立恢复测量，但它清楚地把写入校验、流的容错处理和连续性监测连成了一条控制链。

来源