今天分享的论文的主题为针对 DNS 递归解析器的 DDoS 攻击。该工作由来自 Tel-Aviv University （以色列特拉维夫大学） 的 DEEPNESS Lab 的研究人员完成。在互联网的早期阶段，域名系统（DNS）是互联网的核心基础服务，其提供简单的域名到  IP 的映射服务。但是随着互联网的发展，DNS 已经发展成为了一个非常复杂的系统，其内部由不同的组件相互耦合构建，如开放解析器、递归解析器、公共 DNS 服务商等，这些组件共同协作完成域名解析的任务。面对层出不穷的安全问题，开发者为了尽可能减低损失往往会对软件漏洞进行快速修补，而这些补丁往往很难进行周全的设计与分析，从而导致新的安全风险，本文研究人员利用 NXNSAttack [1] 的缓解机制的缺陷，设计实现了一种新型的针对递归解析器的复杂性 DDoS 攻击（Complexity Attack，复杂性攻击，指一种利用系统在最坏情况下的性能表现来消耗系统资源的攻击方式 [3]），同时揭示了修复安全问题时面临的严峻挑战。该论文发表于网络安全领域顶级会议 UESNIX Security 23。

全文共 3300 字，阅读时间约 10 分钟。

01

【背景介绍】

分布式拒绝服务攻击（DDoS）是 DNS 系统面临的主要安全风险之一。在 RFC1034 中，DNS 解析器的设计者建议通过Bound the amount of work避免 DDoS 攻击。然而，真实网络环境中，在诸多复杂机制的联合作用下，针对 DNS 的新型 DDoS 攻击仍时有发生。

The recommended priorities for the resolver designer are:1. Bound the amount of work (packets sent, parallel processes started) so that a request can’t get into an infinite loop or start off a chain reaction of requests or queries with other implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED SOME DATA.
发表于 USENIX Security 20 的 NXNSAttack [1] 便介绍了一种 DDoS 攻击方法。DNS 递归解析器在接收到不包含NS 记录 IP 的响应时，将开启多个主动解析进程发起对响应中全部 NS 记录的查询，以提高解析效率。这种解析机制可能被攻击者滥用，构造针对递归解析器的放大攻击，达到使递归或权威服务器拒绝服务的效果。我们公众号之前的文章也对 NXNSAttack 进行了详细介绍，请感兴趣的读者点击链接进行阅读。NXNSAttack 发表后，BIND9、KNOT 和 UNBOUND 等软件迅速对相关漏洞进行了修复。然而，NXNSAttack 补丁在修复原有漏洞的同时，也引入了全新的安全风险。论文作者发现，在结合某些 DNS 机制的基础上，NXNSAttack 补丁可被再度利用，导致 NRDelegationAttack，一种新型的、更为复杂的 DDoS 攻击。下面将首先对攻击利用的四种 DNS 机制进行介绍。

1. SLIST
“SLIST” 机制在 RFC-1034 中提出。它在解析器实现中用作临时存储器，用于记录在处理客户端查询时执行的每个中间名称服务器解析的状态。在 BIND9 中其被实现为 address-DB (ADB) [2]。图 1是 BIND9 中 ADB 的实现。当递归解析器接收到响应中没有包含 NS 记录的 IP 地址的响应时，其将 NS 记录保存在 ADB 中，并启动新的 DNS 查询来收集这些 NS 服务器的 A 记录。

图 1：BIND9 对 SLIST 的实现及使用流程

2. Delegation Response
要回答解析器的查询请求，权威服务器可以决定将解析工作委托给另一个名称服务器。例如图 2 中，example1.com 将 e1.example.com 的解析委托给 www1.example2.com ，或者当解析器获得引用响应（Referral Response, RR） 时，就会发生这种情况。
在解析器的实现中，Delegation Response 将会触发restart事件。

图 2：Delegation Response

3. Restart Event
在许多情况下，解析器中的解析过程被委托给不同的名称服务器，在这种情况下，它将重新启动并在新的名称服务器上继续解析。被重定向到的“新权威”服务器将会被记录在 ADB 中。
在restart时，解析器会清除和重置一些标识位，其中包括为了缓解 NXNSAttack 引入的No_Fetch标识位，其用来限制解析器每次查询的NS数量，当No_Fetch为1时，将终止本次解析。
4. Referral Response Limit
为了缓解 NXNSAttack，解析器增加了解析Referral Response中NS的数量限制，每次仅会解析Referral Response中的 k 个 NS。在具体实现中，BIND9 和 KNOT 设置 k 为 5，UNBOUND 为 6。

02

【威胁模型】

一、攻击条件

1. 一个或多个可以发起恶意查询的客户端

2. 一个可控的权威服务器，用于产生特定的referral response3. 不响应 DNS 查询的服务器列表或者 IP 地址

二、攻击流程

图 3：NRDelegationAttack 流程图

如图 3 所示，NRDelegationAttack 主要包括三个阶段：

阶段一：攻击者从客户端发起恶意的查询，使得递归解析服务器向攻击者控制的权威名称服务器发起查询。

阶段二：攻击者利用可控的权威名称服务器返回没有胶水记录的超长的referral response（大小设为 n ）。根据解析器软件的实现（文中主要针对 BIND9 的实现），解析器首先将遍历 ADB 和缓存，查看这些 NS 是否之前查询过，因为存在 A 和 AAAA 两种记录，所以会查询2n次，这是 NRDelegationAttack 的主要成因之一，每次的遍历耗费了服务器大量的计算资源，此时将一次遍历的负载记为 CC(n)。当解析器没有找到 NS 的有效信息，则会对这些 NS 发起解析，由于Referral Response Limit限制的存在，因此，解析器每次仅查询有限的 k 个 NS。

阶段三：当解析器查询referral response中的 NS 时，将触发Delegation Response，此时restart事件被激活，因此No_Fetch标识位被清除，因此解析器通过步骤 10 重新回到步骤 4，再次查询 ADB 和缓存。另一方面，由于攻击者设置的是不响应 DNS 查询的服务器，因此，这些无法获取到这些NS的有效信息，因此，无法在ADB 中更新这些 NS 的信息。所以步骤 10 只有到达解析器的安全限制计数器的上限才会停止，BIND9 中这个上限为 100。该上限对攻击者来说已经可以完成攻击了。文中指出，NSNXattack 计算负载不高的原因是解析器一次性的发出所有请求，并发出的查询标记，不会重复的查询。而 NRDelegationAttack 利用被清除的No_Fetch标识位，形成重复的查询，造成服务器过载。

图 4：攻击时的解析器算法流程图

图 4 展示了解析器在受到 NRDelegationAttack 时，内部的算法流程图，与图 3 对照可以同时观察解析器在NRDelegationAttack 下内部算法的实现和解析流程的关系。三、攻击变种

表 1：NRDelegationAttack的不同变种

表 1 为利用不同的权威服务器的配置来实现 NRDelegationAttack 的不同变种，论文中主要针对 NR-Delegation 变种进行介绍。

03

【NRDelegationAttack 分析】

在 NRDelegationAttack 分析部分，论文作者主要从两方面说明 NRDelegationAttack 的影响，包括复杂性因子理论评估和攻击的实际测量评估。
一、复杂性因子理论评估
首先定义基本的术语：
Rstrts(n): referral 中记录条数 n 与 restart 次数的关系，其计算公式如下：

RR_Sent(n): referral 中记录条数 n 与 NS 名称查询总数的关系，其计算公式如下：

ResolutionLoop(n): referral 中记录条数 n 的计算负载（论文通过测算，得到指令数为21000）
QSentCost(n): referral 中记录条数 n 的与解析过程中查询 NS 名称时执行的指令数的关系，计算公式如下：

Cost(n): referral 中记录条数 n 产生的负载，计算公式如下：

为了验证理论评估的准确性，本文在隔离的实验环境中进行攻击测试，测试效果如图 5 所示。橙红色的线为理论评估值，蓝色线为实际的负载，可以看出理论评估值与实际负载是非常接近的，从而验证了理论评估的准确性。

图 5：真实的攻击负载和理论评估值对比

二、对 NRDelegationAttack 的实际测量评估
为评估 NRDelegationAttack 的真实影响，论文中进行了两方面的验证，一是在云环境中部署测试环境，验证NRDelegationAttack 对不同解析器软件的影响；二是针对公共 DNS 服务器进行测试，评估其对真实应用的影响。
2.1 云环境测试
测试环境部署在微软云上，文中主要关注了 BIND9、Knot 和 Unbound 三款解析器软件，以 NSD (Name Server Daemon, 一个开源 DNS 服务器) 为权威服务器软件。部署的软件均为修复了 NXNSAttack 的版本。具体架构如图 6 所示。

图 6：云环境下的部署架构

图 7 展示了不同攻击条件下不同解析器软件的解析能力。可以看出随着 referral-list 的增大，攻击效果会更好。文中指出这是因为更长的 referral-list 增加了解析器在 ADB 和缓存中的查询负载。

图 7：NRDelegationAttack 对不同解析器软件的攻击效果

2.2 对开放解析器影响文中对开放解析器进行了限制性的攻击测试，以评估 NRDelegationAttack 对真实的开放解析器的影响。攻击中，攻击者仅发起一个恶意查询，返回的 referral-list 仅包含 20 个 NS。攻击者的客户端超时间设置为 15 秒。表 2 展示了测试结果。从表 2 中可以看出不同的开放解析器都受到不同程度的影响，甚至有 4 个开放解析器（Dyn，Yandex，Norton，Ultra）直接超时。

表 2：开放解析器测试结果

三、缓解措施
针对 NRDelegationAttack，本文提出了四种缓解措施
1.  仅考虑referral response中 k 个 NS 记录
   a. 这个缓解措施类似于 NXNSAttack 的缓解方案，但是不同点在于将限制加载 ADB 和缓存搜索阶段，从而避免服务器产生过大的负载，这个方案可以同时修复 NRDelegationAttack 和 NXNSAttack 。
   b.  Bind, Knot 采用这个方案进行修复
2.  在restart事件中不清除No_Fetch标识位
3.  当具有No_Fetch时，就不在 ADB 和缓存中查找referral response。该方案与方案 2 的不同点在于，方案2仅查询k个NS，这时可能造成解析失败，比如域名 example.com 有 7个 NS，而前 6 个都不再提供服务，那么对于使用方案 2 的解析器在查询前 5 个NS失败后将返回给用户解析失败的响应。
4.  缓存不响应查询的服务器，避免解析器多次重复的查询无效的服务器。
图 8 展示了测试环境中前 3 个缓解方案的效果。图 9 展示了 BIND9、Knot 和 Unbound 修复后面对NRDelegationAttack 的负载情况。通过图 8 可以看出，论文提出的 3 个缓解措施都有效的抵御了本文所提的攻击。同时图 9 显示， 缓解措施已经在真实的解析器软件上应用，并取得了很好的效果。

图 8：前 3 个缓解方案的缓解效果

图 9：修复后 BIND9、Knot 和 Unbound 面对 NRDelegationAttack 的负载情况

04

【结论】

面对复杂的 DNS 系统，修复一个漏洞可能会造成其他的影响，甚至会引入新的漏洞。这项研究工作利用修复NXNSAttack 引入的缓解机制，触发了一个新的复杂性 DDoS 攻击，来证明了这样的一个事实，揭示了修复漏洞时所面临的严峻性，将有助于之后在修复相关漏洞时解析器开发者的考虑。

原文链接

https://www.usenix.org/system/files/sec23fall-prepub-309-afek.pdf

开源工具/数据/系统链接Dns full protocol simulator. https://github.com/ShaniBenAtya/dnssim

参考文献

[1] Yehuda Afek and Anat Bremler-Barr and Lior Shafir. NXNSAttack: Recursive {DNS} Inefficiencies and Vulnerabilities. 29th {USENIX} Security Symposium, {USENIX} Security 2020, August 12-14, 2020.[2] ISC. https://kb.isc.org/docs/aa-01463, 2019.[3] https://www.wikiwand.com/en/Algorithmic_complexity_attack

编辑 & 审校 | 王一航、张一铭