SIDN Labs 等机构在对比 .nl 与 .nz 权威服务器流量时发现，DNS 区文件中的循环 NS 记录配合错误的客户端或转发器，会触发 tsuNAME 漏洞，使单次查询放大为海量递归请求，导致权威服务器流量异常激增；现有 RFC 仅阻断解析器端循环，无法阻止客户端与转发器发起循环，研究团队已向 IETF 提交修复草案并开发 CycleHunter 检测工具，Google 与 Cisco 已在公共解析器侧完成缓解。
成因机制：循环依赖与错误转发
当两个区相互指向对方的 NS 记录形成循环，例如 .com 区 example.com NS cat.example.nl、.nl 区 example.nl NS dog.example.com，解析器在追踪授权时会在两个权威服务器间反复跳转。RFC 规定解析器应检测并终止自身循环，但未约束存根解析器、转发器或客户端发起的循环请求。这些错误组件持续向权威服务器发送重复查询，形成放大攻击面，原文未给出具体放大倍数。
实测影响：.nz 区流量激增 50%
图 1 显示，两个原本几乎无流量的 .nz 域名在 tsuNAME 事件期间日查询量均超过 1 亿次。图 2 显示，仅这两个错误域名就使 .nz 总权威流量上升 50%。.nz 运营方修正区文件循环后问题缓解，但攻击流量在修复前已持续冲击权威集群，原文未给出持续时长与峰值带宽。
修复进展：草案、工具与厂商缓解
研究团队提交 IETF DNS 工作组草案，提出在权威与递归层面增加循环检测与熔断逻辑；同步发布 CycleHunter，可扫描区文件发现潜在 NS 循环。Google 与 Cisco 工程师已在其公共 DNS 服务器部署缓解措施，阻断来自错误转发器的循环查询，但部署覆盖范围与生效时间原文未给出具体数据。
对运维工程师而言，需定期审计区文件中的 NS 记录排除跨区循环，部署 CycleHunter 做常态化扫描，并在递归层面启用查询速率限制与循环熔断；同时关注上游公共解析器的缓解策略生效情况，防止少量错误配置引发全区流量风暴。
原文: APNIC Blog（2022-01-20）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog