摘要

  • RIPE NCC 的 11 月 3 日事后报告称，主负载均衡器的网络链路短暂中断后切到备用设备；错误配置将新建 Whois 更新连接导向只读数据库，原有应用连接仍连在主库。
  • 其公布的更新失败窗口为 10 月 28 日 11:42 至 19:40 UTC。对失败的反向委派请求进一步核查后，RIPE NCC 说这些请求要么没有变化，要么未通过 zonemaster 预委派检查，因此不会改变委派。

新路接错了库

RIPE NCC 的事后报告写得很具体：主负载均衡器的一条网络链路短暂中断，服务切换到备用均衡器；后者的配置却让新建的 Whois 更新数据库连接接入只读库，而不是主库。已经建立的应用连接继续使用主库，未受这个错误路由影响。故障之所以“间歇”，不是因为主库不停地坏了又好，而是两批连接从一开始就走了不同的路。

只读库可以承担读取，不能接受资源登记对象的修改。对于发起更新的操作者，备用均衡器有响应毫无用处；需要的是新连接能完成一次写入。旧连接仍能正常工作，更容易让服务看上去只是零星出错。它们遮住了问题的规律：新来的请求被分配到错误的数据库角色。

RIPE NCC 将 10 月 28 日的更新失败窗口定在 11:42–19:40 UTC。最初的状态记录只说有更新未获处理，部分域名对象与反向 DNS 有关。11 月 3 日的报告才交代了故障切换与错误库的链条。报告没有公开哪项配置写错、各提交渠道失败多少次，也没有逐连接路径记录。一份带时间的配置差异和按渠道统计的回执，可以量出影响范围。

反向 DNS 的影响还有一条清楚的边界。RIPE NCC 后续核查说，失败的反向委派请求没有一项本来会改变委派：部分请求根本不含变更，其余未通过 zonemaster 预委派检查。写入路径发生故障是事实；这些请求没有提供“有效反向委派变更被丢失”的实例。把一次尝试直接算作生产区文件的损失，会把故障扩大成官方记录没有的结果。

真正的回执在对象层

RIPE 的对象处理说明指出，一次提交中的各对象分别处理，结果最后作为回执返回。回执说明还强调，Syncupdates 返回 HTTP 200 时，个别对象仍可能失败，必须看详细结果。于是备用均衡器的“存活”状态、HTTP 连接的建立，甚至某些旧会话的成功，都不能替代目标对象的写入结果。注册资料是否改变，要看被接受的操作和之后的读取。