今天，我们宣布支持一项由 Cloudflare、Apple 和 Fastly 工程师共同撰写的新 DNS 提议标准。该标准将 IP 地址与查询分离，从而没有任何单一实体可以同时看到这两者。
更好的是，我们已经公开了源代码，任何人都可以试用 ODoH，或者运行自己的 ODoH 服务！
首先，让我们了解一下背景。域名系统 (DNS) 是互联网可供人类使用的基础。它将可用的域名（例如 cloudflare.com）映射到 IP 地址以及连接到该域名所需的其他信息。关于 DNS 的重要性和问题的快速入门知识，可以阅读之前的博文。对于本文而言，只需知道在 DNS 的初始设计以及仍然占主导地位的使用方式中，查询是以明文形式发送的。
这意味着，在您的设备和 DNS 解析器之间的网络路径上的任何人，都可以看到包含您想要的hostname（或网站）的查询，以及标识您设备的 IP 地址。
为了保护 DNS 免受窥探者和第三方的监视，IETF 将 DNS 加密标准化，推出了 DNS over HTTPS (DoH) 和 DNS over TLS (DoT)。这两种协议都可以防止客户端和解析器之间的查询被拦截、重定向或修改。
包括 Firefox、iOS 等在内的最新版本都已经实现了对 DoT 和 DoH 的客户端支持，且支持范围正在扩大。
即便如此，在互联网服务提供商更广泛地部署之前，Cloudflare 仍然是为数不多提供公共 DoH/DoT 服务的提供商之一。 这引发了两个主要的担忧。
一个担忧是 DNS 的中心化引入了单点故障（尽管 Cloudflare 在 100 多个国家/地区设有数据中心，旨在始终保持可访问性）。
另一个担忧是，解析器仍然可以将所有查询与客户端 IP 地址关联起来。
Cloudflare 致力于保护最终用户的隐私。我们公共 DNS 解析器服务的用户受到强大且经过审计的隐私政策的保护。然而，对于某些人来说，即使有如此强有力的隐私政策，信任 Cloudflare 处理敏感的查询信息仍然是采用该服务的障碍。
与其依赖隐私政策和审计，我们是否可以为用户提供一种通过技术保障来消除这种障碍的选项呢？
今天，Cloudflare 和合作伙伴正在推出对一种协议的支持，该协议正是为此而生的：Oblivious DNS over HTTPS，简称 ODoH。
Oblivious DNS over HTTPS (ODoH)是如何工作的？
ODoH 是 IETF 正在开发的一种新兴协议。
ODoH 的工作原理是在客户端和 DoH 服务器（如 1.1.1.1）之间添加一层公钥加密以及一个网络代理。这两个新增元素的结合保证了只有用户可以同时访问 DNS 消息和他们自己的 IP 地址。
ODoH 路径中有三个参与者。 参照上图，我们从目标 (target) 开始。目标通过代理解密客户端加密的查询。 同样，目标加密响应并将它们返回给代理。 标准规定，目标可以是也可以不是解析器（我们稍后会谈到这一点）。 代理的作用正如代理应该做的那样，即在客户端和目标之间转发消息。 客户端的行为与在 DNS 和 DoH 中的行为相同，但不同之处在于它为目标加密查询，并解密目标的响应。 任何选择这样做的客户端都可以指定自己选择的代理和目标。
加密和代理的结合提供了以下保证：
目标只能看到查询和代理的 IP 地址。
代理无法看到 DNS 消息，也无法识别、读取或修改客户端发送的查询或目标返回的答案。
只有预期的目标可以读取查询的内容并生成响应。
这三项保证在提高客户端隐私的同时，维护了 DNS 查询的安全性和完整性。 然而，这些保证中的每一项都依赖于一个基本属性——代理和目标服务器之间不会串通。 只要没有串通，攻击者只有在代理和目标都被攻破的情况下才能成功。
值得强调的是，该系统的一个方面是，目标 (target) 与执行 DNS 解析的上游递归解析器是分开的。但在实践中，为了性能考虑，我们预计目标将是相同的。
事实上，1.1.1.1 现在既是递归解析器又是目标！ 没有任何理由要求目标必须独立于任何解析器而存在。 如果它们是分开的，那么目标可以自由选择解析器，而只是充当中间人。
请记住，唯一真正的要求是代理和目标永远不会串通。
同样重要的是，客户端完全控制代理和目标的选择。 无需任何类似 TRR 的程序，客户端除了安全性之外，还可以保护其查询的隐私。 由于目标只知道代理，因此目标和任何上游解析器都不知道任何客户端 IP 地址的存在。
重要的是，这使客户端能够更好地控制他们的查询以及查询可能被使用的方式。 例如，客户端可以随时出于任何原因选择和更改其代理和目标！
ODoH 消息流
在 ODoH 中，“O”代表隐蔽性 (oblivious)，这种特性源于 DNS 消息本身的加密级别。
这种额外的加密是客户端和目标之间的“端到端”加密，并且独立于 TLS/HTTPS 提供的连接级加密。 有人可能会问，在存在代理的情况下，为什么还需要这种额外的加密。
这是因为需要两个独立的 TLS 连接来支持代理功能。 具体来说，代理终止来自客户端的 TLS 连接，并启动到目标的另一个 TLS 连接。
在这两个连接之间，DNS 消息内容原本会以明文形式出现！ 因此，ODoH 额外加密客户端和目标之间的消息，以便代理无法访问消息内容。
整个过程从客户端开始，客户端使用 HPKE 为目标加密其查询。 客户端通过 DNS 获取目标的公钥，该公钥捆绑在 HTTPS 资源记录中，并受到 DNSSEC 的保护。 当此密钥的 TTL 过期时，客户端会根据需要请求密钥的新副本（就像在 A/AAAA 记录的 TTL 过期时请求这些记录一样）。
使用经过 DNSSEC 验证的目标公钥，保证了只有预期的目标才能解密查询并加密响应（answer）。
客户端通过 HTTPS 连接将这些加密的查询传输到代理。 收到后，代理将查询转发到指定的目标。
然后，目标解密查询，通过将查询发送到递归解析器（如 1.1.1.1）来生成响应，然后将响应加密给客户端。
来自客户端的加密查询包含封装的密钥材料，目标从中派生出响应加密对称密钥。
然后，此响应被发回给代理，随后再转发给客户端。
所有通信都是经过身份验证和保密的，因为这些 DNS 消息是端到端加密的，即使它们是通过两个独立的 HTTPS 连接（客户端-代理和代理-目标）传输的也是如此。
否则以明文形式出现在代理面前的消息，实际上是一段加密的乱码。
性能表现如何？我是否必须为了隐私而牺牲性能？
为了找到答案，我们进行了大量的测量，并且随着 ODoH 的更广泛部署，我们将进行更多测量。我们最初的测量配置涵盖了美国、加拿大和巴西的城市。
重要的是，我们的测量不仅包括 1.1.1.1，还包括 8.8.8.8 和 9.9.9.9。到目前为止，完整的测量结果已记录在案，可公开访问。
在这些测量中，重要的是将代理和额外加密的成本与 TCP 和 TLS 连接建立的成本隔离开来。这是因为 TLS 和 TCP 成本无论如何都会由 DoH 产生。
因此，在我们的设置中，我们通过建立一次连接并将该连接重用于所有测量来“预热”测量。我们对 DoH 和 ODoH 都这样做了，因为相同的策略可以用于这两种情况。
我们可以自信地说，额外的加密成本微乎其微。我们之所以知道这一点，是因为我们从 Tranco 百万数据集 中随机选择了 10,000 个域名，并测量了使用不同公钥加密 A 记录以及解密 A 记录的时间。在第 99 个百分位数，代理 DoH 查询/响应与其 ODoH 对应项之间的额外成本始终小于 1 毫秒。
然而，ODoH 请求-响应管道不仅仅是加密。查看测量的累积分布图是一种非常有用的方法——如果您熟悉这类图表，请跳到下一段。与大多数从 x 轴开始的图表不同，对于累积分布图，我们通常从 y 轴开始。
下图显示了 DoH、ODoH 以及通过 Tor 网络传输的 DoH 的查询/响应时间的累积分布。从左侧 0.5 开始的虚线水平线是 50% 的标记线。沿着这条水平线，对于任何绘制的曲线，曲线在虚线下方的部分是 50% 的数据点。现在看 x 轴，它是时间的度量。出现在左侧的线比右侧的线更快。最后一个重要的细节是 x 轴以对数刻度绘制。这意味着什么？请注意，在累积分布图中，标记之间的距离（10 倍）是相等的，但“x”是指数，代表数量级。因此，虽然前两个标记之间的时间差为 9 毫秒，但第 3 个和第 4 个标记之间的差异为 900 毫秒。
在此图表中，中间的曲线代表 ODoH 测量结果。我们还测量了隐私保护替代方案的性能，例如，通过 Tor 网络传输的 DoH 查询，如图表中的右侧曲线所示。（其他隐私保护替代方案在公开访问的技术报告中有所记录。）与其他面向隐私的 DNS 变体相比，ODoH 将查询时间缩短了一半甚至更多。这一点非常重要，因为隐私和性能很少能很好地兼顾，因此看到这种改进令人鼓舞！
上图还告诉我们，50% 的情况下，ODoH 查询在不到 228 毫秒内得到解析。现在将中间的线与左侧的线进行比较，左侧的线代表“直线”（或普通）DoH，没有任何修改。
左侧的曲线表示，50% 的情况下，DoH 查询在不到 146 毫秒内得到解析。查看 50% 标记线以下，曲线还告诉我们，一半的时间，这种差异永远不会超过 100 毫秒。另一方面，查看 50% 标记线以上的曲线告诉我们，一半的 ODoH 查询与 DoH 具有竞争力。
这些曲线也隐藏了很多信息，因此深入研究测量结果非常重要。下图具有三条不同的累积分布曲线，描述了如果我们根据延迟选择代理和目标，ODoH 的性能。
这也是测量可以揭示的见解的一个例子，其中一些见解是违反直觉的。
例如，查看 0.5 以上，这些曲线表示，无论选择哪个代理和目标，一半的 ODoH 查询/响应时间几乎没有区别。
现在将注意力转移到 0.5 以下，并将两条实线曲线与代表总体平均值的虚线曲线进行比较。
该区域表明，选择最低延迟的代理和目标提供的改进相对于平均水平而言微乎其微，但最重要的是，它表明选择最低延迟的代理会导致更差的性能！
当然，仍然存在一些未决问题。第一组测量主要在北美执行。在全球范围内，性能会发生变化吗？这在实践中会如何影响客户端性能？
我们正在努力找出答案，而这次发布将帮助我们做到这一点。
有趣！我可以试用 ODoH 吗？是否有公开的 ODoH 服务？
是的，都有！我们已经开源了 Rust 语言的 odoh-rs 和 Go 语言的 odoh-go 这两个可互操作的 ODoH 实现，并将目标集成到了 Cloudflare DNS 解析器中。没错，1.1.1.1 已经准备好接收通过 ODoH 发出的查询了。
我们还开源了 Rust 语言的 odoh-client-rs 和 Go 语言的 odoh-client-go 这两个测试客户端，用于演示 ODoH 查询。您还可以通过直接查询服务来查看 ODoH 用于消息加密到 1.1.1.1 的 HPKE 配置：
1 | $ dig -t type65 +dnssec @ns1.cloudflare.com odoh.cloudflare-dns.com |
我们正在努力将 ODoH 添加到现有的 stub 解析器中，例如 cloudflared。如果您有兴趣为客户端添加支持，或者如果您在实现中遇到错误，请发送邮件至 [email protected] 联系我们！有关 ODoH 规范和服务器的公告将发送到 IETF DPRIVE 邮件列表。您可以在此处订阅并关注有关规范的公告和讨论。
我们致力于在 IETF 中推进它，并且已经看到来自客户端供应商的兴趣。Firefox 的 CTO Eric Rescorla 表示：
Oblivious DoH 是安全 DNS 生态系统的一个重要补充。我们很高兴看到它开始兴起，并期待在 Firefox 中对其进行实验。
我们希望更多的运营商加入我们，通过运行代理或目标来为该协议提供支持，并且我们希望随着可用基础设施的增加，客户端支持也会增加。
ODoH 协议是提高用户隐私的一种实用方法，旨在提高加密 DNS 协议的总体采用率，同时不影响互联网上的性能和用户体验。