摘要

  • RIPE NCC 记录的 NRTM 故障从 8 月 2 日 00:06 UTC 持续到 8 月 4 日 12:30 UTC，共 60 小时 24 分。期间反向 DNS 更新延迟；修复后，待处理更新全部完成。
  • Ed Shryane 在 RIPE 93 说明，解码转义字符时额外插入了换行，RPSL 对象因此不符合语法。修复保留转义字符，并检查了最近 1,000 个对象和数据流结束标记。

分析

RIPE 数据库里的域名对象可以已经变更，全球 DNS 却还没有看到更新。中间断在 RIPE NCC 的近实时镜像服务 NRTM：反向 DNS 配置系统也依靠这条数据流获取数据库变更。

RIPE NCC 在 8 月 6 日发给数据库工作组的邮件给出了完整影响时段：8 月 2 日 00:06 UTC 至 8 月 4 日 12:30 UTC，合计 60 小时 24 分。邮件说，这段时间全球 DNS 更新被拖延；NRTM 修复后，所有积压更新都已处理。RIPE 的状态记录将事件定为重大故障，后续更新确认待发布的域名变更已处理，反向 DNS 服务恢复正常。

RIPE 数据库工程师 Ed Shryane 在 RIPE 93 的 Database 会议上讲明了故障机制。程序解码了本应保留转义形式的字符，在 RPSL 对象中额外生成换行。RIPE NCC 接收了这个语法无效的对象。RPSL 的格式由 RFC 2622 定义，换行和续行规则本身就是结构的一部分；解码不是无害的展示处理，它改变了下游解析器面对的内容。

修复有两个动作：停止反转义，让字符保持原样；回头检查数据流中最近的 1,000 个对象，确认它们都能正确解析，并核对 NRTM 响应末尾的结束标记是否一致。前一项消除了新的语法破坏，后一项则验证接收端读到的是完整、可解析的一段流。

这条链路从数据库对象经过镜像流，再进入反向 DNS 配置，最终发布到 DNS 区域。一个文本转换出错，延迟就传到了链路末端。公开来源给出了持续时间和恢复结果，却没有公布受影响的镜像客户端或域名数量；这些数字会改变对外部影响面的判断。

来源

RIPE 93 Database 会议文字稿；RIPE 93 会议页面；RIPE NCC 状态记录；RIPE NCC 发给 Database 工作组的邮件；RFC 2622。