摘要

  • RIPE NCC在10月30日新增的记录，把10月28日数据库间歇性更新失败区间列为UTC 11:42至19:40；原事故页面于UTC 19:32标记解决。
  • 补充调查称，失败请求都不会改变反向委派：要么没有修改内容，要么没通过Zonemaster预委派检查。原记录的影响等级为“major”，后续记录则为“none”。

两条RIPE NCC记录现在给这场数据库故障画出了两条不同的时间线。10月28日的原页面在CET 20:23进入监控，CET 20:32宣布解决，即UTC 19:32。两天后新增的记录却把间歇性更新失败写到UTC 19:40。按同一时区换算，失败窗口比宣布解决晚了8分钟。

这条后续记录还把故障起点提前到UTC 11:42。首条公开调查信息在CET 20:04发布，即UTC 19:04；两者相差7小时22分钟。原页面的调查文字说部分更新未处理，一些domain对象影响了反向DNS，并把事故影响标为“major”。

10月30日的调查缩小了数据层面的影响。RIPE NCC说，失败请求都不会改动反向委派：有些请求本身没有变化，另一些没有通过Zonemaster预委派检查。RIPE的反向DNS文档说明，domain对象用于申请反向委派，名称服务器检查通过后，RIPE NCC才会传播委派。

因此，这里记录的是写入请求失败，不是已提交的反向委派被改坏。状态API却为原记录标注“major”，为关联的后续记录标注“none”，没有解释两者为何不同。它也没有公布失败请求数量或涉及的对象。补上这些信息，运营者才能知道哪些提交已由RIPE的调查结案，哪些仍需逐项对账。

来源