摘要

  • RIPE NCC把本地DNS检查、路由表检查和Atlas锚点可达性接入了服务前缀的自动撤告与重公告流程。
  • 防火墙错误让所有实例的可达率同时归零；共同故障保护逻辑保留了最后一次路由状态。
  • 这是一次路由保护测试，官方记录没有报告DNS服务中断或用户影响。

最整齐的一排零，反而可能是最可疑的一排数据。

RIPE NCC系统工程师Leon Grasmeijer在RIPE 93的DNS会议上说明，托管DNS的路由控制不只看服务器是否响应。一个小型守护进程会查询本地DNS服务；服务失败时，实例前缀就撤告。随后增加的检查会确认实例是否有默认路由或完整路由表，二者都缺失也会触发撤告。RIPE NCC还在核心站点持续公告覆盖前缀，为实例级自动化留下回退路径。

这次更新把测量也接进了闭环。系统向RIPE Atlas锚点发送消息，统计每个DNS实例有多少比例的锚点能够收到。比例过低，可能说明返回路径异常，于是服务前缀被撤告。过去，故障恢复后还要由人手动重新公告；现在，撤告和恢复公告都由程序自动执行。

自动化最容易犯的错，是把两种故障压成一个数字。单个实例的可达率下降，可能是这台服务器的返回路径真的出了问题；所有实例一起变成零，则也可能是大家共用的测量链路失灵。RIPE NCC给后一种模式加了保护：如果过多实例或地点同时落到低值，就保留最后一次结果，避免一口气撤掉一批路由。

它不是纸面上的边界条件。一次错误的防火墙变更阻止了指标收集，所有实例随即显示零可达率。前缀仍按预期保持公告。这个测试证明保护逻辑挡住了误撤告；它没有证明真实DNS流量曾中断，也没有测量解析器受到什么影响。

RIPE NCC的DNS服务页把AuthDNS描述为一个anycast集群，承载反向DNS、ripe.net、e164.arpa等基础设施区域，也为部分ccTLD提供辅助DNS。该页列出AS197000公告的193.0.9.0/24和2001:67c:e0::/48。BGP撤告会告诉对等路由器，不要继续使用此前公告的路由；RIPE NCC所说的核心覆盖前缀则是另一道连续性措施。它们都不能替代对终端实际路径的测量。

RIPE NCC没有公布锚点总数、撤告与恢复阈值、保持时间，也没有指出防火墙测试触及了哪条具体公告；这些参数决定其他运营者能否复现这套保护逻辑。

控制器面对的是两种相反代价：误判一台实例会撤掉仍可用的路由；把共同测量故障当成真实恢复，则可能保留已经过时的公告。核心覆盖路径、实例检查和共同故障保护各自处理不同故障。把它们混成一个“可用”数字，反而会丢掉这套设计最有价值的区分。

来源