Oblivious DNS：堵住互联网最大的隐私漏洞

作者：Annie Edmundson、PaulSchmitt 和 Nick Feamster

       近日传出新闻称Cloudflare在部署自己的DNS递归解析器，这再次在用户当中燃起了希望：获得更好的隐私，因为他们可以将经过加密的DNS流量发送到Cloudflare，而不是发送到ISP（互联网服务提供商）。我们在本文中解释了为什么这种方法只是将你的私密数据从ISP发送到另一个第三方。你信任这第三方可能甚过信任ISP，但还是仍得信任它。我们在本文中提出了另一种替代设计：Oblivious DNS（隐蔽式DNS，http://odns.cs.princeton.edu/），那样你根本没必要作出这样的选择。

       域名系统（DNS）

       你的客户端将google.com之类的域名转换成IP地址时，它依赖DNS递归解析器来执行此操作。该解析服务系统的运营商可以同时看到你的IP地址和查询的域名。

       你或你的任何设备访问互联网时，第一步通常是在域名系统（DNS）中查找域名（比如“google.com”或“princeton.edu”）以确定联系哪一个互联网地址。DNS本质上是互联网域名的电话簿。

       你运行的客户端（包括浏览器、智能手机和家里的任何物联网设备）把针对每个域名的DNS查询发送到所谓的“递归式DNS解析器”。在典型的家庭网络上，默认的递归式DNS解析器可能由互联网服务提供商（ISP，比如康卡斯特和Verizon）来运行。谷歌和Quad9等其他公司也运行任何人都可以使用的“开放式”递归解析器，其想法是：这些替代的递归解析器为用户提供了除ISP之外解析查询的另一种方案。过去，这种替代方法在规避审查方面很有用。

        DNS：互联网最大的隐私漏洞

        DNS查询通常以明文格式发送，它们会泄露互联网用户可能希望保密的重要信息，包括用户访问的网站、发出初始查询的那个设备的IP地址或子网，甚至包括用户在家庭网络中拥有的设备的类型。比如说，我们之前的研究表明，DNS查询可用于对来自Tor网络的流量进行去匿名化处理。

       由于查询和响应未经加密，任何第三方只要能查看客户端与递归解析器（即权威服务器）之间的通信内容，就能查看DNS解析过程中的各个步骤。

       递归式DNS解析器的运营商（通常是你的ISP）可以看到单个IP地址（这可能对应于ISP用户，或可能是单个最终用户）以及伴随查询的完全符合标准的域名，但是用户解析递归式DNS查询依赖的任何第三方（比如谷歌）通常也能看到。即便在权威解析器这种情况下，DNS的扩展（比如EDNS0 Client Subnet）可能也会将用户的IP地址或子网的信息泄露给DNS层次体系中更高层的DNS权威服务器。

       现有方法

       现有的拟议标准可保护用户隐私的某些方面，包括DNSQuery Name Minimization（DNS查询名称最小化）和DNSover TLS。

       然而，这些方法无法阻止递归式DNS服务器的运营商了解哪些IP地址针对特定的域名发出查询――这是DNS隐私方面的根本问题：

• DNS查询名称最小化提供了一种机制，那样对DNS域名层次体系中不同部分具有权威性的DNS服务器无法了解完整的DNS查询。比如说，对所有*.com具有权威性的服务器不一定了解针对maps.google.com的查询，只了解客户需要解析google.com的某个子域。然而，这种机制无法阻止递归式DNS解析器了解完整的DNS查询和发出查询的客户端的IP地址。

• DNS over TLS为加密DNS查询提供了一种机制。不过，即便使用DNSover TLS，递归解析器仍需要解密初始查询，那样它才能为客户端解析查询。它仍然无法阻止递归式DNS解析器了解查询和发送查询的IP地址。

       第三方最近一直在构建声称尊重用户隐私的新DNS解析器：Quad9（9.9.9.9）和Cloudflare的1.1.1.1就运行这种开放式DNS递归解析器，声称可以清除有关用户查询的信息。Cloudflare另外支持DNS over HTTPS：就像DNSover TLS那样，它确保从浏览器到递归式DNS解析器，DNS查询全程加密。

       然而在所有这些情况下，用户无法保证运营商了解的信息有没有保留以用于运营或其他目的。当然，一旦这类信息保留起来，用户隐私可能容易受到其他威胁，包括执法部门要求调阅数据。简而言之，这些服务只是将信任点从ISP转移到另外某个第三方，但你仍然得信任该第三方。

       Oblivious DNS

       虽然你可能有充分的理由相信提供商声称清除有关DNS查询的所有信息，但我们认为用户甚至本来就没必要作出这样的选择。

       Oblivious DNS（ODNS）的目的是，确保没有任何一方能观察到DNS查询和发出查询的IP地址（或子网）。ODNS作为传统DNS上的某种覆盖层来运行，它不需要改动已经部署的任何DNS基础设施。

       Oblivious DNS（ODNS）的工作方式类似传统DNS，但有两个新的部分：1）每个客户端运行本地ODNS存根解析器，2）我们添加了一个ODNS权威区域，该区域还作为递归式DNS解析器来运行。该图表明了基本方法。
 

       Oblivious DNS（ODNS）在客户端添加了一个自定义存根解析器（stub resolver），有意模糊原始查询，而ODNS权威服务器可以解密原始查询。但是ODNS权威服务器根本看不到发出查询的客户端的IP地址。

       客户端应用程序启动DNS查询时，客户端的存根解析器有意模糊客户端请求的那个域（通过对称加密），导致递归式解析器不知道请求的域。ODNS权威域名服务器将客户端的身份与对应的DNS请求分离开来，那样域名服务器就无法知道谁在请求特定的域。ODNS协议采取的步骤如下：

1. 客户端为www.foo.com生成请求时，存根解析器生成会话密钥k，对请求的域进行加密，并在后面添加TLD域名.odns，因而生成{www.foo.com}k.odns。

2. 客户端将此请求转发给递归解析器，会话密钥由DNS查询的“额外信息”记录中.odns服务器的公钥（{k}PK）来进行加密，然后递归解析器将请求转发给.odns的授权域名服务器。

3. ODNS查询的权威服务器使用其私钥对会话密钥进行解密，然后使用会话密钥对请求的域进行解密。

4. 权威服务器将递归DNS请求转发给原始域的相应域名服务器，然后该服务器将结果返回给ODNS权威服务器。

5. ODNS权威服务器因而可以将结果（域和IP地址都经过加密）返回给递归解析器，递归解析器将其转发给客户端的存根解析器。反过来，存根解析器可以对域和IP地址进行解密。

       其他域名服务器可以看到进入的DNS请求，但这些服务器只能看到ODNS递归解析器的IP地址，ODNS递归解析器实际上为原始客户端代理处理DNS请求。这些步骤对应于下图。

       原型实施和初步评估

       我们用Go语言实施了一个原型，以评估部署ODNS的可行性，还评估了使用ODNS相比使用传统DNS的性能开销。我们实施了一个ODNS存根解析器，并且实施了一台还能发出递归查询的权威域名服务器。

        ODNS使未缓存的DNS查询的解析时间增加了10-20毫秒。

        我们先将运行ODNS查询的性能开销与传统DNS作了一番比较。我们使用ODNS和传统DNS向AlexaTop 10000个域发出了DNS查询。下面的CDF显示，ODNS使每个查询增加了大约10-20毫秒。当然，实际上DNS广泛利用了缓存，这个实验表明的是最糟糕情况。我们预计实际上开销小得多。

        同样，我们评估了整个网页加载的开销（加载过程包括获取页面，并对页面中的嵌入式对象和资源进行任何后续的DNS查询），从而评估ODNS会如何影响典型互联网用户的浏览体验。我们使用ODNS获取了含有大量内容的热门网页，比较了执行同样操作的结果。

       加载整个网页的开销极小。

       在条形图的每五组中，图中的左侧条使用常规DNS，右侧条表示使用ODNS所花的时间。我们发现，ODNS和传统DNS在页面加载时间方面并没有显著差异，原因是DNS查询给整个页面加载过程带来的开销极小。与以前一样，这些实验是在使用“冷缓存”的情况下运行的，实际上我们预计开销还要小。

       总结和后续步骤

       过去几年，DNS查询暴露的隐私风险备受关注（这不无道理）。虽然允许用户使用替代DNS解析器的现有方法迈出了可喜的一步，但从某种意义上来说，它们只是将信任点从用户的ISP转移到另一方。我们认为，一种更好的最终状态是，用户不必信任任何DNS递归解析器的运营商。为了实现这个目标，我们开发出了ODNS，帮助客户身份与相应的DNS查询分离开来，还实施了一个原型。我们正在搞更大规模的实施、部署和评估工作。想了解ODNS的更多信息，请访问我们的项目网站（http://odns.cs.princeton.edu/）。我们欢迎任何反馈和意见。我们准备探究更广泛部署的机会，并在积极寻求合作伙伴，帮助我们在运营环境中部署ODNS解决方案。