使用 Oblivious DoH 改进 DNS 隐私
域名系统 (DNS) 是人类可用互联网的基础。它将可用域名（例如 域名）映射到连接到该域所需的 IP 地址和其他信息。有关 DNS 的重要性和问题的快速入门可以在之前的博客文章中阅读。对于这篇文章，知道在 DNS 的初始设计和仍然占主导地位的使用中，查询以明文形式发送就足够了。这意味着您的设备和 DNS 解析器之间的网络路径上的任何人都可以看到包含您想要的主机名（或网站）的查询，以及标识您设备的 IP 地址。
为了保护 DNS 免受旁观者和第三方的侵害，IETF 使用 DNS over HTTPS (DoH) 和 DNS over TLS (DoT) 标准化了 DNS 加密。这两种协议都可以防止查询在客户端和解析器之间被拦截、重定向或修改。对 DoT 和 DoH 的客户端支持正在增长，已在最新版本的 Firefox、iOS 等中实现。即便如此，在 Internet 服务提供商之间进行更广泛的部署之前，Cloudflare 是少数提供公共 DoH/DoT 服务的提供商之一。这引起了两个主要问题。一个问题是 DNS 的集中化会引入单点故障（尽管 Cloudflare 的数据中心遍布 100 多个国家/地区，但其设计宗旨是始终可以访问）。另一个问题是解析器仍然可以将所有查询链接到客户端 IP 地址。
Cloudflare 和合作伙伴正在推出对一种协议的支持：基于 HTTPS 的 Oblivious DNS，或简称为 ODoH。
ODoH 合作伙伴：
几家同样致力于保护隐私的领先合作伙伴共同推出 ODoH。
ODoH 的一个关键组件是与目标解析器不相交的代理。几个领先的代理合作伙伴一起推出 ODoH，包括：PCCW、SURF 和 Equinix。
“ODoH 是一个革命性的新概念，旨在让用户的隐私成为一切的中心。我们与 Cloudflare 的 ODoH 合作伙伴关系使我们在隐私和“互联网基础设施”领域处于有利地位。除了可通过 Console Connect 按需访问的底层 PCCW Global 网络的增强安全性和性能外，Cloudflare 的 1.1.1.1 解析器现在改进了我们网络上代理的性能。该模型首次将客户端代理与解析器完全解耦。随着世界转向更远程的模式并且隐私成为一个更加重要的特征，这种伙伴关系加强了我们对隐私的现有关注。” -- Michael Glynn，PCCW Global 数字自动化创新副总裁
“我们正在与 Cloudflare 合作，通过 ODoH 实现更好的用户隐私。转向 ODoH 是一种真正的范式转变，用户的隐私或 IP 地址不会暴露给任何提供商，从而实现真正的隐私。随着 ODoH-pilot 的推出，我们正在加入 Cloudflare 网络的力量，以应对全球任何用户的挑战。转向 ODoH 不仅是一种范式转变，而且它强调隐私对任何用户来说比以往任何时候都重要，尤其是在 2020 年。它与我们对隐私的核心关注和信念产生共鸣。” — Joost van Dijk，SURF 技术产品经理
Oblivious DNS over HTTPS (ODoH) 如何工作？
ODoH 是IETF正在开发的新兴协议。ODoH 通过添加一层公钥加密以及客户端和 DoH 服务器（例如 1.1.1.1）之间的网络代理来工作。这两个添加元素的组合确保只有用户可以同时访问 DNS 消息和他们自己的 IP 地址。
ODoH 路径中有三个参与者。看上图，让我们先从目标开始。目标通过代理解密由客户端加密的查询。同样，目标加密响应并将它们返回给代理。标准说目标可能是也可能不是解析器。代理作为代理应该做的事情，因为它在客户端和目标之间转发消息。客户端的行为与它在 DNS 和 DoH 中的行为一样，但不同之处在于对目标的查询进行加密，并对目标的响应进行解密。任何选择这样做的客户端都可以指定选择的代理和目标。
添加的加密和代理一起提供了以下保证：
目标只能看到查询和代理的 IP 地址。
代理无法查看 DNS 消息，无法识别、读取或修改客户端发送的查询或目标返回的答案。
只有预期的目标才能读取查询的内容并产生响应。
这三个保证提高了客户端隐私，同时保持了 DNS 查询的安全性和完整性。然而，这些保证中的每一个都依赖于一个基本属性——代理和目标服务器不会串通。只要没有勾结，只有当代理和目标都受到威胁时，攻击者才能成功。
该系统值得强调的一个方面是目标与执行 DNS 解析的上游递归解析器是分开的。在实践中，对于性能，我们期望目标是相同的。事实上，1.1.1.1 现在既是递归解析器又是目标！没有理由认为目标需要与任何解析器分开存在。如果它们分开，那么目标可以自由选择解析器，并且只是充当中间人。请记住，唯一真正的要求是代理和目标永远不会串通。
此外，重要的是，客户端可以完全控制代理和目标选择。无需任何类似 TRR的程序，除了安全性之外，客户还可以拥有查询的隐私。由于目标只知道代理，因此目标和任何上游解析器都不会注意到任何客户端 IP 地址的存在。重要的是，这使客户可以更好地控制他们的查询及其可能的使用方式。例如，客户可以出于任何原因随时选择和更改他们的代理和目标！
ODoH 消息流
在 ODoH 中，“O”代表不经意，这个属性来自 DNS 消息本身的加密级别。这种添加的加密是客户端和目标之间的“端到端”加密，独立于 TLS/HTTPS 提供的连接级加密。有人可能会问，为什么在代理存在的情况下需要这种额外的加密。这是因为需要两个单独的 TLS 连接来支持代理功能。具体来说，代理终止来自客户端的 TLS 连接，并向目标发起另一个 TLS 连接。在这两个连接之间，DNS 消息上下文将以明文形式出现！出于这个原因，ODoH 额外加密客户端和目标之间的消息，因此代理无法访问消息内容。
整个过程从使用HPKE加密对目标的查询的客户端开始。客户端通过 DNS 获取目标的公钥，将其捆绑到HTTPS 资源记录中并受 DNSSEC 保护。当此密钥的 TTL 到期时，客户端会根据需要请求密钥的新副本（就像 A/AAAA 记录在该记录的 TTL 到期时所做的那样）。目标的 DNSSEC 验证公钥的使用保证只有预期的目标才能解密查询并加密响应（答案）。
客户端通过 HTTPS 连接将这些加密查询传输到代理。收到后，代理将查询转发到指定的目标。目标然后解密查询，通过将查询发送到递归解析器（例如 1.1.1.1）来生成响应，然后将响应加密到客户端。来自客户端的加密查询包含封装的密钥材料，目标从中导出响应加密对称密钥。
然后将此响应发送回代理，然后转发给客户端。尽管通过两个单独的 HTTPS 连接（客户端代理和代理目标）传输，但所有通信都经过身份验证和保密，因为这些 DNS 消息是端到端加密的。否则以明文形式呈现给代理的消息实际上是加密的乱码。
性能怎么样？我是否必须牺牲性能才能获得隐私？
在测量中，将代理和额外加密的成本与 TCP 和 TLS 连接设置的成本隔离是很重要的。这是因为 TLS 和 TCP 成本是由 DoH 承担的。
从Tranco 百万数据集中随机选择了 10,000 个域，并测量了使用不同公钥对 A 记录的加密及其解密。代理 DoH 查询/响应与其 ODoH 对应物之间的额外成本在第 99 个百分位始终小于 1 毫秒。
然而，ODoH 请求-响应管道不仅仅是加密，与我们从 x 轴开始的大多数图表相反，对于累积分布，我们通常从 y 轴开始。
下图显示了通过 Tor 网络传输时 DoH、ODoH 和 DoH 中查询/响应时间的累积分布。从 0.5 左侧开始的水平虚线是 50% 标记。沿着这条水平线，对于任何绘制的曲线，虚线下方的曲线部分是数据点的 50%。现在看看 x 轴，它是时间的度量。出现在左边的线比右边的线快。最后一个重要细节是 x 轴绘制在对数刻度上。这是什么意思？请注意，标记标记之间的距离 (10x) 在累积分布中相等，但“x”是指数，代表数量级。因此，虽然前两个标记之间的时间差为 9ms，但第 3 个和第 4 个标记之间的时间差为 900ms。
在此图表中，中间曲线代表 ODoH 测量值。测量了隐私保护替代方案的性能，例如，通过 Tor 网络传输的 DoH 查询，如图中右侧曲线所示。（在开放访问技术报告中捕获了其他隐私保护替代方案。）与其他面向隐私的 DNS 变体相比，ODoH 将查询时间缩短了一半或更好。这一点很重要，因为隐私和性能很少能很好地结合在一起，所以看到这种改进是令人鼓舞的！
上图还告诉我们，50% 的 ODoH 查询在不到 228 毫秒的时间内得到解决。现在将中间线与代表“直线”（或正常）DoH 的左侧线进行比较，无需任何修改。左边的情节线表明，在 50% 的情况下，DoH 查询在不到 146 毫秒的时间内得到解决。从 50% 标记以下看，曲线还告诉我们 1/2 的时间差异永远不会大于 100 毫秒。另一方面，查看 50% 标记以上的曲线告诉我们，½ ODoH 查询与 DoH 具有竞争力。
这些曲线还隐藏了很多信息，因此深入研究测量结果非常重要。下图包含三个不同的累积分布曲线，这些曲线描述了按延迟选择代理和目标时的 ODoH 性能。这也是测量可以揭示的洞察力的一个例子，其中一些是违反直觉的。例如，在 0.5 以上时，这些曲线表明 1/2 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 配置：
$ dig -t type65 +dnssec @域名 域名dflare-域名 ; <<>> DiG 域名.6 <<>> -t type65 +dnssec @域名 域名dflare-域名 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19923 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;域名dflare-域名. IN TYPE65 ;; ANSWER SECTION: 域名dflare-域名. 300 IN TYPE65 \# 108 00010000010003026832000400086810F8F96810F9F9000600202606 470000000000000000006810F8F92606470000000000000000006810 F9F98001002E002CFF0200280020000100010020ED82DBE32CCDE189 BC6C643A80B5FAFF82548D21601C613408BACAAE6467B30A 域名dflare-域名. 300 IN RRSIG TYPE65 13 3 300 20201119163629 20201117143629 34505 域名dflare-域名. yny5+ApxPSO6Q4aegv09ZnBmPiXxDEnX5Xv21TAchxbxt1VhqlHpb5Oc 8yQPNGXb0fb+NyibmHlvTXjphYjcPA== ;; Query time: 21 msec ;; SERVER: 域名.100#53(域名.100) ;; WHEN: Wed Nov 18 07:36:29 PST 2020 ;; MSG SIZE rcvd: 291
ODoH 协议是一种改善用户隐私的实用方法，旨在在不影响 Internet 性能和用户体验的情况下提高加密 DNS 协议的整体采用率。
