TsuNAME 攻击复现报告

一、摘要

本报告详细记录了对[IMC ‘21]《TsuNAME: exploiting misconfiguration and vulnerability to DDoS DNS》所述TsuNAME攻击的复现过程。TsuNAME 攻击利用权威DNS服务器上错误的循环依赖配置，诱使脆弱的递归解析器陷入查询循环，有对权威服务器形成拒绝服务攻击(DDoS)的潜力。

我们搭建了两种独立的实验环境来验证论文中提及的脆弱系统：一是基于 Docker 的环境，运行了 PowerDNS Recursor 3.6.2；二是在虚拟机中部署了 Windows Server 2008 R2 并启用其 DNS 服务器作为解析器。实验结果表明，尽管这两种系统在面对循环依赖配置时确实会触发查询循环，但它们均未表现出无限循环/较大的流量放大的行为。PowerDNS Recursor 和 Windows Server 2008 R2 内置的循环检测机制均能在有限次迭代后（通常在4-12次查询内）成功中止循环，并向客户端返回错误。

因此，在我们的受控环境中，单次查询触发的包放大系数（PAF）远低于论文大规模实验中观测到的“500x+”，通常在3-5之间。推测的可能原因为现实情况下的DNS系统，往往由多个转发器与多个递归解析器共同组成。经测试，在加入一个脆弱/带有激进重试机制的转发器后，流量规模可以达到了100x+。论文中也提及TsuNAME攻击的巨大威胁主要源于网络生态中大量脆弱解析器与客户端重试行为共同作用下的级联效应。

二、原理分析

TsuNAME 攻击的核心原理是滥用 DNS 的委托机制，制造一个无法被解析的依赖闭环。

攻击者控制（或利用错误配置）的至少两个域名，例如 a.com 和 b.com。将 a.com 的某个子域（如 sub.a.com）的NS记录指向 b.com 域下的一个域名服务器（如 ns.sub.b.com），同时将 b.com 的某个子域（如 sub.b.com）的NS记录指回 a.com 域下的域名服务器（如 ns.sub.a.com）。这就形成了一个死循环：
- 要解析 host.sub.a.com，需要 sub.a.com 的域名服务器 ns.sub.b.com 的IP地址。
- 要解析 ns.sub.b.com 的IP地址，需要 sub.b.com 的域名服务器 ns.sub.a.com 的IP地址。
- 要解析 ns.sub.a.com 的IP地址，又回到了第一步。
当一个不具备完善循环检测机制的递归解析器收到对循环内任一域名的查询时，它会不断地在两个（或多个）权威服务器之间来回查询，试图打破这个循环。
用户的一次初始查询，在脆弱的解析器上会转化为持续不断发往上游权威服务器的多次查询。如果网络中存在大量此类脆弱的解析器，并且有持续的客户端查询触发，这些放大的流量将汇聚到权威服务器上，形成DDoS攻击。

关键放大因素

脆弱解析器的数量：网络中易受攻击的解析器越多，总放大倍数越高。
客户端重试逻辑：当查询超时或收到错误（如SERVFAIL）时，如果客户端应用会重新发起查询，进一步加剧了循环。(GDNS的流量加剧问题反而来自于Google客户端的重试)
缓存策略：极短的TTL或解析器不缓存错误响应的策略会使每一次查询都重新触发完整的循环。(GDNS同样没有实现负缓存)

三、实验复现

1. 实验环境

我们构建了两个的实验环境，以分别验证论文中提到的且能够获取到的两种脆弱解析器

Docker + PowerDNS

服务	IP 地址	角色	作用
`recursor`	`10.3.0.2`	受害者递归解析器	运行 `PowerDNS Recursor 3.6.2`，论文中提及的易受攻击版本之一。
`auth`	`10.3.0.3`	根及.com权威服务器	模拟根和顶级域，将查询委托给下一级权威服务器。
`auth2`	`10.3.0.4`	`a.com` 权威服务器	负责 `a.com` 域，配置`sub.a.com`指向 `ns.sub.b.com` 的循环NS记录。
`auth3`	`10.3.0.5`	`b.com` 权威服务器	负责 `b.com` 域，配置`sub.b.com`指回 `ns.sub.a.com` 的循环NS记录。
`attacker`	`10.3.0.6`	攻击客户端	向递归解析器发起初始查询，触发循环。

VM + Windows Server 2008 R2

服务	IP 地址	角色	作用
Windows Server VM	`10.3.0.10`	受害者递归解析器	运行 Windows Server 2008 R2 (含最新Service Pack) 的DNS服务器角色，作为论文中提及的关键测试目标。

2. 实验思路与结果

在 auth2 (a.com) 和 auth3 (b.com) 的区域文件中，配置了相互指向的NS记录，制造了 sub.a.com 和 sub.b.com 之间的循环依赖。
从 attacker 容器分别向 PowerDNS 解析器和 Windows Server 2008 R2 解析器发起对 $random.sub.a.com 的查询。
在权威服务器容器内运行 count.py 脚本，使用 Scapy 嗅探并统计收到的DNS查询包数量。
实验结果
- PowerDNS Recursor 3.6.2
  - 明确存在一个极短时间的负缓存
  - 触发循环，权威服务器收到来自解析器的交替查询。
  - 循环被中止：在NS记录循环下，约4-5轮迭代后停止；在CNAME记录循环下，约10-12轮后停止。PAF 约为 4~5。
- Windows Server 2008 R2
  - 明确不存在任何形式上的负缓存
  - 同样触发循环，行为与 PowerDNS 类似。
  - 循环同样被中止：与 PowerDNS 的结果非常接近，解析器在迭代数次后检测到循环，并停止查询，最终向客户端返回 Server failure。PAF 同样在 3~5 的范围内。

3. 遇到的困难与挑战

本次复现最重要的发现是，未能重现论文中描述的 Windows Server 2008 R2 无限循环的行为。这一直接冲突可能源于以下几点：

软件补丁：论文中观察到的 r1 解析器是2020年在野外发现的实例，其具体的补丁级别未知。实验环境使用了安装了MSDN官方最新Service Pack的 Windows Server 2008 R2（虽然也在2020年后停止更新与支持）
配置差异：DNS服务器的默认配置可能会影响其循环检测行为。实验环境采用的是标准安装配置，而野外的服务器可能有自定义的、更宽松的配置(但实际检查发现，DNS服务可供配置的内容较少，网络上关于2008 R2的配置问题也往往浅谈辄止)