DNS隐私问题现状的研究

黄 锴，孔 宁

HUANG Kai1,2,3,KONG Ning3

1.中国科学院 计算机网络信息中心，北京 100190

2.中国科学院大学，北京100049

3.中国互联网络信息中心，北京 100190

1.Computer Network Information Center,ChineseAcademy of Sciences,Beijing 100190,China

2.University of ChineseAcademy of Sciences,Beijing 100049,China

3.China Internet Network Information Center,Beijing 100190,China

1 引言

1.1 DNS发展现状

互联网域名系统（Domain Name System，DNS）是互联网最重要的基础设施组件之一，互联网上几乎每个活动都会以DNS查询开始，它也成为目前互联网中各个应用连接的一个纽带。DNS的结构是一个全球性的分布式数据库，维护了域名（domain）到主机名（host）的映射关系。通过DNS，用户可以通过简单易懂的域名更加便捷地访问互联网上的资源。

DNS最早于1983年由Mockapetris提出的[1]，它的主要功能是解决域名和地址转换的问题。经过这么多年的发展。DNS的工作机制和协议层面的研究已经基本成熟[1-2]，截止2017年8月，与DNS直接相关的规范已经达到185条[3]。与DNS相关的讨论也从基础设施建设上升到安全层面，DNS已经从一个简单的查询系统，逐步发展成为一个复杂的生态系统[4]。

正是由于DNS在当前互联网世界中扮演着重要角色，DNS的安全日渐受到业界的重视，特别是近些年有关DNS的安全事件层出不穷[5-7]，把将大家对DNS安全的关注提升到了一个前所未有的高度。但是目前DNS中有关安全的命题真正被解决的还很少，还有大量的问题亟待解决，而隐私问题就是其中十分关键的一个，自斯诺登事件[8]后，大家对隐私的关注度显著提升。当其他协议层都开始关注隐私问题，并通过各种加密手段保护用户隐私的时候，DNS就成了所有环节中最脆弱的一环[9]。

1.2 隐私问题相关讨论

目前网络标准的研究和制定工作主要是由国际互联网工程任务组（The Internet Engineering Task Force，IETF）负责，考虑到整个互联网上的隐私问题日渐显著，IETF于2013年开始就互联网协议的隐私问题开展了一系列的讨论，并提出了一系列的技术协议文档（如表1）。

表1 隐私相关标准制定情况

2013年IETF正式提出了互联网协议存在的隐私问题[10]。在2014年又提出被动监听也是对互联网用户和组织隐私的一种攻击手段[11]。

IETF于2014年成立DNS隐私传输交换工作组（DNS Private Exchange，DPRIVE），专门研究DNS隐私保护相关的课题，希望通过对DNS传输过程进行加密保护，以保护用户的隐私。该工作组拟定了隐私相关的RFC7626正式讨论DNS的隐私问题。同时提出来RFC7858和RFC8094讨论DNS传输过程中的加密手段。

在2017年IETF 99大会上，DNS Privacy项目组（dnsprivacy.org）专门就DNS隐私做了普及型汇报[12]。会上指出，目前DNS是互联网上隐私泄露的关键一环，而且泄露情况不容乐观。

1.3 DNS协议的脆弱性

早在2003年，IETF就对DNS的安全问题展开了讨论[13]。它列举了目前常见的安全威胁。同时文献[14]将DNS系统面临的安全威胁分为拒绝服务（denial of service）攻击、数据虚假和信息泄露。DNS系统之所以面临上述安全威胁，其根本因为是协议脆弱性[15]。

DNS协议设计之初就没有过多考虑安全问题。由于DNS的工作原理比较简单，考虑到效率问题，几乎所有的DNS流量都是基于UDP明文传输的[16]，而且资源记录未加上任何的认证和加密措施，所以很早就有人提出了观点“DNS的数据是公开的”[17]。DNS协议由于以上缺陷，很容易受到中间人攻击（man-in-the-middle attack）[18-19]，中间人可以通过窃听、篡改和伪造DNS数据包实施攻击。

DNS协议的脆弱性导致用户隐私在一层很容易被泄漏。

2 DNS存在的隐私隐患

2.1 DNS查询过程分析

用户每一次与互联网的交互基本都是从一次DNS查询开始的，要了解DNS上隐私问题，需要对DNS的查询方式有个大致了解。

一个简单的DNS查询大概会经历如图1所示过程。

图1 DNS查询过程

（1）发起请求：用户的主机会向自己配置的递归服务器发送查询请求：“www.cnnic.cn的地址是多少”。

（2）递归查询：递归服务器会根据用户查询的信息，查询自己的缓存（cache），如果有匹配信息，直接返回。否则先向根域（root zone）服务器发起查询，由于根域中只记录了顶级域.cn的服务器地址，因此会返回.cn顶级域的权威服务器地址。递归服务器然后转而向.cn的顶级域名服务器发起查询……直到最后访问到负责cnnic.cn.这个域的权威服务器，拿到了对应主机的实际IP地址。

（3）返回结果：递归服务器会将拿到的主机地址返回给用户。再由用户向对应主机发起后续请求。

从这里可以看出，由于当初设计的问题，DNS的这种查询手段，会在一次次与不同的主机对话的过程中，泄露很多没必要的信息，而这些信息都有可能包含用户的隐私。

根据用户主机产生DNS查询的方式，可以将查询分为两种：主动查询和被动查询。

2.1.1 主动查询

主动查询，顾名思义是指用户主动发起的行为所产生的DNS查询。这也是最为用户所熟知的一种查询方式。一般来说，当用户在使用浏览器，访问特定网站的时候就会触发主动查询。浏览器会根据用户输入的域名向DNS发起查询请求，得到查询结果，然后去特定服务器上获取用户想要的资源信息（网页、图片、脚本文件等）。

主动查询一般会泄漏用户上网习惯的偏好，尽管现在很多用户有清除浏览器访问历史记录的习惯，但该行为只能清除本机的数据，浏览器产生的每条DNS查询记录依然会被服务器收集到。

2.1.2 被动查询

除了主动查询外，还有更多的DNS查询是在用户没有察觉的情况下产生的，而这类查询往往会被用户忽视。例如当用户进入一个网页的时候，后台可能会同时执行多个复杂的请求，它可能涉及到请求不同域名下的图片、视频、脚本等资源，而每次资源请求都会重新发起一次DNS查询[20]。加上目前智能化的搜索引擎还会预测用户可能的查询信息，预先发起一些请求，甚至是在用户还未触发任何超连接的情况下，就已经预先发起了请求[21]。此外，用户主机上几乎所有需要的联网应用在向服务器获取数据的过程中都会涉及到DNS查询，这些查询都是后台自动产生的，无形中泄漏了用户使用软件的行为。

以上的两种情况都可能泄漏用户隐私，通过分析用户主机产生的网络流量数据，可以发现第二种情况发生频率远高过第一种，而且由于不被用户熟知，在日常生活中可能会泄漏更多的用户隐私信息。

2.2 DNS请求中的敏感字段

DNS请求包括许多字段[1]，但其中两个与隐私问题特别相关：QNAME和源IP地址[9]。QNAME是用户请求的域名全名，它提供了用户的操作的信息，而IP地址提供的用户主机的信息，可以看做是用户标识。

2.2.1QNAME

不同的QNAME包含的敏感信息不一样。例如，查询知名的域名所能泄露的个人隐私很少，但查询一些长尾的域名，可能会带来更多的隐私隐患。例如，查询www.veryrare.com的A记录（其中，veryrare.com是一个很少有人访问，具有特定主题的网站）可能会泄漏用户的某种习惯，爱好等信息。

此外，QNAME经常被嵌入到日常所使用的软件中，这可能会导致隐私问题。例如，当用户使用轻量目录访问协议 LDAP（Lightweight Directory Access Protocol）或者使用BitTorrent这样的软件的时候，都会触发被动DNS查询，产生特定格式的QNAME信息。例如：ldap.name.msdcs.cn，example.bittorrent-tracker.tcp.domain.，这些QNAME信息可能会泄漏用户使用软件的行为。

2.2.2 源IP地址

这里的IP地址包括IPv4和IPv6地址，由于IPv4地址空间的有限性，用户的IPv4地址经常会经过网络地址转换（Network Address Translation，NAT），因此可能不能特别具体地标识特定的用户。但随着IPv6技术的日渐成熟，并逐渐在全球得以应用[22]，未来每个IPv6地址很可能就能唯一标识用户主机或设备，也更有可能泄漏用户身份。

在一次DNS查询中，不同层面的IP地址的含义不太一样。一般来说，在递归服务器上，源IP地址基本就是用户主机的IP地址，但是在权威服务器上，源IP地址一般是发起递归查询的服务器的地址（但是有一种情况除外，用户在自己的电脑上部署了本地递归服务）。

2.3 DNS敏感数据可能的泄漏途径

通过前面的描述和分析，这里归纳出隐私泄漏主要有以下两个途径：通信链路窃听和服务器收集。

2.3.1 通信链路窃听

由于DNS的开放性，窃听者可以像窃听其他流量一样监听DNS流量。同时DNS查询并不经过任何的加密手段，因此，任何第三方的机构或个人很容易通过在用户和服务器之间进行搭线窃听，查看到用户所有的DNS查询信息。这也是目前被讨论最多的DNS上的隐私问题。

2.3.2 服务器收集

服务器被动收集用户隐私是目前DNS面临的第二个问题。全球现有超过1 000万台域名服务器，每天产生的域名查询信息已经达到了万亿级别[23]，同时，由于DNS日志已被广泛应用于各种DNS解析器（DNS Resolver）软件中[24]，因此，用户的每条查询信息都可以被服务器被动记录到。

其中，递归服务器是最接近用户的，所以它拥有最全面的用户查询记录，同时由于递归服务器上缓存的缘故，各级权威服务器所能记录的用户查询信息相对而言会有所缺失。但是考虑到权威服务器上每日接收到的查询数量巨大，当其掌握到一定量的数据后，它上面的隐私泄漏问题依然不可小觑。

3 DNS隐私泄露情况的研究

3.1 DNS查询会泄露用户的行为

Könings等人[25]通过校园网收集了一周DNS的查询数据，发现其中存隐私泄露风险，如用户真实姓名、设备名称等都有可能得到泄漏。Krishnan等人[21]证明了目前很多浏览器为了优化性能，往往会对网址所包含的内容进行预先提取处理，从而推导出用户可能的搜索行为，他提出这种做法有一定的隐私威胁并有可能被攻击者滥用。

Herrmann等人[26]发表论文指出，用户与DNS的交互存在暴露自身行为的风险。他指出用户在浏览网页时会形成特定的“行为链（behavior chain）”。通过分析用户浏览网页的行为特征，可以精确地匹配到特定用户。为验证猜想，他收集了大学数千名学生两个月的匿名DNS数据，然后使用朴素贝叶斯分类器（Naive Bayes Classifier）对该数据进行分析。在包含3 600名学生的样本中，通过“行为链”从IP地址中准确识别了85.4%的用户。当覆盖的用户量提高到1.2万时，准确率也有75.6%。许多国家的数据保存机制会禁止记录浏览器的访问历史记录。但作者声称执法机构通过使用DNS记录、IP地址记录和行为链可以重构更详细的浏览历史。

以上都表明恶意攻击者完全有可能通过分析用户的DNS请求来获取用户的隐私，通过分析用户的DNS查询日志推断用户的行为，喜好甚至能定位到特定用户。

3.2 第三方服务器收集用户查询日志

通过之前的分析可以知道，递归服务器拥有更多用户信息，更了解用户的习惯和兴趣。Banse等人[27]指出递归服务器在DNS查询中所处的位置最适合用来做用户行为追踪。

通常来说，用户的递归服务器地址默认会被配置成互联网服务提供商（Internet Service Provider，ISP）的地址，用户也可以根据需求，选择将其配置成第三方提供的免费公共递归解析服务器的地址。

截止到2015年底，Google在报告指出它的公用域名解析服务器平均每天要返回超过4 000亿次查询结果，大约占到全球解析总量的12%[28]。根据Google官方文档中对中“隐私（privacy）”一节的描述，Google承认有记录用户查询记录的行为[29]。并且记录的字段十分多，包括用户的IP，用户查询的域名，查询类型，甚至还包括用户地理位置信息。

OpenDNS直接公开表明会收集和保存DNS日志，用户也可以通过设置（付费）帐户功能来访问自己的日志。

另一方面，Golden Frog刚刚推出了一个加密的零日志（zero-logging）DNS[30]。并宣称其能增加用户的隐私，并能突破全球的DNS审查制度。

美国电信运营商AT&T在他们的官网公布了一种名为GigaPower的计划[31]，它为用户提供300 Mb/s光纤接入计划，在定价方案中，它明确地把保护用户的隐私作为一种可选择的增值付费服务。

现在国内各大互联网公司也都纷纷开始推出自己的公用域名解析服务。但由于目前第三方的公用域名解析服务大多都是由商业公司提供的，因此基于商业目的，用户的隐私很可能会遭到侵犯。

同时，国内外目前也有很多被动DNS（passive DNS），被动DNS最初于2004年由Florian Weimer发明，旨在对抗恶意软件[32]。它会将响应记录并将日志数据复制到中央数据库当中，以便用来分析恶意行为。知名的被动DNS系统宣称他们只保留DNS响应，而不保存客户端的源IP地址，这正是出于用户隐私的考虑[32]。但是并不是所有的被动DNS系统都会严格遵循以上规则[33]，所以依然存在泄漏用户隐私的风险。

3.3 国家安全局监听用户DNS查询

美国国家安全局（National Security Agency，NSA）是美国政府机构中最大的情报部门，专门负责收集和分析外国及本国通讯资料，隶属于美国国防部。自从斯诺登事件之后，NSA的大量资料被泄漏，其中有关DNS的各种文件显示，现有的针对DNS的秘密行动已经不仅限于大规模监视，而是已经逐渐开始成为一种辅助攻击手段[34]。随着NSA的QUANTUMTHEORY系列项目（如QUANTUM DNS等子项目）的揭露，可以知道像国家这样强大的攻击者不仅可以窃听DNS流量，还可以注入DNS响应来修改名称解析的结果，甚至使得特定的查询完全失效。由于DNS不提供加密手段保护用户的隐私，加上NSA这样具有强大背景的机构能获取最全面的用户查询信息，因此很容易根据每个用户的浏览行为创建用户的概况[21]。这些信息都可以被用来对特定目标实施QUANTUMTHEORY攻击。根据国家安全局自己公布的评估文件的显示，他们的QUANTUMTHEORY项目进展开展的十分成功[35]。

由此可见，DNS上确实有隐私泄漏隐患。特别是服务器上收集的大量数据很有可能会泄漏用户隐私。随着第三方公用解析服务器的普及使用，大大加剧了这一层面隐私泄漏风险，同时还必须注意到，像国家安全局这样的机构想要窃取用户隐私是非常容易的。因此，如果要彻底解决DNS的隐私问题，只关注通信链路上的隐私安全是远不够的。

4 DNS隐私保护的相关研究

考虑到目前互联网上隐私泄漏的情况，目前学术界和工业界都在提出自己的解决方案去解决DNS上的隐私问题，不同的解决方案关注点也不尽相同，主要是集中在以下几个方面。

4.1 链路上的隐私保护

DNS的开放性，使得它十分容易受到中间人攻击。虽然目前DNSSEC的部署情况已经有所好转，但是DNSSEC明确地将机密性排除在其目标之外[36]。DNSSEC的主要目的是提供签名认证，防止DNS被恶意篡改，并不提供加密服务。IETF的DPRIVE工作组一直在研究这个主题，研究如何以某种加密手段保护DNS客户端和DNS服务器之间的查询和响应交互。

实现链路上的加密，最简单的想法就是利用现有的非对称加密算法对链路上的信息进行安全加密，保证信息无法破解。下面是目前提出的几种针对链路上的隐私保护的方案。

4.1.1 DNS-over-TLS

Zhu等人[37]提出了T-DNS，通过使用安全传输层协议（Transport Layer Security，TLS）来保障用户到解析器或者到权威服务器的隐私安全。TLS已经被广泛应用在多种应用层协议中为其提供加密服务。但TLS通常需要TCP提供的可靠传输信道，因此不能直接用于保护UDP的数据报业务，因此传输层协议必须由UDP换成TCP。

2016年IETF正式提出的RFC7858，在标准层面讨论基于TLS的DNS的可行性。作者指出，使用TLS不仅有利于保护隐私，而且从无连接的UDP转到面向连接的TCP，可能有助于减轻DNS服务器上的扩大攻击（amplification attacks）[38]。通过重用TCP连接能同时处理多个DNS请求，并通过请求管道化和无序处理，能最大限度地减少延迟。但是使用TCP和TLS带来的开销依然不小。

4.1.2 DNS-over-DTLS

为了解决这些问题，另一个讨论开始考虑将TLS的功能映射到数据报传输（datagram transport）环境。出于这种考虑，出现了一种新的协议：数据报传输层安全性协议（Datagram Transport Layer Security，DTLS）。它是对TLS功能的改进，可以向应用程序呈现一种不需要可靠传输服务的数据报传输功能。DTLS可以从数据包丢失和重新排序中恢复，但不能容忍UDP数据包分片[39]。它建立在TLS 1.2的基础上，并使用一些附加功能，允许TLS在数据报传输上运行。但由于其在传输信息之前需完成握手、认证、交换密钥操作之后才能传输数据，往返需要7步才能完成通信任务。

4.1.3 DNSCurve

另外，针对链路上的安全问题，还有学者提出了DNSCurve[40]，它使用 Curve25519[41]交换会话密钥，然后在缓存和服务器之间提供认证和加密。只要相互通信的两台服务器都安装了DNSCurve缓存，那么它就能自动加密所有的DNS数据包，DNSCurve改进了现有域名系统在保密性和完整性上的不足，同时也不需要创建“昂贵”的签名或（D）TLS会话。

所有这些方案都采用不同的加密手段来减少DNS数据中隐私信息的泄漏。尽管这些提案都可取，但IETF并不期望现有的这些行业解决方案能够在短期内改变DNS的现状[42]。毕竟现阶段，大规模加密DNS流量的可能性非常小。

4.2 减少服务器上隐私收集

4.2.1 查询最小化

IETF近期在提高DNS隐私性方面的讨论包括了查询最小化（query minimization）[43]的提案，由于并不需要修改现有的DNS协议，所以该提案很快被采用了。DNS查询最小化遵循的原则是发送的数据越少，隐私问题就越少[44]。

回顾DNS的一次查询过程（图1），用户查询的域名全名会暴露给所有权威服务器，但通常这种信息的暴露是没必要的，因为较顶级的域名服务器通常不知道负责该域名的权威服务器的地址。因此，查询的全名只需暴露给最终权威的DNS服务器即可。查询最小化就是这样实现的，递归服务器每次只需要查询必要的信息（比如向顶级域发起查询的时候，只需要查询.cn的NS记录，而不需向其发送www.cnnic.cn的A记录查询信息），可以减少根服务器和顶级域服务获取到的用户信息，如图2所示。

图2 查询最小化

查询最小化的优势在于：只需要改变递归服务器配置，但是它只能提供非常有限的保护。但是，威瑞信公司（Verisign Inc.）声明该方案早已被其注册了专利，因此可能会通过该专利阻碍查询最小化的部署[45]，尽管如此，由于实现难度不大，目前市场上已经有部分软件宣布支持查询最小化。

4.2.2 加入混淆

加入混淆是一种比较简易实现的减少隐私泄漏的方案。通过加入混淆的信息，让用户原本的意图得到隐藏，一定程度上可以缓解用户信息泄漏的风险。Zhao等人[46]在研究了DNS每个环节的隐私泄漏问题之后，引入了一种解决方案，称之为范围查询（range query），它基于随机集（random set），即每个客户端都配备有一个有效域名的数据库（虚拟数据库）。每次客户端要向解析器发出DNS查询时，它就会从数据库中随机选取N-1个哑名（dumb name），并将N个查询发送到递归服务器。当从递归服务器接收到所有的回复后，虚拟查询的回复将被丢弃，所需的回复被呈现给发出查询的应用程序。他声称这个策略让对手只有机会猜出用户查询的真实域名，如图3所示。

图3 范围查询

但是范围查询是一个理想化的模型。Herrmann等人[47]通过实际的测试表明，在实际浏览网页的时候，往往会触发特定的查询模式，通过语义分析，很容易就能破解用户的访问请求。

Zhao等人[48]在之前的范围查询的基础上，又提出同时使用通信噪音和私人信息检索（Private Information Retrieval，PIR）的方式来降低用户隐私泄漏的风险，同时Castillo-Perez等人[49]进一步对这两种解决方案进行了评估，评估结果表明，第一种方法的优点是简单易于实现，缺点是增加了延迟和带宽。而第二种方法需要对DNS协议进行修改，不具备兼容性。

4.2.3 域名广播

Federrath等人[50]在前人的研究基础上又提出了一种基于热门域名广播和混合查询结合的隐私保护机制。整体的思路就像杀毒软件的病毒特征库的更新模式，定时广播域名库到用户机器上。递归服务器会参与热门域名转发，通过广播最频繁访问的域名，使得递归服务器无法直接获知用户对热点互联网业务的访问兴趣。同时用户可以本地缓存数据，实现80.2%的访问零延迟，且没有隐私泄漏的风险。同时对于长尾域名，加入混合的匿名机制，以保证隐私性。但是潜在的问题是用户的机器上需要缓存大量的数据，而且定时广播大量域名对服务器的要求比较高，而且需要修改现有的DNS架构，部署起来工作量比较大。

4.3 全面匿名化方案

Victors等人[51]提出使用洋葱路由（The Onion Router，TOR）的传统匿名手段来保护DNS隐私，但是这种隐私保护手段由于使用多跳路由会引入相当大的延迟。

Herrmann等人[52]提出 EncDNS，一种轻量级隐私保护名称解析服务器，用来替代传统的第三方解析器。EncDNS使用的传输协议基于DNSCurve，将加密的消息封装在标准的DNS消息中。通过使用EncDNS服务器代替用户向DNS服务器发送请求，隐藏真实的查询者，从而保护用户隐私。

Lu等人[53]提出了PPDNS（Privacy Preserving DNS），在域名解析过程中提供一定程度的隐私保护。PPDNS采用分布式散列表来取代传统的层次结构，使用可计算隐私查询方法（computation PIR，cPIR）实现查询过程中对信息发送者的隐藏。

Lammertink等人[54]提出借鉴比特币（bitcoin）的成熟方案，用基于比特币技术的分布式域名系统Namecoin来解决这个问题，Namecoin使用一个新的区块链（blockchain），独立于比特币的区块链之外，在上面维护域名列表。每个用户通过拷贝区块链副本，可以在本地实现DNS查询，从而实现完全匿名化。

以上的几种方案都通过改变现有的DNS架构，加入了相应的隐私保护措施，但由于改变了现有架构，只能被小范围应用，难以得到广泛部署。

4.4 方案总结

总结分析以上的各种方案，本文列举了每种方案主要的优缺点（如表2所示），可以发现，目前提出的隐私保护方案或多或少都还有一些不足，每种方案都是针对当前DNS隐私泄漏的某一个侧面进行研究的。根据前文分析，目前隐私保护应该从两个方面入手，一是在数据传输过程中进行加密处理，保护DNS查询链路上的隐私性，二是尽量地减少服务器对用户的隐私的收集。要真正彻底解决DNS上面的隐私问题，需要同时解决这两方面的问题。

其中针对传输链路加密手段的研究进展很快，除了DNSCurve未被IETF标准化，其他方案都已经被标准化，其中DNS-over-TLS已经有了多个具体实现和大量的实验性服务器部署。

但是针对服务器上的隐私收集问题，目前还没有真正意义上的解决方案。不管是查询最小化，加入混淆还是广播域名都没办法有效地隐藏长尾域名。使用EncDNS通过代理服务器代替用户查询的思路值得借鉴，但是单代理服务器有严重的性能瓶颈和单点失效问题。而类似PPDNS，NameCoin这些解决方案虽然实现了全面的匿名化，但都修改了现有架构，只能小范围应用，缺乏大规模部署性。

5 后续研究建议

为了后续研究的开展，这里提出后续隐私保护方案可以考虑的几个方面。

5.1 技术层面考虑

目前有关链路上加密研究已经很成熟了，多个方案都以被标准化了。相较而言服务器层面的隐私泄漏问题更值得研究。

Schomp等人通过对当前网络中解析器进行探测，发现当前网络中的大约有1 500～3 200万个公用递归解析器[23]。这些解析器有些是可信任的，有些则是半可信任甚至不可信任的。一次看似简单的域名解析过程，很可能会涉及多台位于多个不同层级、不同地域的域名服务器和解析器。由此可见，服务器上的隐私泄漏问题可能更加严峻。

后续研究一方面可以研究通过DNS查询日志如何预测用户行为，给后续解决方案提供理论支撑。另一方面可以考虑借鉴或使用新的手段减少服务器上隐私泄漏，比如减少或合并查询量，打乱查询时间线，伪造查询，或者加入混淆的时候考虑网页间的语义关系从而优化虚拟域名的选择策略。

现有解决方案部分实现匿名化，但是都不是从构建匿名化模型角度出发，后续研究可以考虑借鉴现有成熟的匿名化网络的方案[55]。

匿名保护通常可以分为：发送者匿名、接收者匿名和通信关系匿名[56]。把一次DNS查询比作一个双方通信，用户看作发送者，DNS服务器看作接收者。在这个特定的场景实现匿名化，实际上是要实现发送者匿名，即服务器无法获知真实的发送者。同时需要考虑到匿名化对延迟的影响，尽量要选择低延迟的匿名化方法，比如引入crowds协议，在保证查询延迟的情况下提供对发送者的匿名化[57]。

表2 各种隐私保护方案比较

5.2 部署难度考虑

目前全球已经有上千万台的DNS服务器，需要他们同时升级，难度重重，DNSSEC从1997年由网络工作组提出，直到2016年底依然没有实现全部顶级域的部署[58]。因此新的方案必须要考虑系统的部署难度，协议层的修改注定需要经历非常长的时间。

因此比较好的解决方案是尽量不要修改现有的DNS架构，而是采取“补丁”的方式，在现有的架构基础上进行功能改进。

5.3 法律层面考虑

除了从技术层面解决DNS的隐私问题外，还可以考虑从法律政策层面去减轻这个问题的影响。目前还没有任何国家地区正式发布与DNS隐私数据的相关的法律法规，这一块是一个空白。正因为没有立法，目前所有隐私的研究只能是在道德层面去约束和避免用户的隐私收到威胁。但是真正侵犯用户隐私的行为也不会受到任何的实际制裁，导致其犯罪成本很低。

考虑到隐私侵犯的判定比较难，因此在法律政策层面也需要进一步的推进。

6 结束语

本文通过对目前DNS隐私问题的现状做了一定的分析，提出了目前DNS架构中可能泄漏隐私的途径和可能泄漏的用户隐私信息，并且通过对目前国内外DNS隐私泄漏情况进行了研究，发现目前DNS有严重的隐私隐患，需要得到业界的重视。

与此处同时，近两年，国内外很多机构也开始在DNS的安全性和隐私性上下功夫，IETF中以DPRIVE为主的工作组开始就下一代安全可靠的DNS协议开展研究，有关DNS隐私的标准和草案也将会陆续推出。国内外的学者也针对不同环境下的DNS隐私泄漏问题提出了自己的解决方案，这些方案距离实际应用还有许多问题需要解决，但是依然给解决DNS隐私泄漏问题提供了很多创造性的思路。本文通过对现有方案进行总结和整理，希望能为后续研究提供一定的参考价值。

参考文献：

[1]Mockapetris P V.RFC 1034 Domain names concepts and facilities[S].1987.

[2]Mockapetris P.RFC 1035 Domain names implementation and specification[S].USC/Information Sciences Institute，1987.

[3]DNS RFC[EB/OL].（2017-02-07）.https：//www.isc.org/community/rfcs/dns/.

[4]DNS Ecosystem[EB/OL].（2016）.https：//www.nsrc.org/workshops/2016/nsrc-nicsn-aftld-iroc/documents/prezo/DNS_Org.pdf.

[5]Dyn cyberattack[EB/OL].（2016）.https：//en.wikipedia.org/wiki/2016_Dyn_cyberattack.

[6]Turkey DNS servers under attack[EB/OL].（2015-12）.https：//blog.radware.com/security/2015/12/turkey-dns-servers-under-attack/.

[7]Cyberattacks in China[EB/OL].http：//www.scmp.com/news/china/article/1410423/major-internet-outage-hits-millionschina-cyberattacks-suspected.

[8]Wikipedia.Global surveillance disclosures[EB/OL].（2013）.https：//en.wikipedia.org/wiki/Global_surveillance_disclosures_（2013%E2%80%93present）.

[9]Bortzmeyer S.RFC 7626 DNS privacy considerations[S].IETF，2015-08.

[10]Aboba B，Peterson J，Tschofenig H，et al.Privacy considerations for Internet protocols[S].2013.

[11]Farrell S，Tschofenig H.RFC 7258 Pervasive monitoring is an attack[S].IETF，2014-05.

[12]Dnsprivacy.org.DNS privacy tutorial[EB/OL].（2017）.https：//dnsprivacy.org/wiki/display/DP/IETF+DNS+Privacy+Tutorial?preview=/1277990/3145807/IETF_99_EDU_DNS_Privacy.pdf.

[13]Atkins D，Austein R.RFC 3833 Threat analysis of the Domain Name System（DNS）[S].Internet Engineering Task Force，2004.

[14]Conrad D.Towards improving DNS security，stability，and resiliency[EB/OL].（2012）.http：//www.internetsociety.org/sites/default/files/bp-dnsresiliency-201201-en_0.pdf.

[15]胡宁，邓文平，姚苏.互联网DNS安全研究现状与挑战[J].网络与信息安全学报，2017，3（3）：13-21.

[16]Bellis R.DNS transport over TCP-implementation requirements[J].Poultry Science，2010，75（11）.

[17]Osterweil E，Massey D，Zhang L.Deploying and monitoring DNS security（DNSSEC）[C]//Twenty-Fifth Annual Computer Security Applications Conference（ACSAC 2009），Honolulu，Hawaii，2009：429-438.

[18]Ariyapperuma S，Mitchell C J.Security vulnerabilities in DNS and DNSSEC[C]//Proceedings of the International Conference on Availability，Reliability and Security，2007.

[19]王洪芬.基于DNS和DNSSEC安全的脆弱性分析[J/OL].中国科技论文在线，2008.http：//www.paper.edu.cn.

[20]Wills C E，Shang H.The contribution of DNS lookup costs to Web object retrieval[R].Worcester Polytechnic Institute，2000.

[21]Krishnan S，Monrose F.DNS prefetching and its privacy implications：When good things go bad[C]//Proceedings of the 3rd USENIX Conference on Large-scale Exploits and Emergent Threats：Botnets，Spyware，Worms，and More，2010.

[22]马军锋，侯乐青.中美IPv6发展现状分析[J].电信网技术，2016（12）：28-31.

[23]Schomp K，Callahan T，Rabinovich M，et al.On measuring the client-side DNS infrastructure[C]//Proceedings of the Conference on Internet Measurement，2013.

[24]Leonhard W.Another privacy threat：DNS logging and how to avoid it[EB/OL].（2014）.https：//www.infoworld.com/article/2608352/privacy/internet-privacy-another-privacy-threat-dns-logging-and-how-to-avoid-it.html.

[25]Könings B，Bachmaier C，Schaub F，et al.Device names in the wild：Investigating privacy risks of zero configuration networking[C]//Proceedings of the IEEE International Conference on Mobile Data Management，2013.

[26]Herrmann D，Banse C，Federrath H.Behavior-based tracking：Exploiting characteristic patterns in DNS traffic[J].Computers&Security，2013，39（4）：17-33.

[27]Banse C，Herrmann D，Federrath H.Tracking users on the Internet with behavioral patterns：Evaluation of its practical feasibility[C]//IFIP Advances in Information&Communication Technology，2017，376：235-248.

[28]Google[EB/OL].（2014-12）.https：//webmasters.googleblog.com/2014/12/google-public-dns-and-location.html.

[29]Google privacy[EB/OL].https：//developers.google.com/speed/public-dns/privacy.

[30]Vyprdns[EB/OL].https：//www.goldenfrog.com/zh/vyprvpn/features/vyprdns.

[31]Gigapower[EB/OL].（2014-05-13）.https：//gigaom.com/2014/05/13/atts-gigapower-plans-turn-privacy-into-a-luxury-thatfew-would-choose/.

[32]Weimer F.Passive DNS replication[J].Analysis，2005（4）：1-13.

[33]Spring J M，Huth C L.The impact of passive DNS collection on end-user privacy[EB/OL].（2012）.https：//resources.sei.cmu.edu/library/asset-view.cfm?assetID=57021.

[34]Wired.A close look at the NSA’s most powerful internet attack tool[J].Communications of the ACM，2014.

[35]National Security Agency.There is more than one way to quantum[EB/OL]https：//www.documentcloud.org/documents/1076891-there-is-more-than-one-way-to-quantum.html-document/p1.

[36]US department of commerce N.DNS security introduction and requirements[C]//Proceedings of the BCP 78&BCP 79 Copies of IPR Disclosures Made To the IETF Secretariat，2005.

[37]Zhu L，Hu Z，Heidemann J，et al.T-DNS：Connectionoriented DNS to improve privacy and security（poster abstract）[J].ACM Sigcomm Computer Communication Review，2015，44（4）：379-380.

[38]Hu Z，Zhu L，Heidemann J，et al.Specification for DNS over Transport Layer Security（TLS）[S].IETF，2016，

[39]Netze H.RFC 6347 Datagram transport layer security version 1.2[S].2012-01.

[40]Dempsky M.DNSCurve：Link-level security for the domain name system[EB/OL].（2010-02-26）.https：//tools.ietf.org/html/draft-dempsky-dnscurve-01.

[41]Bernstein D J.Curve25519：New Diffie-Hellman speed records[C]//Lecture Notes in Computer Science，2006，3958（1）：207-228.

[42]Bortzmeyer S.Possible solutions to DNS privacy issues[EB/OL].（2013-12-17）.https：//tools.ietf.org/html/draft-bortzmeyer-dnsop-privacy-sol-00.

[43]Bortzmeyer S.RFC7816 DNS query name minimisation to improve privacy[S].2016-03.

[44]Steve Kenny C.Assuring data privacy compliance[J].Information Systems Control Journal，2004，4.

[45]Verisign Inc.’s Statement about IPR related to draftbortzmeyer-dns-qname-minimisation-02[EB/OL].（2014-10-27）.https：//datatracker.ietf.org/ipr/2469/.

[46]Zhao F，Hori Y，Sakurai K.Analysis of privacy disclosure in DNS query[C]//Proceedings of the International Conference on Multimedia and Ubiquitous Engineering，2007.

[47]Herrmann D，Maaß M，Federrath H.Evaluating the security of a DNS query obfuscation scheme for private web surfing[C]//Proceedings of the IFIP SEC，2016.

[48]Zhao F，Hori Y，Sakurai K.Two-servers PIR based DNS query scheme with privacy-preserving[C]//Proceedings of the International Conference on Intelligent Pervasive Computing，2007.

[49]Castillo-Perez S，Garcia-Alfaro J.Evaluation of two privacy-preserving protocols for the DNS[C]//Proceedings of the International Conference on Information Technology：New Generations，2009.

[50]Federrath H，Fuchs K P，Herrmann D，et al.Privacypreserving DNS：Analysis of broadcast，range queries and mix-based protection methods[C]//16th European Symposium on research in Computer Security（ESORICS 2011），Leuven，Belgium，September 12-14，2011.Berlin：Springer，2011，6879：665-683.

[51]Victors J.The onion name system：Tor-powered distributed DNS for tor hidden services[J].Dissertations&Theses-Gradworks，2015.

[52]Herrmann D，Fuchs K P，Lindemann J，et al.EncDNS：A lightweight privacy-preserving name resolution service[C]//Proceedings of the European Symposium on Research in Computer Security，2014.

[53]Lu Y.PPDNS：Privacy-preserving domain name system[J].oai：CiteSeerX.psu：10.1.1.188.296，2011.

[54]Lammertink X，Davids M.Namecoin as alternative to the Domain Name System[D].UvA System and Network Engineering，SIDN Labs，2011.

[55]王平水，王建东.匿名化隐私保护技术研究综述[J].小型微型计算机系统，2011，32（2）：248-252.

[56]徐静，王振兴.基于IPv6的接收者匿名Crowds系统[J].计算机工程，2009，35（23）：1-3.

[57]Reiter M K.Crowds：anonymity for Web transactions[J].ACM Transactions on Information&System Security，1997，1（1）：66-92.

[58]Chung T.Why DNSSEC deployment remains so low[EB/OL].（2017）.https：//blog.apnic.net/2017/12/06/dnssec-deploymentremains-low/.