【论文分享】域名查询海啸：域名解析循环依赖引发的拒绝服务攻击

今天分享的是一篇关于域名解析误配置导致拒绝服务攻击的文章，“TsuNAME: exploiting misconfiguration and vulnerability to DDoS DNS”。文章的第一作者来自于荷兰SIDN实验室。论文通过测量研究证明了域名解析循环依赖（TsuNAME漏洞）的实际威胁。研究论文发表于2021年网络测量领域国际顶级会议ACM IMC（录用率：55/197=28%）。

全文共2080字，阅读时间约6分钟

【背景介绍】

域名系统作为互联网关键网络基础设施之一，负责将域名标识符翻译转换成为IP主机地址。在此过程中，域名解析流程依赖于“NS”记录[2]指明域名权威服务器信息。然而，若“NS”记录配置错误，便有可能导致NS记录形成循环依赖。

图表1：由于NS记录误配置引发的域名解析循环依赖

如图表1所示，若“*.example.com”和“*.example.nl”两个区域的NS记录相互依赖，试图查询该域名的递归解析器将不得不在两者之间反复查询，始终无法打破解析循环。这种域名循环依赖性致使权威服务器侧网络流量被急剧放大。换言之，源自客户端的一个简单查询，可能会间接导致递归解析器对权威服务器发起大量查询请求。

文章将上述安全问题称之为TsuNAME。TsuNAME的风险在于其可能会被攻击者轻易滥用，任何一个可被攻击者部署域名解析记录的权威服务器都有被攻击的风险。具体而言，攻击者可以注册多个域名，将域名NS记录部署到攻击的目标权威服务器上，使NS记录形成循环依赖。随后，攻击者可利用例如僵尸网络发起大量查询，这些查询由于循环依赖将被众多解析器放大，形成对权威服务器的DDoS攻击。

现实网络环境中的确出现过由TsuNAME漏洞导致访问权威服务器流量激增的情况。研究团队发现了2020年在新西兰国家顶级域.nz上出现的误配置问题，两个域之间形成了循环依赖，导致其权威服务器接收到的查询流量增加了50%。

图表2：.nz域权威服务器因TsuNAME漏洞导致的流量激增

【研究方法】

2020年.nz顶级域的TsuNAME事件说明，实际网络中的循环依赖的确会导致查询流量激增，并极大地加重权威服务器的负载。为了进一步研究TsuNAME漏洞的细节、成因以及威胁，研究团队在可控实验条件下展开了对于TsuNAME漏洞的复现及测量。

团队搭建了用于研究的受控权威服务器，并通过手工配置使两个域名形成NS记录循环依赖，以复现TsuNAME漏洞。文章中使用网络测量平台及被接管的僵尸网络两种方式发起大规模的域名查询请求，以分析TsuNAME漏洞的细节并探究其在真实互联网中的威胁。

1. 基于网络测量平台的实验

研究团队使用分布在全球6,740个AS域，累计约10k个活跃网络设备发起域名查询，并在查询域名中编码了编号信息，以便于后续追踪及分析。

测量实验共展开了两次：1）每个测量节点只发送1次查询；2）探针每隔10分钟即再次发送新的查询请求。

图表 3 实验拓扑示意图（黄色节点为网络测量节点、红色为域名解析器、蓝色为解析器缓存、绿色为权威服务器）

2. 基于受控僵尸网络的实验

研究团队使用一个已被接管的僵尸网络发起域名查询，以模拟真实网络环境中的攻击。该测量包括以下阶段：

• 准备阶段：对僵尸主机的请求回复“localhost”，整个僵尸网络保持沉默。

• 授权阶段：将僵尸域名的NS记录修改为研究团队控制的权威服务器。本阶段实验发现，整个僵尸网络每10分钟会产生10k次查询。

• 循环依赖阶段：部署NS的循环依赖记录，并分析权威服务器在TsuNAME漏洞下所遭受的“攻击”情况。循环依赖记录的TTL初始设置为1小时，随后调整为1秒，以观察NS记录的TTL在TsuNAME漏洞事件中的影响。

【主要发现】

研究团队对权威服务器收到的查询流量从归属、请求次数等方面进行了分析，得到了TsuNAME的放大规模及漏洞的更多细节，主要结论包括：

1. 使用网络探针发起的查询被放大了435倍，其中源自37个自治域的574个域名解析器陷入了无期限的循环。

2. 网络探针发起的查询越多，权威服务器侧流量放大的情况越严重，两者呈现正相关。

3. 使用僵尸网络发起的查询被放大了526倍，NS记录的TTL越短，权威服务器侧的流量放大越严重。

图表4：探针两次测量结果（左侧：1次请求；右侧：周期性请求）

图表5：探针测量权威侧请求情况（1次请求）

图表6：僵尸网络测量权威侧请求情况

研究团队在对请求来源做AS聚类时发现，无论是在2020年.nz顶级域中的TsuNAME事件，还是本文的复现实验中，Google Public DNS（GDNS）都贡献了最大的查询量。考虑到Google DNS是最流行的的公共域名解析服务之一[4]，其本身所承载的域名解析请求量很大，出现上述现象也在意料之中。

图表7：.nz域TsuNAME事件期间归属Google（AS15169）及其他AS的查询次数

图表8：TsuNAME问题复现期间归属Google（AS15169）及其他AS的查询次数

不过，在研究团队向Google报告问题后，Google工程师重现问题时并未发现陷入循环查询的现象。对此，Google给出的解释是：

1. 使用Google Public DNS服务来解析域名的设备（例如图表3中的R1b）由于没有获得结果而不断地重试查询。

2. Google Public DNS对于循环依赖所导致的响应失败没有缓存[3]。因此，如果GDNS不断地收到查询，Google Public DNS会重新发起请求。

上述两个因素使得Google Public DNS在面对TsuNAME漏洞时，会向权威服务器发起大量查询请求。Google工程师针对该问题进行了优化，完善了缓存机制，以避免类似的情况再次发生。

【结论】

域名解析循环依赖问题已经有30多年的历史了。技术社群早在RFC 1536[1]中便提及了该问题。但是，其安全威胁一直被严重低估。.nz顶级域权威服务器遭受的拒绝服务攻击表明，直到今天，域名解析循环依赖漏洞仍然能爆发出巨大的能量。

研究团队通过一系列受控环境下的实验，对上述攻击进行了复现与测量，得到了更多漏洞的细节信息，最终发现该漏洞能够引起近500倍的放大倍率。研究团队将问题披露给软件服务供应商以及安全社区，得到了诸多积极回应。

原文链接：

https://dl.acm.org/doi/pdf/10.1145/3487552.3487824

相关网站：

研究团队开发的域名循环依赖检查工具：https://github.com/SIDN/CycleHunter

参考文献：

[1] A. Kumar, J. Postel, C. Neuman, P. Danzig, and S. Miller. 1993. Common DNS Implementation Errors and Suggested Fixes. RFC 1536. https://www.rfc-editor.org/rfc/rfc1536.txt

[2] 1987. Domain Names - Implementation and Specification. RFC 1035. https://www.rfc-editor.org/rfc/rfc1035.txt

[3] M. Andrews. 1998. Negative Caching of DNS Queries （DNS NCACHE）. RFC 2308. https://www.rfc-editor.org/rfc/rfc2308.txt

[4] Giovane C. M. Moura, Sebastian Castro, Wes Hardaker, Maarten Wullink, and Cristian Hesselman. 2020. Clouding up the Internet: How Centralized is DNS Traffic Becoming?. In Proceedings ofthe ACM Internet Measurement Conference （Virtual Event, USA）（IMC ’20）. Association for Computing Machinery, New York,NY, USA, 42-49.

[5] Google 2020. Public DNS. https://developers.google.com/speed/public-dns/.

编辑&审校|刘保君、张一铭