通过遗忘的DoH改善DNS隐私
今天，我们宣布支持新提议的DNS标准，该标准由Cloudflare，Apple和Fastly的工程师共同撰写，该标准将IP地址与查询分隔开，因此没有一个实体可以同时看到两者。更好的是，我们提供了源代码，因此任何人都可以试用ODoH或运行自己的ODoH服务！
但是首先，有一点背景。域名系统（DNS）是人类可以使用的Internet的基础。它将可用的域名（例如cloudflare.com）映射到IP地址以及连接到该域所需的其他信息。有关DNS的重要性和问题的快速入门可以在以前的博客文章中阅读。对于这篇文章，足以知道，在DNS的最初设计和仍然占主导地位的用法中，以明文形式发送查询。这意味着您的设备与DNS解析器之间的网络路径上的任何人都可以看到包含所需主机名（或网站）的查询以及标识您设备的IP地址。
为了保护DNS免受旁观者和第三方的侵害，IETF通过HTTPS上的DNS（DoH）和TLS上的DNS（DoT）标准化了DNS加密。两种协议都可以防止查询在客户端与解析器之间被拦截，重定向或修改。在最新版本的Firefox，iOS等中实现的对DoT和DoH的客户端支持正在增长。即使这样，在Internet服务提供商之间进行更广泛的部署之前，Cloudflare还是提供公共DoH / DoT服务的少数几个提供商之一。这引起了两个主要问题。一个问题是DNS的集中化会引入单点故障（尽管在100多个国家/地区的数据中心中，Cloudflare始终可访问）。另一个问题是解析器仍然可以将所有查询链接到客户端IP地址。
Cloudflare致力于最终用户的隐私。我们的公共DNS解析器服务的用户受到严格的，经过审核的隐私政策的保护。但是，对于某些人来说，即使具有如此强大的隐私策略，使用敏感的查询信息来信任Cloudflare仍然是采用的障碍。不用依靠隐私策略和审核，如果我们可以为用户提供选择以技术保证删除该限制，该怎么办？
如今，Cloudflare和合作伙伴正在开始为一种协议提供支持，该协议可以实现以下功能：HTTPS上的遗忘DNS，或简称ODoH。
我们很高兴与几个同样致力于隐私的领先发射合作伙伴一起推出ODoH。
ODoH的关键组件是与目标解析器不相交的代理。今天，我们与几个领先的代理合作伙伴一起推出ODoH，其中包括：PCCW，SURF和Equinix。
“ ODoH是一种革命性的新概念，旨在保持用户的满意度。隐私是一切的中心。我们与Cloudflare的ODoH合作关系使我们在Internet的隐私和基础设施方面处于很好的位置。空间。可以通过Console Connect按需访问的基础PCCW Global网络具有增强的安全性和性能，现在，Cloudflare的1.1.1.1解析器提高了我们网络上代理的性能。该模型首次将客户端代理与解析器完全分离。随着世界向更偏远的模式转变，隐私变得更加关键，这种伙伴关系加强了我们对隐私的现有关注。” -PCCW Global数字自动化创新副总裁Michael Glynn
“我们正在与Cloudflare合作，以通过ODoH实现更好的用户隐私。迁移到ODoH是一个真正的范式转变，用户的隐私或IP地址不会暴露给任何提供商，从而带来真正的隐私。随着ODoH-pilot的推出，我们将加入Cloudflare网络的力量，以应对全球任何用户的挑战。迁移到ODoH不仅是一种范式转变，而且还强调了隐私对任何用户的重要性，尤其是在2020年期间。这与我们对隐私的核心关注和信念产生了共鸣。” — SURF技术产品经理Joost van Dijk
ODoH是IETF正在开发的新兴协议。 ODoH通过添加一层公共密钥加密以及客户端和DoH服务器（例如1.1.1.1）之间的网络代理来工作。这两个添加元素的组合确保只有用户才能同时访问DNS消息和他们自己的IP地址。
ODoH路径中有三个参与者。看上图，让我们从目标开始。目标通过代理解密客户端加密的查询。同样，目标对响应进行加密并将其返回给代理。该标准说，目标可能是解析器，也可能不是（我们稍后会对此进行介绍）。代理就像代理应该做的那样工作，因为它在客户端和目标之间转发消息。客户端的行为与在DNS和DoH中的行为相同，但是通过加密目标查询和解密目标响应来实现差异。选择这样做的任何客户端都可以指定代理和选择的目标。
代理无法查看DNS消息，无法识别，读取或修改客户端发送的查询或目标返回的答案。
只有预期的目标才能读取查询的内容并产生响应。
这三个保证在保持DNS查询的安全性和完整性的同时改善了客户端的隐私。但是，这些保证中的每一项都依赖于一个基本属性-代理和目标服务器不会相互影响。只要没有串通，攻击者只有在代理服务器和目标服务器都受到威胁时才能成功。
该系统值得强调的一个方面是，目标与执行DNS解析的上游递归解析器是分开的。实际上，对于性能，我们希望目标是相同的。实际上，1.1.1.1现在既是递归解析器又是目标！没有理由不需要将目标与任何解析程序分开存在。如果它们是分开的，则目标可以自由选择解析器，而只是充当中间人。请记住，唯一真正的要求是代理服务器和目标服务器永远不会合谋。
同样，重要的是，客户可以完全控制代理和目标选择。无需任何类似TRR的程序，客户端除了具有安全性外，还可以对其查询进行保密。由于目标仅了解代理，因此目标和任何上游解析程序都不会考虑任何客户端IP地址的存在。重要的是，这使客户可以更好地控制其查询及其使用方式。例如，客户可以出于任何原因随时选择和更改代理和目标！
在ODoH中，“ O”表示遗忘，此属性来自DNS消息本身的加密级别。这种增加的加密是客户端和目标之间的“端到端”，并且独立于TLS / HTTPS提供的连接级加密。有人可能会问为什么在存在代理的情况下根本需要这种附加加密。这是因为需要两个单独的TLS连接来支持代理功能。具体来说，代理会终止来自客户端的TLS连接，并启动到目标的另一个TLS连接。在这两个连接之间，DNS消息上下文否则将以纯文本形式显示！因此，ODoH还会在客户端和目标之间加密消息，因此代理无法访问消息内容。
整个过程从客户端使用HPKE加密其对目标的查询开始。客户端通过DNS获取目标的公钥，并将其捆绑到HTTPS资源记录中，并由DNSSEC保护。当此密钥的TTL过期时，客户会根据需要请求密钥的新副本（就像A / AAAA记录的TTL过期时一样）。使用目标的DNSSEC验证的公共密钥可确保只有目标目标可以解密查询并加密响应（答案）。
客户端通过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记录的加密及其解密。在第99个百分位数处，代理的DoH查询/响应与其ODoH对应项之间的额外开销始终小于1毫秒。
但是，ODoH请求-响应管道不仅限于加密。查看度量值的一种非常有用的方法是查看累积分布图-如果您熟悉这些类型的图，请跳至下一段。与大多数图表沿x轴开始的图相反，对于累积分布图，我们通常从y轴开始。
下图显示了通过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。另一方面，查看高于50％标记的曲线可以告诉我们½ODoH查询与DoH竞争。
这些曲线还隐藏了很多信息，因此深入研究测量值很重要。下表具有三个不同的累积分布曲线，这些曲线描述了我们通过代理和目标的延迟来选择ODoH的性能。这也是测量可以揭示的见解的一个例子，其中一些是违反直觉的。例如，从0.5之上看，这些曲线表明，无论选择代理和目标，ODOH查询/响应时间的½实际上是无法区分的。现在将注意力转移到0.5以下，并将两条实线与代表整体平均值的虚线相比较。该区域表明选择最低延迟代理和目标对平均值的改进很小，但最重要的是，它表明选择最低延迟代理会导致性能变差！
当然，还有待解决的问题。第一组测量主要在北美执行。绩效会在全球范围内发生变化吗？在实践中，这如何影响客户绩效？我们正在努力寻找答案，此版本将帮助我们做到这一点。
是的，是的！我们已经在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 @ ns1.cloudflare.com odoh.cloudflare-dns.com; ＆lt;＆lt;＆gt;＆gt; DiG 9.10.6＆lt;＆gt; -t type65 + dnssec @ ns1.cloudflare.com odoh.cloudflare-dns.com; （找到1个服务器）;;全局选项：+ cmd ;;得到了答案：;; -＆gt;＆gt; HEADER＆lt;--操作码：QUERY，状态：NOERROR，ID：19923 ;;标志：qr aa rd；查询：1，答案：2，权限：0，附加：1；警告：请求递归但不可用；选择伪指令： EDNS：版本：0，标志：做； udp：1232 ;;问题部分：; odoh.cloudflare-dns.com。 TYPE65 ;;解答部分：odoh.cloudflare-dns.com。 300 IN TYPE65 \＃108 00010000010003026832000400086810F8F96810F9F9000600202606 470000000000000000006810F8F92606470000000000000000000000006810 F9F98001002E002CFF02002800200001000100ED82DBE32CCDE189 BC6C643A80B5FAFF82548D21601C613408BAAAE-467B。 300个RRSIG类型65 13 3 300 20201119163629 20201117143629 34505 odoh.cloudflare-dns.com。 yny5 + ApxPSO6Q4aegv09ZnBmPiXxDEnX5Xv21TAchxbxt1VhqlHpb5Oc 8yQPNGXb0fb + NyibmHlvTXjphYjcPA ==;查询时间：21毫秒；服务器：173.245.58.100＃53（173.245.58.100）;;时间：2020年11月18日星期三07:36:29； MSG大小RCV：291
我们正在努力将ODoH添加到现有的存根解析器中，例如cloudflared。如果您有兴趣向客户端添加支持，或者您在实现中遇到错误，请在[电子邮件保护的位置]与我们联系！关于ODoH规范和服务器的公告将发送到IETF DPRIVE邮件列表。您可以在此处订阅和关注有关规范的公告和讨论。
我们致力于将其在IETF中向前推进，并且已经引起客户厂商的关注。 Firefox的CTO Eric Rescorla说，
遗忘的DoH是安全DNS生态系统的重要补充。我们很高兴看到它开始起飞，并期待在Firefox中进行试验。
我们希望有更多的运营商加入我们，并通过运行代理或目标为协议提供支持，我们希望随着可用基础架构的增加，客户支持也会增加。 ODoH协议是一种用于提高用户隐私的实用方法，旨在在不影响Internet上的性能和用户体验的情况下，提高加密DNS协议的整体采用率。 MarekVavruša和Anbang Wen在使1.1.1.1解析器支持ODoH方面发挥了作用。 Chris Wood和Peter Wu帮助准备并测试了ODoH库。 IDO的ODoH草案由Eric Kinnear，Patrick McManus，Tommy Pauly和Christopher Wood撰写。 ODoH本身从＆＃34; 遗忘的DNS：DNS查询的实用隐私，Schmitt等人的工作。 发表在PoPETs 2019中。 隐私周研究DNS DoH安全