Summary

  • 2020 年 12 月 3 日，Matt Nordhoff 和 Peter van Dijk 报告 ripe.net 部分域名解析异常；Anand Buddhdev 随后说明，DNSSEC 签名程序留下了多余的 NSEC 记录。
  • RIPE NCC 约在欧洲中部时间 20:00 强制重签整片区域，问题随之解决，并向软件开发者报错、计划增加监测。

故障先在外面露了头。2020 年 12 月 3 日约 15:40，Matt Nordhoff 和 Peter van Dijk 告诉 RIPE NCC，ripe.net 旗下某些名字解析出了问题。第二天，RIPE NCC 工程师 Anand Buddhdev 在致 DNS 工作组的说明中点名致谢，并交代了查到的路径：区域文件最近更新时，一些地址记录的身份变成了胶水记录；DNSSEC 签名程序没处理好这次变更，留下不该出现的 NSEC 记录，造成验证失败。

这是两个平时几乎不会登上新闻版的工种撞了车。胶水记录帮解析器找到委派域名的服务器；NSEC 是 DNSSEC 对名称不存在范围所作签名证明的一部分。RFC 4035规定了验证签名 DNS 数据的规则。一旦区域里的证明不自洽，验证型解析器就不接受答案。门锁没有自行松开，屋里的账却对不上。

团队采用的修复办法直接而彻底：约 20:00，强制签名程序把 ripe.net 区域完整重签一遍。Buddhdev 说，这解决了当时的问题。从首次通报到修复，公开时间线约为四小时二十分钟。RIPE NCC 的当月会员更新也把这起 DNSSEC 验证问题列入服务事件。

他的报告没有在“恢复了”三个字处停笔。RIPE NCC 已把问题提交给签名软件开发者，并表示会增加监测，好让下一次异常更早被发现。公开记录没有受影响用户数，也没有宣称软件修补已经完成。它足以说明一次具体的操作失误：记录角色变化，签名证明失序，外部观察者报警，整区重签恢复验证。注册局维护的是资源记录，读者真正碰到的却是运行中的 DNS；两者之间还隔着一段会犯错的软件。