10

ODNS：保护DNS隐私的新标准

 4 years ago
source link: https://my.oschina.net/u/4888052/blog/4816768
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client
ODNS：保护DNS隐私的新标准 - 哇噢拜戈的个人空间 - OSCHINA - 中文开源技术交流社区

最近，Cloudflare在官方博客上宣布，他们和Apple、Fastly公司的工程师一起合作，开始支持一种新提议的DNS标准——ODNS。这种新标准声称能够保护用户在执行DNS请求时的隐私。在介绍ODNS之前，我们需要先回顾一下现在域名系统的架构。

域名系统的特点是分级、去中心化。一共分为了递归解析器、权威域名服务器、顶级域名服务器、根服务器四个等级。

DNS

当用户发起DNS请求时，会经历以下流程：

  1. 用户本机的解析器（Stub Resolver）向递归解析器（Recursive Resolver）发起请求。
  2. 如果递归解析器缓存了该域名，直接返回结果。如果没有缓存，则向根服务器请求。
  3. 根服务器向递归解析器返回顶级域服务器的地址。递归解析器向顶级域名服务器请求。
  4. 顶级域名服务器返回权威域名服务器的地址。递归解析器向权威域名服务器发起请求。
  5. 递归解析器收到权威域名服务器解析后的IP地址，返回给本机解析器。

在传统的DNS协议中，请求和响应都是明文的，也就是说，在发起请求的各个阶段，中间的操作者都能够看到一些信息。其中，递归解析器能够看到是谁请求了什么域名。由ISP提供的DNS服务器是递归解析器，被发现通常会收集大量个人信息，出售给广告商以获利。另外，明文的域名请求也使得政府的监管成为了可能。一旦请求恶意的网站，监管机构就能够切断对该网站的访问。

加密的域名请求

域名系统遇到的问题和HTTP非常类似。自然而然地，给DNS请求加密的标准被提了出来，一共有三种：DNS-over-TLS、DNS-over-DTLS、DNS-over-HTTPS。它们的目的都是通过一种公钥加密算法给DNS请求加密，从而防止用户的隐私被ISP侵犯。但是，这也带来了相同的问题，作为DNS请求操作者的公司就是值得信任的吗，比如Cloudflare和Google？这个方案不过是把信任从ISP放到了提供加密DNS请求服务的提供者上。

ODNS基本流程

为了解决上面DOT等标准无法解决的隐私问题，ODNS被提了出来。ODNS是Oblivious DNS的简写，由普林斯顿大学的Paul Schmitt、Anne Edumundson等人于2018年提出，未来将会形成一份IETF的标准。

ODNS的基本思想是在递归解析器和其它域名服务器之间加入一个服务器——ODNS服务器，由ODNS服务器去完成域名的递归解析。原来的递归解析器这时充当的是一个代理。ODNS的协议不仅能够保证递归解析器只能够知道是谁发起了请求，但不知道请求了什么，还能够保证ODNS服务器只知道请求的内容，但不知道是谁发起了这次请求。换句话说，处理DNS请求的各个节点服务器都没有办法把请求者和请求的内容联系起来，因此，保护了用户的隐私。

ODNS

ODNS请求的流程如下：

  1. 当客户端请求域名时，本地解析器生成对称会话密钥，使用这个密钥加密域名，生成字符串s1。之后再使用ODNS服务器的公钥加密会话密钥，生成字符串s2。把整个加密后的字符串和ODNS的域名拼接在一起，形成一个新的域名请求——{s1}{s2}.odns。
  2. 发送域名请求给递归解析器，递归解析器把域名发送给权威域名服务器查找特定的odns域名。
  3. ODNS解析器收到请求的域名，解密出会话密钥，再用会话密钥解密出真正想要请求的域名。
  4. ODNS解析器按照递归解析器的流程解析该域名，从其它服务器获得响应。
  5. ODNS解析器把响应加密后返回给客户端的递归解析器。
  6. 递归解析器把已经加了密的响应内容返回给本机解析器。

在上述流程中，ODNS解析器既是一个权威域名服务器，又是一个递归解析器。在接收ODNS后缀形式的域名请求时，它是权威域名服务器。在返回ODNS后缀形式的域名请求响应时，它是一个递归解析器。根域名服务器、其它权威域名服务器只能够看到ODNS发起了请求，但不知道背后真正发起请求的人是谁。客户端的递归解析器只能够看到客户端发起了请求，也不知道客户端到底请求了什么。而ODNS解析器虽然知道请求的内容是什么，但是它只能够看到客户端的递归解析器的地址，看不到客户端的真实地址。所以，在DNS的解析流程中，没有任何一个服务器能够同时看到请求者和请求的内容，除非递归解析器和ODNS是同一个服务器。

任播（anycast）是一种路由策略，可以选择若干目的节点中的一个作为数据报文的目的地，也即是一对多个中的一个，相比之下，多播（multicast）是一对多的。ODNS使用任播来实现ODNS解析服务器的复制，从而提高可用性和性能。在地理位置上，可以优先由离用户最近的ODNS解析服务器提供服务。当其中一个节点下线后，还有其它的节点提供服务。

ODNS的问题

尽管ODNS为用户带来了一定程度上的隐私保证，但它也引入了新的问题，这些问题中最重要的是性能问题。ODNS的加密和协议交互相比原有的会有额外的性能开销。同时，每一次请求都使用不同的对称密钥，会造成递归解析器的缓存失效，也就是说，即使请求相同的域名，但是递归解析器看到的是不同的内容，因此都会向ODNS发起解析请求。缓存失效带来了两个结果，一个是请求时间增加，另一个是网络中的流量会增多。

另外，ODNS的隐私保证是建立在一个前提之上——ODNS解析服务器的提供者和递归解析器的提供者不能是同一个人，或者说，他们没有共谋。在现实中，这样的假设可能很容易就被打破。

ODoH（Oblivious DNS over HTTPS）

文章最开头提到Cloudflare和Apple等公司开始支持这一新标准。它们基于这个新标准，设计、提出了ODNS的一种具体实现——ODoH，并部署到了现实环境中进行测试，以衡量它对网络的实际影响。另外，Cloudflare还开源了分别用Rust、Go语言编写的ODoH库，使用这个库可以实现ODoH的客户端、服务器程序。

[1]《Improving DNS Privacy with Oblivious DoH in 1.1.1.1》. https://blog.cloudflare.com/oblivious-dns/ (见于 12月 15, 2020).

[2]P. Schmitt, A. Edmundson, A. Mankin和N. Feamster, 《Oblivious DNS: Practical Privacy for DNS Queries》, Proceedings on Privacy Enhancing Technologies, 卷 2019, 期 2, 页 228–244, 4月 2019, doi: 10/ghn828.

[3]《[2011.10121] Oblivious DNS over HTTPS (ODoH): A Practical Privacy Enhancement to DNS》. https://arxiv.org/abs/2011.10121 (见于 12月 20, 2020).

[4]《Cloudflare and Apple design a new privacy-friendly internet protocol | TechCrunch》. https://techcrunch.com/2020/12/08/cloudflare-and-apple-design-a-new-privacy-friendly-internet-protocol (见于 12月 19, 2020).

[5]《cloudflare/odoh-rs: Oblivious DoH library in Rust》. https://github.com/cloudflare/odoh-rs/ (见于 12月 20, 2020).


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK