Who Is Answering My Quries:Understanding and Characterizing Interception of the DNS Resolution Path

来自终端用户的DNS查询由递归DNS服务器处理，以实现可伸缩性。为了方便起见，当客户端选择默认的网络设置时，Internet服务提供商（ISPs）自动的为其客户分配递归服务器。但是用户也应该有使用他们喜欢的递归服务器的灵活性，比如使用公共DNS服务器。然而，这种信任可能被隐藏的DNS解析路径的拦截（我们称之为DNS拦截）所破坏。具体来说，沿路的设备可能冒充用户指定的DNS服务器的IP地址，并暗中拦截DNS查询，从而带来隐私和安全问题。

在本文中，我们进行了大规模的沿途DNS拦截分析，并阐明了其范围和特点。我们设计了新颖的方法去检测DNS拦截，并利用全球148 478个住宅和蜂窝IP地址进行分析。结果是，我们发现在我们调查的3047个自治系统中有259个表现出DNS拦截行为，包括像中国移动这样的大型提供商。此外，我们发现拦截请求的自治系统DNS服务器可能使用过时的易受攻击的软件（2009年以前已经弃用）并且缺乏安全相关的功能，如处理DNSSEC请求。我们的工作突出关于路径上DNS拦截的问题并且为解决这些问题提出了新的见解。

1 介绍

域名系统（DNS）为因特网应用提供了一项关键的服务——将人类可读的域名解析为数字的IP地址。几乎每一个因特网连接都需要提前进行地址查找。因此，DNS故障将会严重影响用户使用互联网服务的体验。以往的研究表明，流氓DNS[38,42]，DNS透明代理和未经授权的根域名服务器可能破坏互联网通信的完整性和可用性。

在这项工作中，我们研究了一个关于DNS的新问题，即DNS解析路径被沿途设备隐藏拦截，这是以前的工作所没有完全研究和理解的。来自客户端的DNS查询通过递归域名服务器处理，以提高因特网的性能并且减少因特网上的流量拥塞。在默认的配置下，用户的递归域名服务器指向由网络服务提供商控制的域名服务器。另一方面，用户应该有选择他们自己的DNS服务器或者公共递归域名服务器的灵活性，如谷歌公共DNS8.8.8.8。然而，我们发现沿途设备拦截发往公共DNS的DNS查询，并且偷偷的使用替换了的递归域名服务器解析的DNS应答作为回应。沿途设备欺骗在DNS响应中用户指定的递归域名服务器的IP地址，比如使用谷歌公共DNS的8.8.8.8替换解析IP地址，这样用户不会注意到DNS解析路径已经被操纵了。

DNS拦截的目的包括显示广告（如通过NXDOMAIN响应的操作），收集统计数据和组织恶意软件连接等等。但是，这种做法可能会引起多方面的关注：（1）未经用户允许的拦截和很难在用户一方检测这些将导致伦理担忧；（2）用户对备选递归DNS服务器存在较高的信任风险，与知名公共DNS服务器相比，备选递归DNS服务器通常缺乏适当的维护（比如配置过时的DNS软件）。（3）某些安全相关的功能受到影响甚至破坏，比如一些备用DNS解析器不提供DNSSEC。

本文对DNS拦截进行了大规模分析。我们的研究调查了这个问题的严重性，描述了DNS拦截的各个方面，并且检测了对终端用户的影响。最后我们提供了缓解问题的见解。

挑战。系统的分析DNS拦截主要有两个挑战。首先是获取来自不同自制系统（ASes）的客户端来进行大规模的测量，这些也允许对测量参数微调。以前的作品提出的测量框架不能同时满足条件，包括广告网络[33]，HTTP代理网络[19,36,37,52]，和互联网扫描仪[42,48]。另一个挑战是去核实DNS解析式被拦截了还是到达用户指定的递归域名服务器。因为沿途设备可能欺骗DNS响应中的IP地址，仅从客户端很难感觉到DNS拦截的存在。

我们的方法。为了应对这些挑战，我们设计了一种新的测量方法并且将其应用于两种不同的大规模实验，即全球分析和全中国分析。对于全球分析，我们使用了一个基于TCP SOCKS（而不是HTTP）的住宅代理网络，它提供了173个国家的36173个独特的住宅住宅IP地址。这让我们可以从世界范围的角度理解DNS拦截。然而，这个代理网络只允许我们通过TCP SOCKS发送DNS数据包。为了了解更全面的特征，我们和一家领先的安全公司合作，该公司为数百万活跃的移动用户提供网络测试工具。我们从112305个IP地址（分布在356个自治系统中）获取UDP和TCP之上的DNS流量，这些流量主要来自中国。

为了去检测DNS拦截流量，我们注册了一组域（像OurDomain.TLD)并且使用被我们控制的权威域名服务器处理解析。每一个客户端被指示发送DNS包到一个DNS服务器列表中，并且在我们的域名下查询临时的子域，我们的域名如UUID.Google.OurDomain.TLD（我们使用Google来指示将DNS请求发送到谷歌公共DNS）。需要注意的是，我们不改变客户机的DNS配置，而是直接将DNS请求发送到公共DNS服务器。由于每一个子域UUID都是不存在的，因此任何级别的DNS缓存都无法解析，必须通过DNS服务器层次结构。在我们操纵的权威域名服务器上，我们记录IP地址，这个地址是我们控制查询子域名得来的。通过检查IP地址是否属于最初请求的公共DNS服务，我们可以了解DNS解析是否被替代的解析器截获。根据Alexa流量排名[57]，我们选择三个流行的公共DNS服务器作为研究目标，包括Google公共DNS[12],OpenDNS[22],Dynamic DNS[9]，此外，我们自己建立了一个名叫EDU DNS的公共DNS服务器来进行比较。

我们的发现。在这项工作中，我们有以下关键的发现。

在我们调查的3047个自治系统中，有259个自制系统（8.5%）发现被拦截，包括像中国移动这样的大型提供商。另外，中国对谷歌公共DNS的UDP DNS请求中有27.9%被拦截。
拦截策略因不同类型的DNS流量而异。特别地，对UDP的DNS查询以及发往知名公共DNS查询的A类记录的DNS查询更可能被截获。
拦截器使用的DNS服务器可能使用过时的软件，例如，我们确定的所有97个DNS服务器都安装了2009年后就应该弃用了的旧的BIND软件，并且容易受到像DoS[6]等的攻击。而且，有57%的DNS服务器不接受 DNSSEC请求。
DNS拦截对于终端用户来说限制了性能发展。事实上，对于公共DNS服务的UDP DNS流量，有15.37%甚至比替代DNS服务器发出的流量还要快。

贡献。我们研究的贡献总结如下。

理解：我们系统的测量了DNS拦截，它欺骗用户指定的DNS服务器的IP地址，以便暗中拦截DNS流量。
方法：我们设计了新颖的方法来进行大规模分析，通过全球148478个住宅和蜂窝IP地址来描绘DNS拦截。
发现：我们发现在一些著名的ASes中存在隐藏的拦截行为，包括属于中国移动等这样的大型提供商。我们的研究结果表明拦截器使用的DNS服务器通常很少有安全维护，并且容易受到攻击，这可能会破坏终端用户DNS解析的完整性和可用性。
检测工具：我们在http://whatismydnsresolver.co[25]发布了在线检测工具来帮助因特网用户检测DNS拦截。

2 危险模型和机制

在本节中，我们首先概述如何使用DNS将域名转换为地址。然后我们介绍我们的DNS拦截威胁模型，根据我们的观察，我们对拦截路径进行了分类。最后，我们讨论一下潜在的拦截器及其行为。

2.1领域解析过程

DNS是一种分级命名系统，用于处理不同级别的域解析。在层次结构的顶部是DNS根，它管理顶级域（TLD）解析。二级域（SLD）委托给DNS根目录下的解析器。全限定域名（FQDN）由来自所有域级别的标签组成，全限定域名（FQDN）指定其在DNS层次结构中的确切位置，从最低级别到根。例如：www.example.com是一个FQDN，其对应的TLD和SLD是com和example.com。

当客户端请求域的解析时，解析通常首先由递归DNS解析器执行，该解析器可以由ISP分配或者由Internet用户指定。如图1所示，递归解析器迭代地联系根、TLD 和SLD名称服务器来解析域名，并最终将答案返回给客户端。因此，将DNS流量拦截到递归解析器直接影响到用户的域解析过程。

2.2威胁模型

图2展示了我们的威胁模型。我们假设用户的DNS解析请求被沿途设备监视了。这些沿途设备能够拦截和选择性操纵DNS请求的路由（例如，通过检查目的地和端口），这些请求本来是要发送到递归解析器，如公共DNS服务器。沿途设备将请求重定向或者复制到执行标准解析过程的替代解析器（通常是本地DNS解析器）。最后，在将替代解析器的响应发送回客户端之前，将源替换为原来的解析器的地址。因此，从客户端的角度来看，DNS响应根据他们的源地址来看似乎是来自于最初的DNS解析器，这使得实际的拦截行为难以识别。

默认情况下，为了处理DNS请求，ISP为Internet用户分配本地DNS解析器。同时，用户保留指定首选递归解析器以启动DNS请求（特别是公共DNS服务器）的权利。然而，我们的研究表明对于使用指定DNS服务器的用户来说，DNS拦截不仅违背了用户的意愿，而且它也可能带来安全问题。

研究的范围。我们的目标是通过大规模的数据分析来测量和描述DNS拦截。我们聚焦于在客户端和知名公共DNS解析器之间的DNS解析路径如何被篡改。其他类型的网络流量操纵机制，比如BGP前缀拦截和未经授权对DNS根服务器进行操作，这些在之前已经系统的研究过了，这里我们不再研究。

DNS解析路径的分类。在本研究中，我们根据请求阶段解析路径的构造，将DNS解析机制分为四类。除正常解析外，其余三种情况都视为DNS拦截。图3显示了四种DNS解析机制的DNS请求路径。

正常的请求。解析严格遵循标准程序。客户端发送的DNS查询只到达指定的解析器，未经任何沿途设备的修改。如果解析没有被缓存，指定解析器通过联系权威域名服务器来执行解析。
请求重定向。发送到用户指定的解析器的原始DNS查询被扔掉。同时，采用替代的解析器进行解析。指定的解析器完全从解析过程中移除。
请求克隆。发送到用户指定的解析器的DNS查询没有被修改或者阻塞。但是，请求被沿途设备复制，并且由另一个解析器同时处理。因此，权威域名服务器从用户指定的解析器（即in-band请求）和替代解析器（即out-band请求[46]）收到两个确认请求。当返回多个响应时，客户端通常会接收最快的响应。
直接回应。和请求重定向类似，用户的DNS请求被沿途设备重定向到替代的解析器，而没有到达指定的解析器。但是，即使对于没有缓存的域，替代解析器也直接响应用户，而不再联系任何其他的名称服务器。

2.3潜在的拦截器

有趣的是，沿途设备主要由网络运营商（像ISPs）部署，以拦截DNS流量[16]。但是，同样的拦截也可以由如下所述的其他人进行。我们设计了自己的测量方法以减少触发研究所不想要的拦截的机率。然而，我们承认，由于我们的方法和优势点的限制，其他拦截器不能被完全移除。

审查和防火墙。为了组织访问某些网站（如有关政治的和色情网站），审查人员和防火墙可以操纵DNS查询的路径，并返回虚假的响应。正如之前工作的研究[28]，这种DNS拦截通常发生在域名包含敏感关键字或者匹配黑名单时。我们通过在DNS请求中嵌入一个正常的域名来尽量避免这种类型的拦截。
恶意软件和反病毒（AV）软件。和钓鱼网站的目的类似，恶意软件可以改变其主机的DNS解析器的配置，并将DNS重新路由到流氓解析器[38]。另一方面，AV软件也可能拦截DNS请求，以防止客户端DNS请求被劫持。例如，Avast AV软件通过使用加密通道[3]将DNS请求从客户机从新路由到自己的DNS服务器来提供这种功能。在这两种情况下，解析器都可能直接由恶意软件和反病毒软件的操作人员控制，这些软件由云提供商或者专门托管服务托管。
企业代理。大量企业部署网络代理来规范员工设备和互联网之间的通信。一些代理能够仔细检查DNS请求并决定是否允许相应的web访问，比如 Cisco Umbrella intelligent proxy。和反病毒设置类似，用户需要将他们的DNS解析器指向代理的解析器。

由于解析器的IP地址与其所有者之间的映射是我们所不知道的，所以我们的研究包括网络服务商以外的各方拥有的替代解析器，比如反病毒软件和企业代理解析器。直接使用自制系统信息进行分类并不总是可靠的。例如，如果企业租用ISP的子网，那么企业解析器就可能被错误的归类为ISP解析器。我们现在正在开发一种方法来实现精确解析器分析以解决这个问题。

3 方法和数据集

在本节中，我们描述了我们研究的方法和数据收集，试图解决第一节中描述的两个主要挑战。首先我们描述我们方法的高级概念和它需要满足的设计需求。然后我们详细阐述度量框架的每个组件，以及如何获取大量全球分布有利位置。最后讨论了有关数据收集的伦理问题。

3.1 概述

首先说明我们识别DNS拦截的方法，包括请求重定向、请求克隆、和直接响应。

方法。检测DNS拦截在概念上很简单。回顾正常的解析，当从客户端收到请求时，如果结果没有被缓存，递归解析器就会试图联系权威域名服务器以获得答案。然而，正如图3所示，当拦截发生时，请求被替代解析器转发到权威名服务器。

因此，我们识别拦截的方法包括以下步骤。（1）我们指示一个客户端向公共解析器A发送关于我们控制的域的DNS请求，（2）在我们的权威名服务器上记录其相应的请求，该请求来自递归解析器B，（3）将A与B比较。作为补充步骤，我们还（4）验证客户端最终收到的响应。

只有当A和B匹配时，认为请求是正常解析的。否则，对于客户端发送为公共解析器A的每一个得到有效响应的请求，（1）如果没有相应的请求被权威名服务器捕获，我们将其视为直接响应；（2）如果捕获的不是来自解析器A的耽搁请求，我们将其视为请求重定向；（3）如果来自解析器的多个相同的请求（其中一个是A）被捕获，我们将其视为请求克隆。

设计要求。我们的方法应满足几个要求，以获得有效的结果。

第一，每个来自客户端的请求的查询域名应该相异，以避免缓存。第二，当我们从客户端和权威命名服务器分别铺货数据包时，我们应该能够将来自客户机的请求与权威命名服务器在相同解析度下捕获的请求关联起来。正如将在3.2节讨论的那样，这两个问题通过对每个请求设置唯一前缀来解决。

第三，我们的研究中的客户端应该是多样化的，即使本地DNS解析器已经由ISP分配，也能够将DNS数据包直接发送到指定的公共解析器。第四，为了深入的研究拦截特性，期望优势点能够解决不同的DNS请求（例如，不同传输协议和不同RR类型的请求）。之前研究中使用的度量基础框架都不符合要求，包括广告网络[33]、HTTP代理网络[19,36,37,52]，和互联网扫描器[42,48]。如何处理这两个问题将会在3.3节中讨论。

最后，使用anycast地址（如谷歌的8.8.8.8）被客户端访问的公共DNS服务。当请求被转发到我们的权威命名服务器时，这些地址很少能与单播地址匹配（比如，谷歌的74.125.41.0/24）。我们提出了一种识别公共DNS服务出口IP的新方法，将在第3.2节中详细介绍。

3.2 方法

在介绍我们的方法之前，我们先用拦截器可能考虑的元素来描述一个拦截模型。在此基础上，我们详细阐述如何生存DNS请求以及如何识别公共DNS服务的出口IP。拦截模型。部署在路径上的设备来检查和操作DNS包。我们认为每个DNS包由五个字段的元素表示：

{Src IP, Dst IP, Protocol , RR Type, Requested Domain}

每个字段都可以决定如何进行拦截。因此，要全面了解DNS拦截，我们需要具有不同字段的DNS数据包。为此我们构建了一个拥有大量分布在全球的源IP的客户机池（即客户机IP）。目标IP指向我们指定的公共DNS解析器。调查所有的公共解析器将花费大量的时间和资源，因此我们根据Alexa流量排名[57],将范围缩小到三个具有代表性和广泛使用的公共DNS服务，包括谷歌公共DNS[12]，OpenDNS[22]和Dynamic DNS[9]。作为补充，我们还包括了一个自检的公共DNS服务，名为EDU DNS，以进行比较。传输协议可以是TCP或者UDP。对于资源记录（resource record，RR)，我们考虑了五种安全相关的记录，包括A，AAAA，CNAME，MX和NS。最后，我们专门为我们的研究注册了四个域名，涵盖四个TLDs，包括一个新的gTLD（com，net，org和club）。我们避免任何含有敏感字的域名。

生成DNS请求。在本研究中，我们需要解决客户端请求与其相应请求之间的源IP不一致的问题，该问题应该是递归解析器引起的。为此我们设计了一种通过唯一域前缀链接这些请求的方法。前缀包括为每个客户端生成的唯一UUID（代表源IP）和用于处理解析的公共DNS服务标签（代表目的IP）。通过同时考虑RR类型，我们能够以相同的解析度识别DNS包。例如，当客户端发起了一个DNS A类请求UUID.Google.OurDomain.TLD时，这个请求应该由Google公共DNS处理。权威命名服务器捕获的相应请求也应该是A类型的，并且能匹配域前缀中的每个标签。

生成DNS响应。在请求克隆情形中，客户机接收in-band响应和out-band响应。我们我们想要对这两种情况进行分类，但是权威命名服务器的常规响应无法区分这两种情况。因此，我们需要一个可靠的机制将客户机接收到的响应和权威命名服务器的响应链接起来。与前面的组件类似，我们在响应中编码了一个唯一的场景。特别地，我们的权威命名服务器将时间戳，源地址和请求的域名一起哈希，并从哈希字符串匹配到记录类型中生成唯一的响应。例如，一旦收到一个A类型的请求，响应则是一个从哈希值转换过来的IPv4地址（使用哈希的最后32位二进制位）。

需要注意的是，通过这种方法合成的响应可能将客户机指向一个未知的服务器。例如，僵尸网络服务器可能偶尔使用响应IP。我们想要强调的是，因为客户端的行为只不过是DNS查找，所以这不会对我们的优势点造成实际的伤害。这里没有对服务器进行后续连接。

解析器能够根据权威名称解析器及其策略返回的内容操纵响应的TTL值。我们尝试通过选择一个介于1到86400之间的随机TTL值来度量这个场景。

识别公共DNS的出口IP。我们的下一个任务是识别与我们权威命名服务器联系的源IP是否属于公共DNS服务，即，是一个出口IP。从客户端的角度来看，anycast地址是可访问的，它本质上代表了一组递归解析器前面的代理。这种设计是为了负载均衡。然而，关联解析器的单播地址（由我们的权威命名服务器监视）通常与他们的anycast地址不匹配。anycast地址的所有者通常不为公众所知。因此，我们需要推断出所有者身份。

先前的研究利用IP WHOIS数据和来自公共论坛的信息[37,49]来识别出口IP，当我们对数据进行检查时，这些这些IP不够精确。我们提出了一种利用DNS PTR和SOA记录的更为可靠的方法。我们的方法基于一个假设，即公共DNS服务倾向于使用多个网络前缀（例如/24网络）聚合的地址，而不是分散的IP地址。因此，为了便于管理，网络管理员通常将IP地址的标识信息嵌入PTR和SOA记录。我们根据Alexa流量[57]排名前12的公共DNS服务，从5个自治系统不同位置优势位置验证了这一假设，并发现所有12个DNS服务都将身份信息嵌入到PTR（如Norton ConnectSafe）或者SOA记录（如Freenom），或者两者（如OpenDNS）。例如，对谷歌公共DNS的出口IP反向查找的响应都是 dns-admin.google.com。

实际上，对于与我们的权威命名服务器联系的IP，我们首先执行它的反向DNS查找。随后，我们递归的请求响应域名的SOA记录，并构建其SOA依赖项（5次迭代），类似于[43]。如果依赖链中存在特定的SLDs（例如opendns.com），我们将改地址视为响应公共DNS服务的出口IP。例如，PTR中45.76.11.166这个记录（AS20473；Choopa，LLC）是hivecast-234-usewr.as15135.net。这个域名的SOA记录是ns0.dynamicnetworkservices.net，因此我们将45.76.11.166视为Dynamic DNS的出口IP。

使用这种方法，我们可以推断和我们权威命名服务器连接的85%的地址的所有者身份。同时，和IP WHOIS方法相比，我们的方法发现了新的公共DNS服务的出口ASes。例如，发现AS20473（使用Dynamic DNS）和AS30607（使用OpenDNS）是ASes出口。但是使用IP WHOIS和BGP信息方法都没有发现他们。

讨论。正如2.3节所讨论的，我们的方法可能无法准确的区分拦截是网络运营商还是其他的拦截器引起的。其次，通过给替代解析器设置虚假的PTR和SOA记录，将无法准确识别它们的出口IP。但是，应该从Passive DNS数据中观察到这些隐秘的变化，例如Farsight[10]和DNS Pai[15]管理的数据。目前，由于访问限制，我们没有包含Passive DNS数据，之后的工作会考虑加入。同时，在以往的研究中，PTR记录被证明是一个可靠的IP地址分类来源。例如，[48]使用PTR记录来识别特定CDNs上托管的域。

3.3 优势点

我们的研究需要大量分布在全球的客户端。此外，我们的客户端应该能够向指定的公共解析器发送关于域的定制DNS请求。为此，我们首先利用一个基于TCP SOCKS的住宅代理网络（它允许我们直接从全球分布的客户端发送DNS包）来描述DNS拦截的全球场景（这个阶段称为全球分析）。然而这个实验不能揭示DNS拦截的全部特征，因为代理网络不允许我们改变DNS请求的每一个字段。因此，我们和我们的合作伙伴（开发了有数百万活跃用户的安全软件）合作设计了另一个实验。我们实现了一个测量脚本，并将其集成到软件的网络调试模块中。当更改交付到客户端时，将显示同意，并且直到客户端确认更改后才执行脚本。由于本次实验的客户端主要没来自中国，我们将其命名为China-wide analysis。

全球分析。以往的研究都使用代理网络作为度量优势点[37,52]。但是，从这些代理网络下的客户端发送出去的DNS请求只允许预先分配的本地DNS解析器，这并不满足我们的要求。为了解决这个问题，我们使用一个名为ProxyRack[14]的SOCKS代理网络，它允许我们通过TCP向任何指定的解析器发送定制的DNS请求。

ProxyRack的网络结构如图4所示。它通过超级代理与我们的测量客户端进行交互。当我们的机器发送DNS包时，它们进入附属节点，最后从不同的出口节点离开网络。DNS包被转发到应该和我们的权威域名服务器连接的递归解析器上。因此，我们的客户机池实际上是由这些出口节点组成。ProxyRack已经征募了超过100k的节点[14]，因此我们可以通过与超级代理交互，将DNS请求从全球分布的节点发送到公共解析器，并验证响应。但是，ProxyRack仅接收TCP上的DNS请求，在实际的设备中，只有一小部分DNS请求使用TCP。因此，我们进行了下一个实验来测量UDP和其他因素上的拦截。

全中国分析。我们与一家开发了移动安全软件并拥有数百万用户的国际安全公司合作。该软件已经在安装时被授予了发送任意网络请求的权限，因此我们能够收集详细的DNS数据。

这个实验的主要担忧是道德和隐私，我们小心翼翼地解决了这些问题，下边简单介绍一下（更多细节将在3.5节中介绍）。首先，我们实现测量脚本（发送和接收DNS包）的模块得到了用户的同意，并且软件必须在获得用户许可的情况下手动运行。其次，虽然从客户端发送不同的DNS请求帮助我们全面了解DNS拦截的特性，但是我们尽量避免在用户设备上产生过多的流量。这些选择限制了DNS请求的多样性。最后，我们的脚本只捕获为本研究专门注册的域的DNS数据包，因此像发送到社交网络的请求这样的被视为隐私的数据是不会被收集的。

DNS包的分布。根据我们前面描述的初始模型，为了生成尽可能多的不同的DNS包，我们应该在所有四个不同的SLDs下，所有五种RR的类型，通过TCP和UDP，以及到所有四个公共DNS服务，从客户端启动DNS请求。然而，因为道德上的考虑和优势点的限制，我们认为这是困难的。

在全球分析阶段，ProxyRack仅接收TCP流量。同时，代理网络有提交请求的速率限制，所以我们在处理DNS请求时必须小心。因此，从客户端到所有四个公共DNS服务，我们只请求DNS A记录，这是使用基于TCP查找的com域名中最常见的RR类型。

在全中国分析阶段，虽然从软件客户端发送请求更加灵活和高效，但我们应该限制我们请求的数量以避免过多的流量。因此，对于每个客户机，我们考虑随机选择两个公共DSN服务、两个TLDs、一个传输协议，以及所有五种RR类型。此外，我们还向本地DNS解析器发送一个请求。

3.4 数据集

表1总结了我们在两个阶段收集的数据集。我们总共从全球148478个不同住宅和蜂窝IP地址获得DNS流量。

数据集的格式。通过从客户端启动DNS请求、在权威域名服务器上监视DNS查询并捕获DNS响应，我们能够对每个DNS解析“建立关联”。为了进行这种关联分析，我们为每个DNS请求收集的数据以JSON格式存储，如图5所示。对于每个客户机，我们捕获每个请求和响应的响应。在我们的权威域名服务器上，我们手机响应请求的到达时间和源IP以及返回的响应。

客户机的全球分布。利用ProxyRack和安全软件，我们解决了在全球范围内获得客户的挑战。这里我们使用全球分布[20]的不同的IP来评估客户机。在全球分析中，我们收集的客户机遍及173个国家超过36000个独立的地址。图6显示了全球分布以及我们的客户机覆盖了世界上大多数国家，其中韩国、俄罗斯、日本和美国居多。在全中国的分析中，我们获得的客户机大多数来自中国，但是仍然覆盖了87个不同的国家。

3.5 道德

我们的方法可能会导致一些道德问题。在展示我们的成果之前在这里先来讨论一下它们。在整个研究中我们都非常注意保护用户不受我们实验可能产生的副作用影响。

在全球分析中，ProxyRack是商业化的。我们对代理服务付费并且完全遵守他们的服务条款。更重要的是，出口节点的所有者（即我们的优势点）与ProxyRack达成协议，允许ProxyRack流量从其主机出去。因此，从ProxyRack启动DNS请求符合出口节点所有者授权的权限。

在全中国范围的分析中，我们在一个拥有数百万用户的安全软件（360）的网络调试器中实现了一个测试脚本。为了避免道德上的顾虑，这个网络调试器模块附带了一个每次的同意声明软件的运行和数据收集。用户保留选择是否安装此安全软件以及是否手动运行包含我们测量脚本的模块的权利。此外，用户可以选择安装不带测量模块的软件。

至于我们的方法，我们仔细地设计我们的DNS请求，并限制它们的数量以避免过度的网络流量。同时，我们只在每个客户端启动为本研究专们注册和使用的域名的DNS查找，不连接任何DNS解析器之外的主机。

通过上述方法，我们认为我们在实验中已经把用户安全和隐私的威胁降到了最低，因为所有的操作都是在用户允许的情况下进行，我们不会在有限的范围内收集除了DNS解析之外的任何数据。

4 TCP DNS拦截分析（全球）

为了进行全球DNS拦截测量，我们首先利用一个基于TCP SOCKS的住宅代理网络。在本节，我们通过展示其布局和特征来报告我们的测量结果以及全球分析阶段的分析。

4.1 范围和规模

我们首先从三个方面来研究DNS拦截的全球布局。第一，使用我们在前一节描述的方法，我们通过交叉匹配解析器地址识别和分类拦截。第二，我们验证客户最终接收的响应是否正确。在这里，只有当它的RR值与我们的权威域名服务器响应的相同FQDN的RR值完全相同时，我们才认为客户接收的FQDN的响应是正确的；否则，响应是不正确的，它在返回的路上被篡改了。第三，对于请求克隆的情况，拦截器可能希望使用out-of-bandDNS包[46]（即，克隆查询的响应）取代in-band DNS包（即，原始查寻的响应）。为了达到这个目的，克隆查询通常比原始查询更快。通过我们设计的权威域名服务器，我们展示了有多少in-band响应最终被客户接收。

表2总结了我们在全球分析中的发现。我们的数据集中包含了所有的三种拦截类型。总共有198个（在2691个客户机中占了7.36%）客户机的流量被拦截了，其中158个是对谷歌公共DNS查询时被拦截的。直接响应的比例非常低，因为如果不连接域名服务器，解析器就不可能正确地解析一个域，因此，这种行为是区别于客户机的。此外，我们还发现，与不太为人所知的EDU DNS（被拦截的数据包占0.45%）相比，发送到知名公共DNS服务器上的流量更可能被拦截（如谷歌DNS拦截为0.66%）。

对于客户端接收的响应，除了一个外，其余都是正确的，这表明被拦截的查询中大多数的响应没有被篡改。AS36992（EG,ETISALATMISR）中的客户机接收了一个错误的响应（Response:146.112.61.109，反向查询指向hit-block.opennd.com)，这是由域阻塞引起的。另一方面，对于请求克隆，客户端接收的in-band响应占少数。在发现克隆查询的23个自治系统中只有2个客户端（AS9198 JSC Kazakhtelecom和AS31252 Star-Net Solutii SRL）收到in-band响应。

4.2 AS级别的特征

在我们的布局研究中，我们在198个客户机自治系统中发现不同模式和比率的拦截DNS请求。我们现在分析自治系统级别的DNS拦截特征，重点关注158个对谷歌公共DNS请求的拦截。

拦截的类型和比率。图7展示了从每个自治系统到谷歌的被拦截的请求的数量和类型，以及拦截的请求和总共发往Google的请求的比率。我们发现在前20名的自治系统中，大部分只遭受了一种拦截，这表明在一个自治系统中DNS流量过滤使用统一策略。请求重定向和请求克隆都可以在考前的自治系统中找到。

关于拦截率，我们发现，在所有158个有问题的自治系统中，有82个自制系统（52%）中拦截发送到谷歌DNS的请求在90%以上，比如AS38001和AS43554。相比之下，50个自治系统（32%）的拦截率低于0.5（例如AS17974）。我们推测，这可能是由于拦截策略和沿途设备的部署导致的，沿途设备可能值覆盖了自治系统的有限的地点。

国家层面的分析。我们进一步调查158个自治系统的分布国家，并且发现他们分布于41个国家。俄罗斯高居榜首，占44个自制系统（28%），其次是美国（15个自治系统，9%），印度尼西亚（8个自治系统，5%），巴西和印度（各7个，4%）。

目标公共DNS服务器。我们发现在某些自治系统中，只有发送到特定公共DNS服务器的查询被拦截。表3显示了对谷歌拦截次数最多的10个自治系统的结果。我们发现有两个自治系统（AS43554和AS15774）专门拦截到谷歌DNS的流量，虽然大多数的ASes不这样。

替代解析器。当DNS拦截发生时，替代解析器将与我们的权威域名服务器连接。对于被截获请求最多的前10个自治系统，表4显示了处理解析的替代解析器。我们可以读出这样的结论，对于排名前10的自治系统，替代解析器实际上和客户机处于同一个自治系统下。

有问题的自制系统的流量排名。我们认为DNS拦截通常发生在声誉较低的自治系统中，因为这样的行为应该是隐秘的。然而，通过将有问题客户机的自制系统与他们在CAIDA[2]记录的流量排名相对比，我们的结果表明拦截也存在于信誉良好的自治系统中。如图8所示，有问题的自制系统分布在不同的排名中。例如，在CAIDA排名第一的AS3356，发现了请求重定向和请求克隆拦截。

案例研究。AS7922（CAIDA排名第22位）属于美国知名因特网服务提供商Comcast Cable Communications，LLC。在我们发送到谷歌的13466个DNS请求中，有72个（0.53%）被重定向，实际上不是谷歌而是其他解析器与我们的权威域名服务器联系。这些替代解析器的IP前缀是76.96.15.*（也位于AS7922），其PTR记录指向hous-cns14.nlb.iah1.comcast.net。我们还发现，72个被拦截请求的客户机可以通过几个前缀进行分组（如，67.160.0.0/11）。由于拦截率比较低，我们推测进行DNS拦截的沿途设备仅部署在这个自治系统中有限的子网中。此外，拦截设备可能是由Comcast客户部署，而不是由自治系统一级的网络运营商部署。

4.3 研究结果总结

我们子啊全球分析中的测量结果总结如下。

发现DNS拦截在全球198个自治系统中存在。对于我们所研究的公共DNS服务，从客户端发送的基于TCP的DNS请求有0.66%以上被拦截。同时，拦截行为在有名的ASes中和排名较低的ASes中都存在。
对于拦截情况，请求重定向和请求克隆都出现在对谷歌DNS拦截请求最多的前20个ASes中。直接响应比较少，因为它更可能被客户机发现。
对于ASes前20中的大多数，在一个AS中只发现一种拦截类型，这表明了统一的拦截策略。此外，我们发现拦截器可以专门拦截发送到特定公共DNS服务（如谷歌公共DNS）的DNS流量。具体的策略在不同的拦截器之间是不同的。我们还发现，发送到谷歌公共DNS的82个ASes的DNS流量90%以上被拦截。

5 TCP/UDP DNS拦截分析（全中国）

为了了解更多关于DNS拦截的特性，我们设计了另一个名为全中国分析的实验。在本节中，我们首先从总体上分析了不同类型DNS数据包的拦截特性。此外，我们还讨论了关于DNS查询性能和由DNS拦截带来的响应操作。最后我们讨论了这种拦截行为的潜在动机。

5.1 拦截的特征

在我们的实验设置中，我们从客户端到公共DNS服务触发具有不同字段值的DNS包。总的来说，通过比较不同字段值的数据包的截获率，我们首先研究哪种类型的数据包更容易被拦截。表5展示了我们对这一阶段结果的总结。

传输协议。与TCP相比，客户端通过UDP发送的DNS请求更容易被截获。例如，通过UDP发送到谷歌公共DNS的27.9%的DNS请求被重定向或者克隆，通过TCP发送的拦截比率近卫7.3%。事实上，现实中大多数的DNS请求都是通过UDP发送的，并且拦截UDP流量在技术上更容易。因此，拦截的流量主要是UDP流量是合理的。

目标公共DNS服务器。DNS拦截的的目标不光是发送到知名公共DNS服务器而且还有不那么流行的DNS服务器。与我们的全球分析结果类似，知名公共解析器的拦截率明显更高。例如，发送到谷歌的基于UDP的DNS数据包拦截率为27.9%。我们自己的EDU DNS的拦截率为9.8%。

DNS RR类型。我们发现A类型的请求更容易被拦截，这可能是因为它是最常见的RR类型。同时，我们在表5中注意到，对于请求克隆，客户机没有收到CNAME、NS或者MX类型的请求的in-band响应。我们推测沿途设备在克隆请求的同时，阻止了来自公共DNS服务的三种RR类型的响应，重申了拦截行为的不道德本质。

请求域的TLD。由于检查所请求的域名会带来额外的时间开销，所以沿途设备不太可能指定特定的域并只拦截他们的请求。如表6所示，在不同的TLDs下，被截获的DNS请求的比例并没有因为域而变化。

案例研究。总之我们发现356个ASes中有61个ASes是有问题的。在表7中，我们列出了客户端发送DNS请求（总共292K）最多的ASes中的前5个ASes。由于我们的客户端主要来自中国，所以排名前五的自治系统属于中国三大因特网服务提供商。我们发现，中国移动的ASes相对于中国其他的ISP的ASes，有着显著的高截获比。对于替代解析器，他们大多数都和他们的客户端位于相同的AS。然而，我们发现他们可能位于同意ISP的不同AS中（如表7中的AS56046）。

5.2 DNS查找的性能

正如一个大型ISP[24]所宣传的那样，设计DNS拦截的目的是为了提高DNS查找的性能，我们想调查这是否属实。我们认为RTT（round-trip-time），即客户机测量的从发送请求道接收应答之间的间隔，是DNS查找性能的指标。在我们的研究中，客户机可能记录两次时间戳。

图9显示了DNS请求RTT的ECDF。我们发现每种类型的拦截所带来的性能影响是不同的。对于请求克隆，当客户端通过UDP发送DNS请求时，确实存在性能改进，与正常解析相比，RTT更短。然而，在TCP上，由于建立连接的成本，改进并不明显。另一方面，对于请求重定向，性能改进是不确定的。以TCP为例，70%的请求有更好的性能，30%的请求比未被拦截的请求有更长的RTT。在回顾重定向请求主要是由本地解析器处理的（如表4所示，替代解析器与客户机位于同一AS中）同时，它还暗示了沿途设备重定向请求几乎不需要额外的时间开销。因此，因特网用户很难注意到隐藏的拦截行为。

对于请求克隆，我们以克隆到谷歌DNS的请求为例，我们在权威域名服务器上计算in-band和相应的out-band请求到达时间的差异。总共有14590个out-of-band解析请求（84.63%，总共17239个克隆请求）比in-band请求更快到达我们的权威域名服务器。放大到ASes，图10显示了到谷歌克隆请求最多的前10个ASes。在AS4812（中国电信集团）中，大多数的ASes的克隆请求更快到达，而所有的大歪请求都滞后。我们猜想，这可能是由于AS中网络设备的实现造成的，或者out-of-band请求遵循不同的和更长的路由造成的。

总结。通过DNS查询的RTT，我们发现请求克隆提高了DNS查询的性能，特别是通过UDP的请求，使得out-of-band更有可能被客户端接收。从权威域名服务器的角度观察，84.63%的克隆查询更快到达谷歌DNS。然而，根据我们的发现，请求重定向会带来不确定的影响。

5.3响应操作

通过比较我们的权威域名服务器产生的响应和客户接收的响应，我们发现响应在返回的路上被篡改。我们聚焦于相应的TTL和DNS记录值，并详细的说明他们是怎么操作的。

TTL值。正如3.2节所述，我们的权威域名服务器返回的TTL值是从1到86400之间随机选择的。然而，如图11（a）所示，对于我们的客户端，我们发现大约20%的TTL值被替换了，大部分替换为一个更小的值。通过将每个请求散布到图11（b）中，我们发现对于修改后的TTL有一些首选值，例如1800、3600和7200。

DNS记录值。如表8所示，虽然数量很少，但是我们确实观察到客户端接收到被篡改的DNS记录（包括A、AAAA和MX）响应的情况。对于占大多数的A和AAAA记录，除了被私有地址（可能是流量网关）替换，我们还观察到DNS劫持用于非法流量货币化（illicit traffic monetization）。例如，在AS9808（广东移动）中，来自谷歌公共DNS的8个响应被篡改，改为指向一个为中国移动推广APP的一个门户网站。相应的客户端位于相同的AS中。对于MX记录，可能由于配置错误，在AS25019（沙特电信公司JSC）中，我们观察到沙特阿拉伯ISP的邮件服务器出现在对客户端的响应中。

5.4 拦截的动机

在本节中，我们将研究DNS拦截的动机。我们首先通过查询搜索引擎和浏览技术论坛来调查提供DNS拦截功能的设备、供应商和软件平台。为此，我们发现三个著名的路由器制造商（Cisco[4]，Pnabit[23]，Shenxingzhe[8]），三个公司（ZDNS[26]，Haomiao[7]，Ericsson[21]）和一个软件平台（DNS Traffic redirect system of Xinfeng[24]）都支持DNS拦截。与此同时，在[7，21,，23，24，26]中发表了几种拦截DNS流量的详细技术方法。例如，中国移动提出了一种方法，它可以在骨干网络上克隆out-of-band DNS请求，并使用本地DNS解析器响应客户机，这和请求克隆很相似。上述刊物中提到了DNS拦截的几个可能的动机，我们现在根据我们的测量结果对它们进行讨论。

提高DNS安全。供应商声称通过DNS拦截，DNS请求是被可信的本地DNS服务器处理而不是本地网络之外的不可信的DNS服务器处理，因此被劫持的可能性更小[24，26]。但是，首先对于那些可信公共DNS服务器并指定它们处理DNS请求的客户端来说，DNS拦截无疑会带来道德问题，并违反了用户与其首选DNS解析器之间的信任关系。此外，我们的测量结果显示，声誉良好、安全部署良好的公共DNS服务器的截获率明显高于不知名的公共服务器。这个结论与使用DNS拦截改进DNS安全性相冲突，因为out-of-band公共DNS服务器没有被同等地视为不可信的解析器。更糟糕的是，我们观察到为了利润而劫持的行为（例如，流量货币化），虽然很少。

提高DNS查询性能。另一个声称的DNS拦截的动机是提高DNS查找和用户体验的性能。正如在5.2节所述，我们发现克隆请求确实缩短了DNS查找的RTT，而请求重定向的影响是不确定的。然而，在实际中，对于表7所示的前5个ASes，请求重定向的比率明显更高，而请求重定向带来带来性能的不确定性而不是性能的改进。因此，DNS拦截对DNS查找性能的改进非常有限。

减少财务结算。因特网服务提供商，尤其是小规模的网络服务提供商，希望降低网络间流量传输的成本。请求重定向满足了减少out-of-band流量的需要，如表7所示的一些AS中可以看到这一点。因此，我们认为财务问题是DNS拦截的主要动机。在与中国一家大型ISP的DNS管理团队进行线下会议后，这一动机得到了证实。

5.5 发现总结

综上所述，我们在全中国分析阶段得出以下结论。

总体而言，通过UDP发送的DNS数据包更容易被拦截。以发送到谷歌公共DNS的数据包为例，27.9%的基于UDP的数据包被拦截，通过TCP发送的数据包只有7.3%的比例被拦截。此外，A类请求的拦截率稍高，而不同的请求域名带来的差别较小。
在61个自治系统中发现了拦截行为。我们发现中国最大的因特网服务提供商之一中国移动拦截的DNS流量明显多于其他因特网服务提供商。为了进行DNS拦截，请求重定向是首选。
对于DNS查询的性能，总的来说，请求克隆缩短了DNS请求的RTT。对于请求重定向，拦截会对DNS请求的RTT带来不确定的影响。
我们推测DNS拦截的动机包括减少财务结算，提高DNS查找性能，而不是提升DNS安全性。

6 威胁

知名的公共DNS服务因其良好的声誉和可用性而被广受因特网用户和应用程序信赖。不幸的是，我们的研究表明这个信任可能被DNS拦截破坏。进一步讨论DNS拦截带来的潜在威胁和安全问题。

道德和隐私。在客户端很难检测到DNS拦截，因此因特网用户可能不会意识到他们的流量被拦截了。首先，当客户机的DNS请求被替代解析器处理时，先前的研究已经证明了从流量中非法货币化是可能的[36，56]。其次，由于因特网用户很难仅从客户端检查DNS拦截，当返回不希望得到的结果时（例如，广告站点或恶意软件），用户可能会错误的指责公共DNS解析器。最后，被拦截的DNS请求可能被不信任的第三方监听，从而导致隐私数据泄露。因此，我们认为DNS拦截可能给因特网用户带来道德和隐私风险。

DNS安全实践。虽然流行的公共DNS服务器通常部署完善的DNSSEC支持和最新的DNS软件，实际上许多域名服务器和解析器仍然在使用过时的甚至弃用的DNS软件，这可能很容易受到攻击[42，54]，而且在解析器上部署的DNSSEC仍然很差。我们提出了一个粗略的关于 1166个替代DNS解析器的安全实践的观点，这些DNS解析器与我们的权威域名解析器联系；其中205个对公众开放。尽管这些解析器可能不具有广泛的代表性，但他们仍然为我们提供了了解DNS安全实践的机会。在205个公共太呆解析器中，只有88个（43%）接收DNSSEC请求；那些实际验证DNS请求的可能更少。使用fpdns[11]对解析器上部署的DNS软件进行指纹识别后，我们发现97个（47%）正在运行BIND。不幸的是，指印显示所有97台服务器使用的笨笨都早于9.4.0，这个版本在2009年之前就弃用了。因此，根据公共漏洞库[6]，他们都容易受到像DoS这样的已知的攻击。

DNS功能。除了DNSSEC，DNS的其他功能也会受到DNS拦截的影响，如果替代解析器没有提供相应的支持的话。例如，EDNS客户端子网（ECS）请求，它允许DNS查询包含其来源的地址，因此可以根据客户端的位置返回不同的响应。然而，通过检查205个开放替代解析器，我们发现只有45个（22%）接收ECS请求。

7 缓解讨论

目前，几乎所有的DNS数据包都是不加密发送，这使得它们很容易受到监视和操纵。这个问题已经被DNS社区注意到，RFC7858[39]（描述了DNS在传输层安全（TLS）上的规范）被发布来解决这个问题。不幸的是，在TLS上部署DNS是非常复杂的，并且需要从客户端更改。鉴于此，主动的广泛部署这个可能需要很长时间。

根据我们的观察，我们开发了一个在线检查工具[25]来帮助互联网用户检测DNS拦截。这个工具在我们自己控制的权威域名服务器的协助下工作。访问我们的检测网站的用户将向我们的域发送一个DNS请求，并且该请求由我们的权威域名服务器捕获。通过比较与我们的域名服务器连接的解析器和他们自己指定的解析器，因特网用户就能识别出DNS拦截。目前，我们还在完善这个网站，旨在为因特网用户提供更多的DNS拦截信息。然而，目前的解决方案和缓解措施还远远不够。围绕DNS拦截，安全社区还需要提出新的解决方案来解决这个问题。

8 相关工作

流氓DNS解析器。对手可以建立DNS解析器来为DNS查询返回流氓响应，这可以任意操纵用户的流量。之前的研究表明拦截动机包括恶意软件的传播、审查和广告注入[38,42]。我们研究了另一种类型的DNS流量操作。

透明的DNS代理。透明的DNS代理可以操纵通过的DNS流量。首先，互联网运营商可以通过将DNS查找错误重定向到广告来盈利[55，56]。相似的，Chung等人利用住宅代理网络研究了本地DNS服务器端到端透明性的违规情况，结果显示4.8%的NXDOMAIN响应被重写为广告服务器地址[36]。此外，之前的研究也表明了，在蜂窝网络中，有18%的DNS会话通过透明DNS代理[53]并且生存时间（TTL）值被区别对待[49]。此外，技术博客还报道，因特网服务提供商可以使用DNS透明代理拦截DNS流量[1，13,17,18）。相比之下，我们的研究关注的是路径上隐藏的拦截行为，而不是流氓解析器或DNS代理。

因特网审查。DNS协议缺乏认证和完整性检查，因此DNS流量操纵已成为一种普遍的审查机制，组织用户访问某些网站。在全球和特定国家的观点中，已经投入了大量的精力来研究审查的内容、方法和原因。结果显示，许多国家都部署了DNS审查能力，包括中国，巴基斯坦、埃及、伊朗和叙利亚[28、29、30、31、32、44、45、58]。此外，从全球范围来看，Pearce等人发现了广泛的DNS操纵[48]，Scott等人在117个国家[50]发现了DNS劫持。相比之下，我们研究中使用的域名都是专门注册和使用的，并且避免使用任何敏感的关键词。因此，我们的研究与审查机制没有重叠。

因特网资源的其他操作。此外，研究人员还发现了操纵DNS流量的其他方法，包括滥用DNS域名空间（即“名称冲突”[34，35]，利用配置错误和硬件问题），利用配置错误和硬件问题（误植域名和一位之差[54]），和幽灵域[40]。Allman等人介绍了如何检测未授权的DNS根服务器[27]，这是与我们最接近的工作。但是，只考虑了一种流量操纵，只发现了有限的情况。我们的研究是对现有研究成果的补充，有助于理解DNS生态系统中的安全问题。

与以往的研究相比，我们的工作对DNS拦截进行了系统的和大规模的研究，这是一种尚未得到深入研究的DNS行为，重点关注安全、隐私和性能方面的问题。

9 总结

在本文中，我们队NDS拦截进行了大规模的研究，它带来了和DNS拦截相关的安全、隐私和性能问题。我们开发了一套技术来检测这种隐藏的行为，利用两个独特的平台和众多的优势点。基于我们的数据集，我们发现DNS拦截存在一些ASes和网络中。此外，进一步分析了DNS拦截的拦截特征和动机。我们的结果表明隐藏的DNS拦截可能在DNS生态系统带来新的威胁，需要新的解决方案来应对威胁。

致谢

感谢一堆人，工作的项目支持，国家自然科学基金等的支持，谨代表作者本人的观点，立场。

参考资料

[1] 22 networks with transparent dns proxies. https://help.dnsfilter.com/article/22-networks-with-transparent-dns-proxies.
[2] As rank: A ranking of the largest autonomous systems (as) in theinternet. http://as-rank.caida.org.
[3] Avast secure dns. https://help.avast.com/en/av_abs/10/etc_tools_secure_dns_overview.html.
[4] 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.
[5] Cisco umbrella intelligent prox. https://learn-umbrella.cisco.com/feature-briefs/intelligent-proxy.
[6] Cve-2015-5477: An error in handling tkey queries can causenamed to exit with a require assertion failure.https://nvd.nist.gov/vuln/detail/CVE-2015-5477.
[7] Dns traffic clear refreshment system. http://www.xpspeed.net/product4.html.
[8] Dns traffic router of shenxingzhe. http://bbs.dwcache.com/t/31.
[9] Dynamic dns. https://dyn.com/dns/.
[10] Farsight passive dns. https://www.farsightsecurity.com/solutions/dnsdb.
[11] fpdns https://github.com/kirei/fpdns.
[12] Google public dns. https://dns.google.com/.
[13] How to find out if your internet service provider is doingtransparent dns proxy. https://www.cactusvpn.com/tutorials/how-to-find-out-if-your-internet-service-provider-is-doing-transparent-dns-proxy/.
[14] Http and socks proxies. https://www.proxyrack.com/.
[15] Introduction of dns pai project. http://www.dnspai.com.
[16] Is your isp hijacking your dns traffic? https://labs.ripe.net/Members/babak_farrokhi/is-your-isp-hijacking-your-dns-traffic.
[17] Is your isp hijacking your dns traffic. https://labs.ripe.net/Members/babak_farrokhi/is-your-isp-hijacking-your-dns-traffic.
[18] Isp doing transparent dns proxy. https://www.smartydns.com/support/isp-doing-transparent-dns-proxy/.
[19] Luminati: Residental proxy service for businesses. https://luminati.io.
[20] Maxmind: Ip geolocation. https://www.maxmind.com/en/home.
[21] A method to conduct dns traffic redirecting in telecommunica-tion system. https://patentimages.storage.googleapis.com/cc/b2/65/6272013c07765e/CN103181146A.pdf.
[22] Open dns. https://www.opendns.com/.
[23] Panabit intelligent dns system. http://www.panabit.com/html/solution/trade/service/2014/1216/94.html.
[24] The practice of dns control based on out-of-band respon-der mechanism. http://www.ttm.com.cn/article/2016/1000-1247/1000-1247-1-1-00064.shtml.
[25] What is my dns resolver? http://whatismydnsresolver.com.
[26] Zdns: solutions for campus network services. http://free.eol.cn/edu_net/edudown/2017luntan/zdns.pdf.
[27] A LLMAN , M. Detecting dns root manipulation. In Passive andActive Measurement: 17th International Conference, PAM 2016,Heraklion, Greece, March 31-April 1, 2016. Proceedings (2016),vol. 9631, Springer, p. 276.
[28] A NONYMOUS . The collateral damage of internet censorship bydns injection. ACM SIGCOMM CCR 42, 3 (2012).
[29] A NONYMOUS . Towards a comprehensive picture of the greatfirewalls dns censorship. In FOCI (2014).
[30] A RYAN , S., A RYAN , H., AND H ALDERMAN , J. A. Internetcensorship in iran: A first look. In FOCI (2013).
[31] B AILEY , M., AND L ABOVITZ , C. Censorship and co-option of the internet infrastructure. Ann Arbor 1001 (2011), 48104.
[32] C HAABANE , A., C HEN , T., C UNCHE , M., D E C RISTOFARO ,E., F RIEDMAN , A., AND K AAFAR , M. A. Censorship in the wild: Analyzing internet filtering in syria. In Proceedings of the 2014 Conference on Internet Measurement Conference (2014),ACM, pp. 285–298.
[33] C HEN , J., J IANG , J., D UAN , H., W EAVER , N., W AN , T., AND P AXSON , V. Host of troubles: Multiple host ambiguities in http implementations. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (2016), ACM, pp. 1516–1527.
[34] C HEN , Q. A., O STERWEIL , E., T HOMAS , M., AND M AO ,Z. M. Mitm attack by name collision: Cause analysis and vul-nerability assessment in the new gtld era. In Security and Privacy(SP), 2016 IEEE Symposium on (2016), IEEE, pp. 675–690.

[35] C HEN , Q. A., T HOMAS , M., O STERWEIL , E., C AO , Y., Y OU ,J., AND M AO , Z. M. Client-side name collision vulnerability inthe new gtld era: A systematic study. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Se-curity (2017), ACM, pp. 941–956.
[36] C HUNG , T., C HOFFNES , D., AND M ISLOVE , A. Tunneling fortransparency: A large-scale analysis of end-to-end violations inthe internet. In Proceedings of the 2016 ACM on Internet Mea-surement Conference (2016), ACM, pp. 199–213.
[37] C HUNG , T., VAN R IJSWIJK -D EIJ , R., C HANDRASEKARAN , B.,C HOFFNES , D., L EVIN , D., M AGGS , B. M., M ISLOVE , A.,AND W ILSON , C. A longitudinal, end-to-end view of the dnssececosystem. In USENIX Security (2017).
[38] D AGON , D., P ROVOS , N., L EE , C. P., AND L EE , W. Corrupteddns resolution paths: The rise of a malicious resolution authority.In NDSS (2008).
[39] H U , Z., Z HU , L., H EIDEMANN , J., M ANKIN , A., W ESSELS ,D., AND H OFFMAN , P. Specification for dns over transport layersecurity (tls). Tech. rep., 2016.
[40] J IANG , J., L IANG , J., L I , K., L I , J., D UAN , H., AND W U , J.Ghost domain names: Revoked yet still resolvable. In Networkand Distributed System Security Symposium (2012).
[41] K REIBICH , C., W EAVER , N., N ECHAEV , B., AND P AXSON ,V. Netalyzr: illuminating the edge network. In Proceedings of the 10th ACM SIGCOMM conference on Internet measurement(2010), ACM, pp. 246–259.
[42] K¨ UHRER , M., H UPPERICH , T., B USHART , J., R OSSOW , C.,AND H OLZ , 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.
[43] L IU , D., H AO , S., AND W ANG , H. All your dns records point to us: Understanding the security threats of dangling dns records. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (2016), ACM, pp. 1414–1425.
[44] L OWE , G., W INTERS , P., AND M ARCUS , M. L. The great dns wall of china. MS, New York University 21 (2007).
[45] N ABI , Z. The anatomy of web censorship in pakistan. In FOCI(2013).
[46] N AKIBLY , G., S CHCOLNIK , J., AND R UBIN , Y. Website-targeted false content injection by network operators. In USENIX Security Symposium (2016), pp. 227–244.
[47] N IKIFORAKIS , N., V AN A CKER , S., M EERT , W., D ESMET , L.,P IESSENS , F., AND J OOSEN , W. Bitsquatting: Exploiting bit-flips for fun, or profit? In WWW, 2013.
[48] P EARCE , P., J ONES , B., L I , F., E NSAFI , R., F EAMSTER , N.,W EAVER , N., AND P AXSON , V. Global measurement of dns manipulation. In 26th USENIX Security Symposium (2017), USENIX Association.
[49] S CHOMP , K., C ALLAHAN , T., R ABINOVICH , M., AND A LL -MAN , M. On measuring the client-side dns infrastructure. In Pro-ceedings of the 2013 conference on Internet measurement confer-ence (2013), ACM, pp. 77–90.
[50] S COTT , W., A NDERSON , T. E., K OHNO , T., AND K RISHNA -MURTHY , A. Satellite: Joint analysis of cdns and network-levelinterference. In USENIX Annual Technical Conference (2016),pp. 195–208.
[51] S HI , X., X IANG , Y., W ANG , Z., Y IN , X., AND W U , J. Detect-ing prefix hijackings in the internet with argus. In Proceedingsof the 2012 ACM conference on Internet measurement conference(2012), ACM, pp. 15–28.
[52] T YSON , G., H UANG , S., C UADRADO , F., C ASTRO , I., P ERTA ,V. C., S ATHIASEELAN , A., AND U HLIG , S. Exploring httpheader manipulation in-the-wild. In Proceedings of the 26th In-ternational Conference on World Wide Web (2017), InternationalWorld Wide Web Conferences Steering Committee, pp. 451–458.
[53] V ALLINA -R ODRIGUEZ , N., S UNDARESAN , S., K REIBICH , C.,W EAVER , N., AND P AXSON , V. Beyond the radio: Illuminat-ing the higher layers of mobile networks. In Proceedings of the13th Annual International Conference on Mobile Systems, Appli-cations, and Services (2015), ACM, pp. 375–387.
[54] V ISSERS , T., B ARRON , T., V AN G OETHEM , T., J OOSEN , W.,AND N IKIFORAKIS , N. The wolf of name street: Hijacking do-mains through their nameservers. In Proceedings of the 2017 ACM SIGSAC Con ference on Computer and Communications Security (2017), ACM, pp. 957–970.
[55] W EAVER , N., K REIBICH , C., N ECHAEV , B., AND P AXSON ,V. Implications of netalyzrs dns measurements. In Proceedingsof the First Workshop on Securing and Trusting Internet Names(SATIN), Teddington, United Kingdom (2011).
[56] W EAVER , N., K REIBICH , C., AND P AXSON , V. Redirecting dns for ads and profit. In FOCI (2011).
[57] W IKIPEDIA . Public recursive name server. https://en.wikipedia.org/wiki/Public_recursive_name_server.
[58] X U , X., M AO , Z. M., AND H ALDERMAN , J. A. Internet cen-sorship in china: Where does the filtering occur? In InternationalConference on Passive and Active Network Measurement (2011),Springer, pp. 133–142.

posted @ 2018-11-04 00:08 CatOnRoad 阅读(610) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部