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

域名系统

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

当用户发起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请求的流程如下：

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).