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

由于某些运营商利用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解析路径如图一蓝线所示。同时，我们假设路径上的某些设备可能会监控用户的DNS请求流量，并且能够劫持和操纵用户的DNS请求。例如，将满足预设条件的DNS请求转发到中间盒子（Middlebox），并使用其他替代的DNS服务器（Alternative resolver）处理用户的DNS请求；最终，中间盒子通过伪造IP源地址的方式将DNS应答包发往终端用户，此时的解析路径如图一红线所示。   

 图1 威胁模型示意

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

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

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

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

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

我们设计了两个阶段的实验。第一阶段，研究全球范围通过TCP协议传输的DNS数据包，结果在2691个自治域中，198个自治域检测到DNS解析路径劫持，7.36%的DNS数据包受到影响；第二阶段，研究中国范围内通过UDP和TCP协议传输的DNS数据包，结果在356个自治域中，61个自治域检测到DNS解析路径劫持，17.13%的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这两个自治域同属于一家运营商，但是在请求复制类型的比例上也存在明显差异。

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

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

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

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

图3DNS查询性能对比

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

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

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

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

我们在所收集的实验数据中，发现了上百例DNS解析结果被篡改的案例。通过人工分析，导致DNS响应记录被篡改的原因包括：本地流量网关、灰色流量变现、管理员误配置等。例如，图五是我们发现劫持并修改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方案的大规模规范部署和应用。

刘保君，清华大学计算机系博士研究生，导师段海新教授与刘莹教授，曾在UC Berkeley 访问研究，在Vern Paxson教授指导下工作。主要研究方向为网络基础设施安全，包括DNS、Web、CDN等系统的安全以及地下产业检测。现有学术论文发表于USENIX Security、DSN等网络安全会议。

[1] Liu, B., Lu, C., Duan, H., Liu, Y., Li, Z., Hao, S., & Yang, M. Who Is Answering My Queries: Understanding and Characterizing Interception of the DNS Resolution Path. In USENIX Security (2008).

[2] DAGON, D., PROVOS, N., LEE, C. P., AND LEE, W. Corrupted dns resolution

paths: The rise of a malicious resolution authority. In NDSS (2008).

[3] WEAVER, N., KREIBICH, C., NECHAEV, B., AND PAXSON, V. Implications of netalyzr dns measurements. In Proceedings of the First Workshop on Securing and Trusting Internet Names (SATIN), Teddington, United Kingdom (2011).

[4] WEAVER, N., KREIBICH, C., AND PAXSON, V. Redirecting dns for ads and profit. In FOCI (2011).

[5] KUHRER, M., HUPPERICH, T., BUSHART, J., ROSSOW, C., AND HOLZ, T. Going wild: Large-scale classification of open dns resolvers. In Proceedings of the 2015 ACM Conference on Internet Measurement Conference (2015), ACM, pp. 355–368.

[6] CHUNG, T., CHOFFNES, D., AND MISLOVE, A. Tunneling for transparency: A large-scale analysis of end-to-end violations in the internet. In Proceedings of the 2016 ACM on Internet Measurement Conference (2016), ACM, pp. 199–213.

[7]Is your ISP hijacking your dns traffic? https://labs.ripe.net/Members/babak_farrokhi/is-your-isp-hijacking-your-dns-traffic.

[8]Avast secure DNS. https://help.avast.com/en/av_abs/10/etc_tools_secure_dns_overview.html.

[9]Cisco umbrella intelligent proxy.

https://learn-umbrella.cisco.com/feature-briefs/intelligent-proxy.

[10] ZDNS: Solutions for campus network services. http://free.eol.cn/edu_net/edudown/2017luntan/zdns.pdf.

[11]The practice of DNS traffic control based on out-of-band responder

Mechanism. http://www.ttm.com.cn/article/2016/1000-1247/1000-1247-1-1-00064.shtml.

[12] Cisco: DNS configuration guide. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dns/configuration/12-4t/dns-12-4t-book/dns-config-dns.html.

[13] Hu, Z., et al. Specification for DNS over transport layer security (TLS). No. RFC 7858. 2016.

[14] ACM Technews. How Often Are Users' DNS Queries Intercepted? https://technews.acm.org/archives.cfm?fo=2018-08-aug/aug-24-2018.html.

[15] The Resigter. How's that encryption coming, buddy? DNS requests routinely spied on, boffins claim. https://www.theregister.co.uk/2018/08/20/dns_interception/.

[16] HackRead. Hackers can intercept and manipulate DNS queries, researchers warn. https://www.hackread.com/hackers-can-intercept-and-manipulate-dns-queries-researchers-warn/.

[17] Rambler. Most DNS queries can be easily intercepted, experts say.https://news.rambler.ru/other/40604197-bolshinstvo-dns-zaprosov-legko-perehvatit-schitayut-eksperty/.