ODNS:保护DNS隐私的新标准 – 作者:ja50n

最近,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).

来源:freebuf.com 2020-12-20 09:29:18 by: ja50n

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论