谁劫持了我的DNS：全球域名解析路径劫持测量与分析

文/刘保君

或许你已知道网络中几乎所有的DNS请求都是通过明文进行传输的，但是你是否相信，这一协议设计的缺陷，已经开始被用于域名解析路径劫持了？

问题背景

论文“Who Is Answering My Queries：Understanding and Characterizing Interception of the DNS Resolution Path”[1]，发 表 于USENIX Security 2018（网络安全领域国际四大顶级学术会议之一）。

由于某些运营商利用DNS 解析服务器植入广告等盈利行为，运营商的DNS解析服务器一直备受质疑[2～6]， 而公共DNS 服务器（如Google 的8.8.8.8）因其良好的安全性与稳定性被越来越多的互联网用户所信任。然而，我们发现这层信任关系会轻易地被DNS 解析路径劫持所破坏。网络中的劫持者将用户发往指定公共DNS 的请求进行劫持，并转发到其他的解析服务器。除此之外，劫持者还会伪装成公共DNS 服务的IP 地址，对用户的请求进行应答。从终端用户的角度来看，这种域名解析路径劫持难以被察觉。我们设计并部署了一套测量平台用于检测全球范围的DNS 解析路径劫持现象。

主要研究结论

1.劫持的规模：在全球3047 个自治域中，我们在259 个自治域内发现了DNS 解析路径劫持现象。特别是在中国，近三成发往谷歌公共DNS 服务器的UDP 流量被劫持。

2. 劫持特点：在不同的自治域中，路径劫持策略和特点有着明显差异。整体而言，通过“UDP”协议传输发往“知名公共DNS 服务器”的“A 记录类型”的数据包更容易成为劫持目标。

3.安全威胁：我们不仅观测到劫持设备会篡改DNS 响应结果，而且，通过对劫持者所使用的DNS 服务器的分析，发现其功能特性和安全性均存在隐患。

4. 劫持目的：DNS 解析路径劫持的主要目的是减少运营商网间流量结算成本，而非提高用户DNS 服务器的安全性或优化DNS 查询的性能。

5. 解决方案：解决DNS 解析路径劫持的最佳方案是，在推进DNSSEC 大规模规范部署的同时，加快DNS 加密方案的实施。

威胁模型

我们首先阐述所关注的威胁模型。部分网络用户可能选择使用公共DNS 服务器，正常情况下，其DNS 解析路径如图1 蓝线所示。同时，假设路径上的某些设备可能会监控用户的DNS 请求流量，并且能够劫持和操纵用户的DNS 请求。例如，将满足预设条件的DNS 请求转发到中间盒子（Middlebox），并使用其他替代的DNS 服务器（Alternative resolver）处理用户的DNS 请求；最终，中间盒子通过伪造IP 源地址的方式将DNS 应答包发往终端用户，此时的解析路径如图1 红线所示。

图1 威胁模型示意

通过对DNS 数据包“请求阶段”中的解析路径进行划分，将DNS 解析路径分为四类。首先是正常的DNS 解析路径（Normal resolution），用户的DNS 请求只到达指定的公共DNS 服务器；此时，权威服务器应当只看到一个来自公共服务器的请求。剩下三类均属于DNS 解析路径劫持：第一类DNS 路径劫持方法是请求转发（Request redirection），用户的DNS 请求将直接被重定向到其他的服务器，解析路径如图2 红线所示；此时，权威服务器只收到来自这个服务器的请求，用户指定的公共DNS 服务器完全被排除在外；第二类方法是请求复制（Request replication），用户的DNS 请求被网络中间设备复制，一份去往原来的目的地，另一份去往劫持者使用的解析服务器，解析路径如图2 黄线所示，此时，权威服务器将收到两个相同的查询；第三类方法是直接应答（Direct responding），用户发出的请求同样被转发，但解析服务器并未进行后续查询而是直接返回一个响应，解析路径如图2 蓝线所示，此时，权威服务器没有收到任何查询，但是客户端却收到解析结果。

图2 DNS 解析路径类别（仅考虑请求阶段）

我们注意到，可能造成DNS 解析路径劫持的设施种类较多，不仅包括运营商部署的中间盒子[7]，还包括恶意软件、反病毒软件[8]、防火墙以及企业代理[9]等。在这项研究中，重点关注如何检测这种现象，因此不对劫持者进行区分。

测量分析

对于DNS 解析路径劫持现象，我们在测量分析中依次回答了下列问题：

1. DNS 解析路径劫持规模有多大？

我们设计了两个阶段的实验。第一阶段，研究全球范围通过TCP 协议传输的DNS 数据包，结果在2691 个自治域中，有198 个自治域检测到DNS 解析路径劫持，7.36%的DNS 数据包受到影响；第二阶段，研究中国范围内通过UDP 和TCP协议传输的DNS 数据包，结果在356 个自治域中，有61 个自治域检测到DNS 解析路径劫持，17.13%的DNS 数据包受到影响。

图3 DNS 查询性能对比

特别是在中国网络中， 通过UDP 协议发往Google 公共DNS 的数据包，有27.9%受 到DNS 解析路径劫持的影响（通过TCP 传输时为7.3%）；相比而言，对于不知名的DNS 服务器，同样也有9.8%的数据包受到影响（通过TCP 传输时为1.1%）。

2. DNS 解析路径劫持有什么特点？

——路径劫持类型层面的特征我们发现，直接应答劫持方式（Direct responding）极少发生。这很可能是因为此时的响应结果明显是不正确的。此外，请求转发（Request directing）的比例要高于请求复制（Request replication）的比例。

——自治域层面的特征

在每个自治域内，解析路径劫持的特点差别巨大，即使在同一个自治域内，由于劫持者的多样性，整体表现出的劫持特征也会较为复杂。 例如，在表1 选取的案例中，AS9808 和AS56040 这两个自治域同属于一家运营商，但是在请求复制类型的比例上也存在明显差异。

3. 劫持现象对DNS 查询性能有什么影响？

（1）不同类型的解析路径劫持对DNS 查询性能有什么影响？

将各DNS 请求完成的时间（Round trip time， RTT）进行累积分布作图，得到图3。相比于未被劫持的请求（绿色曲线），我们发现通过请求复制（红色曲线）的劫持方式确实能够提高DNS 查询的性能，总体的查询时间更短；但是通过请求转发的方式（黄色曲线）不能够稳定地实现这一目标。另外，我们向用户的本地DNS 服务器（Local DNS resolver）发送一个DNS 数据包用于作性能对比，结果显示其性能曲线（蓝色）与请求转发的性能曲线高度近似。

表1 DNS 解析路径劫持在不同自治域内的特点

图4 复制抢答式路径劫持性能分析

（2） 对于请求复制这一场景，哪一个查询数据包会更先到权威服务器？

当劫持者使用请求复制（Request replication）方式劫持解析路径时， 如果从权威服务器的角度观测，原始的DNS请求和复制的DNS 哪个会更先到达权威服务器。图4 显示对这一时间差异的分析。对于大部分的自治域而言，复制后的DNS请求会更先到达权威服务器，然而我们仍然发现了一个属于中国电信的自治域，其中所有被复制后的请求均比原始请求要慢。由此推测，这种现象可能是由于自治域内设备部署不当引起的，或是此时的DNS 数据包经过了更长的路由导致的。

4. 劫持者是否会篡改DNS 响应数据包内容？

在所收集的实验数据中，我们发现了上百例DNS 解析结果被篡改的案例。通过人工分析，导致DNS 响应记录被篡改的原因包括：本地流量网关、灰色流量变现、管理员误配置等。例如，图5 是我们发现劫持并修改Google 公共DNS 服务器响应内容一个案例，劫持后的网页内容为一款移动APP 的推广信息。

5. 路径劫持会带来哪些安全威胁？

——道德与隐私风险

劫持者很可能在未征得用户同意的情况下，篡改用户的DNS 访问，不仅带来了道德问题，而且给用户的隐私来了风险。

图5 某运营商劫持DNS 流量示例

——网络故障

劫持者的行为使得用户的网络链路更加复杂，当出现故障时难以排除。

——DNS 功能特性

替代DNS 服务器可能缺乏DNS 的某些功能特性，例如，根据终端子网返回最优的IP 地址的选项（EDNS Client Subnet，ECS）。

—— DNS 服务器安全性

劫持者所使用的替代DNS 服务器往往不遵守最佳安全实践。例如，我们发现仅有43%的替代DNS 服务器“接受”DNSSEC 请求；而且，所有使用BIND 软件的替代DNS 服务器版本都严重落后（全部低于BIND 9.4.0，应当于2009年过期）。

6. 劫持背后的目的是什么？

我们调研了大量设备提供商与软件提供商，整理出一份能够提供DNS 解析路径劫持功能的厂商列表[10～12]。同时收集产品的功能介绍信息并结合实际测量结果，推测劫持背后的目的。

（1）提高用户DNS 服务器的安全性。我们观测到发往知名公共DNS 的数据包更容易被劫持，而且相当一部分劫持者使用的解析服务器可能存在安全问题。因此，该结论虽然不能完全排除，但我们认为不是劫持的主要目的。

（2）优化用户的DNS 查询性能。我们发现请求复制式劫持能够提高DNS 查询性能；但在实际网络中，劫持者更多的是采用请求转发的方式。因此，大部分的劫持并不是为了优化DNS 查询性能。

（3）减少运营商网间流量结算成本。发往公共DNS 服务器的异网流量对中小型运营商而言，提高了运营商的流量结算成本。通过对异网DNS 流量进行管控，可以有效节省网间流量结算成本。 因此，我们倾向于认为这是DNS 解析路径劫持的主要原因。

解决方案

解决DNS 解析路径劫持的最佳方案是在部署DNSSEC 的基础上，推进DNS加密方案的部署。 DNSSEC 能够解决DNS 响应记录内容被中间盒子篡改的问题，部署DNSSEC 可以保证终端用户拿到正确的响应结果。 然而，此时DNS 流量仍然通过明文传输，存在隐私隐患。DNS 加密方案，包括DNS-over-TLS[13]、DNS-over-HTTPS 等，不仅解决明文传输时的隐私威胁，而且可以对用户所使用的DNS 服务器进行认证，进而最终解决劫持者伪装公共DNS 服务器的问题。

目前，Firefox 浏览器从第62 版本开始支持DNS-over-HTTPS。此外，越来越多的公共DNS 服务器和知名DNS软件开始逐步支持不同的DNS 加密方案，其中公共DNS 服务器包括Google、Cloudflare、Quad9 等，知名的DNS 软件包括BIND、Unbound、Knot、CoreDNS 等。

在这项研究中，我们系统地分析了DNS 解析路径劫持这一威胁。通过全球范围的大规模测量研究，分析了其规模、特点、安全威胁以及目的。在论文发表后，多个国际知名安全媒体对研究内容进行了报道，包括ACM TechNews、The Register、HackRead、HelpNet Security 和 Rambler[14～17]等。希望这项研究结果，能够进一步推进DNSSEC 和加密DNS 方案的大规模规范部署和应用。