Summary

  • RIPE NCC 记录显示，数据库更新和反向委派操作间歇失败至 10 月 28 日 19:40 UTC。
  • 事故页在 20:32 CET（19:32 UTC）标记解决；10 月 30 日核查称，失败请求均不会改变委派记录。

RIPE 状态页最初描述的是一项正在发生的服务故障：部分 RIPE Database 更新没有被处理，某些域对象也影响到了反向 DNS 服务。故障从 10 月 28 日 11:42 UTC 持续到 19:40 UTC。RIPE NCC 实施修复并监测结果，随后于欧洲中部时间 20:32 将事件标为解决。

10 月 28 日应把两处时间换算到同一时区。欧盟委员会公布的 2026 年夏令时安排显示，欧洲于 10 月 25 日结束夏令时，因此 20:32 CET 是 19:32 UTC。RIPE 状态历史把受影响时段结束记为 19:40 UTC。解决时间比列出的故障窗口结束早八分钟。

两天后的公开更新把影响范围说得更细。RIPE NCC 对失败请求进行进一步检查后表示，没有一项请求会导致反向委派发生变化。有些请求本来就没有变更内容；其余请求没有通过 Zonemaster 的预委派检查。更新通道确实不稳定，但这些请求没有通过改变委派记录所需的检查。

关键就在这一区别：操作被打断，不等于它要改变的状态已经改变。RIPE NCC 说，创建、更新和删除反向委派的操作间歇失败；后续核查则说，失败请求本身无论如何都不会改变这些委派。状态记录同时给出了两项事实，却没有公布每一类请求的数量。

RIPE NCC 尚未说明数据库更新究竟在 19:32 还是 19:40 UTC 恢复；经时区统一的更正时间，才能判明这是显示差异，还是事件在受影响窗口结束前就已关闭。

时间线本身颇有价值。20:04 CET，RIPE NCC 表示部分更新未处理，某些域对象影响反向 DNS。20:23，它称已实施修复并开始监测。20:32，事件标记为解决。10 月 30 日，状态历史补充了请求级别的解释。前三条描述服务恢复，后续说明则限定对注册状态的影响。

时间线从更新失败推进到修复与监测，再到逐项核查请求。公布有效请求的重试和重放结果，便能看出服务恢复后是否仍有工作待处理。

记录：RIPE NCC 故障时间线；RIPE NCC 状态历史及 10 月 30 日更新；欧盟委员会 2026 年夏令时日期。