使用代理服务器的客户端可以不配置dns_Cloudflare发布OdoH，改善DNS安全和隐私

日前，Cloudflare发布了一项用于改善DNS安全和隐私的新的DNS标准ODoH。标准由Cloudflare，Apple和Fastly的工程师共同撰写，标准通过将IP地址与查询分隔开，防止相关信息的泄露。Cloudflare也在Github开源了协议实现和客户端的源代码，可以让大家自己试运行和验证OdoH服务。

概述

域名系统(DNS)是人类可以使用的Internet的基础。它将可用的域名(例如cloudflare.com)映射到IP地址以及连接到该域所需的其他信息。在接入网络后设备与DNS解析器之间的网络路径上的任何人都可以看到包含所需主机名(或网站)的查询以及标识设备的IP地址。

为了保护DNS免受旁观者和第三方的侵害，IETF推出了基于HTTPS上的DNS(DoH)和TLS协议DNS(DoT)对DNS传输进行标准化加密。两种协议都可以防止DNS查询在中间过程中被拦截，重定向或篡改。目前很多客户端系统，包括新版本的Firefox，iOS等中都已经实现了对DoT和DoH的支持，但是还未得到全网范围的广泛部署和支持。

基于但是使用对DoT和DoH后目，存在着两个明显的问题：一个是集中化的DNS会引入单点故障。

另一个问题是解析器仍然将所有查询链接到客户端IP地址。

为了解决这个问题， Cloudflare和合作伙伴推出了一个改进的协议，该协议可以实现以下功能：HTTPS Oblivious DNS，或简称ODoH。这些合作伙伴包括PCCW，SURF和Equinix。

OdoH工作原理

ODoH是IETF正在开发的新协议。ODoH通过添加一层公共密钥加密机制以及客户端和DoH服务器之间的网络代理(例如1.1.1.1)来工作。通过两个添加元素的组合确保只有查询用户才能同时访问DNS消息和及其IP地址。

OdoH实现中有三个参与者。目标服务器通过代理解密由客户端加密的查询。同样，目标对响应进行加密并将其返回给代理。目标可以是解析器，也可以不是。代理服务器只负责在客户端和目标之间消息转发。客户端行为与在DNS和DoH中的行为相同，但是通过对目标的查询进行加密并解密目标的响应来进行区别。选择这样做的任何客户端都可以指定代理和选择的目标。

增加的添加的加密和机制和代理提供了以下保证：

目标仅可以查看查询和代理的IP地址。

代理无法查看DNS消息，无法识别，读取或修改客户端发送的查询或目标返回的答案。

只有预期的目标才能读取查询的内容并发出响应。

这三个保证在保持DNS查询的安全性和完整性的同时改善了客户端的隐私。但是这些保证中的每一项都依赖于一个基本属性：代理服务器和目标服务器不相互影响。只要两者没有串通，攻击者只有全部拿下代理服务器和目标服务器才能成功。

在该体系架构中目标与执行DNS解析的上游递归解析器是分开的。同样，重要的是，客户可以完全控制代理和目标选择。无需任何类似TRR的程序，客户端除了安全性之外，还可以保留其查询的隐私权。由于目标只和代理联系，目标服务器和任何上游解析程序都不能获得客户端IP地址。这样客户可以更好地控制其查询及其使用方式。例如，客户可以出于任何原因随时选择和更改代理和目标服务器。

ODoH消息流

在ODoH中，"O"表示Oblivious(遗忘)，该属性来自DNS消息本身的加密级别。加密是客户端和目标之间的"端到端"，并且独立于TLS/HTTPS提供的连接级加密。有人可能会问为什么在存在代理的情况下还需要额外的加密。因为需要两个单独的TLS连接来支持代理功能。具体来说，代理会终止来自客户端的TLS连接，并启动到目标的另一个TLS连接。在这两个连接之间，DNS消息上下文将以纯文本形式显示。为此，ODoH还会在客户端和目标之间加密消息，这样代理无法访问消息内容。

整个过程从客户端使用HPKE加密对目标的查询开始。客户端通过DNS获取目标的公钥，并将其捆绑到HTTPS资源记录中并由DNSSEC保护。当此密钥的TTL过期时，客户端会根据需要请求密钥的新副本(就像A/AAAA记录的TTL过期时一样)。使用目标的DNSSEC验证的公共密钥可确保只有目标目标可以解密查询并加密响应。

客户端通过HTTPS连接将这些加密的查询传输到代理。收到后，代理将查询转发到指定目标。然后目标解密该查询，通过将查询发送到递归解析器(例如1.1.1.1)来生成响应，然后将响应加密到客户端。来自客户端的加密查询包含封装的密钥材料，目标可从中获得响应加密对称密钥。

然后将该响应发送回代理，然后转发给客户端。尽管这些DNS消息是通过两个单独的HTTPS连接(客户端代理和代理目标)传输的，但所有通信都是经过端到端加密的，因此所有通信都经过身份验证和保密。否则在代理中显示为纯文本的消息实际上是加密的乱码。

性能测试

Tranco百万数据集中随机选择了10,000个域，统计了使用不同公钥对A记录的加密及其解密。结果中，99%的代理的DoH查询/响应与其ODoH对应对象之间的额外开销始终小于1毫秒。

但是，ODoH请求：响应管道不仅限于加密。查看度量的一种非常有用的方法是查看累积分布图。下图显示了通过Tor网络传输时DoH，ODoH和DoH中查询/响应时间的累积分布。从左侧开始的水平虚线是50%标记。沿着该水平线，对于任何绘制的曲线，虚线下方的曲线部分为数据点的50%。x轴是时间的度量。左边的线比右边的线变化的快。最后一个重要的细节是x轴以对数刻度绘制，标记的标记之间的距离(10x)在累积分布中相等，但是'x'是指数，代表数量级。因此，尽管前两个标记之间的时间差为9毫秒，但第3个标记和第4个标记之间的时差为900毫秒。

在图表中，中间曲线代表ODoH测量值。还测量了隐私保护方案的性能，例如，通过Tor网络传输的DoH查询，如图表中的右曲线所示。与其他面向隐私的DNS变体相比，ODoH将查询时间缩短了一半甚至更好。

在不到228毫秒的时间内，解决ODoH查询的时间占50%。现在，将中间线与代表"直线"(或正常)DoH的左侧线进行比较，而无需进行任何修改。左边的绘图线表示，在50%的时间内，DoH查询在不到146ms的时间内得到解决。从低于50%的标记看，差值的时间永远不会大于100ms。

这些曲线还隐藏了很多信息，因此深入研究测量值很重要。下表具有三个不同的累积分布曲线，这些曲线描述了我们通过代理和目标的延迟来选择ODoH的性能。这也是测量曲线中，其中一些是违反直觉的。例如，0.5之上看，这些曲线表明，无论选择代理和目标，ODOH查询/响应时间的50%实际上是无法区分的。在0.5以下，并将两条实线与代表整体平均值的虚线相比较。该区域表明选择最低延迟代理和目标对平均值的改进很小。最重要的是，其表明选择最低延迟代理会导致性能变差。

OdoH验证

目前Cloudflare已经开源了odoh-rs(Rust)和odoh-go(Golang)中开源了可互

操作的OdoH服务器实现，并将目标集成到了Cloudflare DNS解析器中。

还开源了odoh-client-rs( Rust)和odoh-client-go(Golang)客户演示ODoH查询。

1.1.1.1公共DNS中已经支持ODoH查询。可以通过直接查询由OdoH加密的HPKE配置：