[译] DNS over TLS：端到端加密的 DNS

• 原文地址：DNS over TLS: Encrypting DNS end-to-end
• 原文做者：code.fb.com
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：lsvih
• 校对者：Qiuk17

为了加密互联网流量中未被加密的最后一部分，咱们与 Cloudflare DNS 合做进行了一个试点项目。这个试点项目利用安全传输层协议（即 TLS，一种被普遍应用的、通过时间证实的机制，可用于双方在不安全信道上创建通信时，为通信提供身份认证及加密）与 DNS 进行结合。这个 DNS over TLS（DoT）方案可以加密并验证 Web 流量的最后一部分。在 DoT 测试中，人们能够在浏览 Facebook 时使用 Cloudflare DNS 享受彻底加密的体验：不只是在链接 Facebook 时用的 HTTPS 时进行了加密，并且在 DNS 级别，从用户计算机到 Cloudflare DNS、从 Cloudflare DNS 到 Facebook 域名服务器（NAMESERVER）中全程都采用了加密技术。

DNS 的历史

二十世纪八十年代末，域名系统（DNS）被提出，可让人们用简短易记的名称来链接实体（好比 facebook.com），这使得网络安全发生了极大的变化。人们为网络安全作了许多的改进，好比如今大部分的网络流量都是经过 HTTPS 链接，但在线上传输明文时仍然存在一些问题。

2010 年，DNS 安全拓展（DNSSEC）部署实施，DNS 协议由此支持身份验证功能。虽然 DNSSEC 支持对消息进行身份验证，但仍然会使用明文来传输 DNS 请求与应答。这也使得传输的内容能够被请求方与响应方中间路径上任意节点轻松获取。2014 年 10 月，国际互联网工程任务组（IETF）创建了 DPRIVE 工做组，其章程包括为 DNS 提供保密性与身份验证功能。

此工做组在于 2016 年提出 RFC 7858 指定了 DoT 标准。为此，Cloudflare 的 1.1.1.1 与 Quad9 的 9.9.9.9 等开放的解析器在 DoT 的支持下更加关注使用者的隐私。这也保护了终端用户设备到 DNS 解析器这一部分 DNS 通讯。但链接的其它部分仍然是明文传输。在 2018 年 5 月，DPRIVE 从新开发了一个方法，用于加密从解析器到域名服务器间的通讯。

DoT 之前的 DNS

DoT 试验

咱们在过去的几个月中一直在进行一项试验，在 Cloudflare 1.1.1.1 递归解析器与咱们的主域名服务器间开启 DoT。这个试验的目的是了解大规模使用 DoT 的可行性，收集信息以更好地了解 DoT 在接受应答时的延迟产生的开销，并肯定计算开销。这个试验让咱们更好地了解了 DoT 协议在真实环境下的表现。另外在生产环境负载中试验把 DNS 从 UDP 等即发即弃方法换成 TLS 之类的加密链接协议，能够将一些设计协议时发现不了的问题给暴露出来。

DoT 下的 DNS

截至目前，经过观察 Cloudflare DNS 与 Facebook 域名服务器间的生产环境流量，已经能够证实该试验是可行的解决方案。在初始化一个新链接的时候因为须要初始化请求，所以增长了延时；但咱们能够重用 TLS 链接来处理其它更多的请求。所以，初始化增长的负载在均摊以后，下降到了 Cloudflare DNS 与 Facebook 主域名服务器 UDP 基线的 p99 相同的程度。

下图展现了咱们从 TLS 切换回 UDP 时（在 17:30 时刻）延时的变化。它可让咱们比较两个协议请求的延时。第一个图显示了在没有 TCP/TLS 会话创建开销状况下的延时百分比。它展现了当链接创建后，TLS 与 UDP 在查询和响应间的延时是相同的。

第二张图加上了创建链接的时间来考虑请求的整体延迟。从图中能够看到，使用 TLS 仍是 UDP 对链接的整体延时也没有影响。这是由于咱们使用 TLS 的会话恢复技术，经过相同的 TLS 链接来执行多个请求，实质上分摊了初始化链接的开销。

做为参考，下图展现了在不使用 TLS 会话恢复技术，并在创建链接后仅处理少许请求时总延时的差别。在比 22:35 稍早的时刻完成了 TLS 到 UDP 的切换，能够看到整体而言 TLS 对大多数的请求的影响与 UDP 相似，但在 p95 或更高的统计指标下，请求的延时收到了影响。后面一张图显示，当连接已经创建时，延时不受影响。这两张图代表，第一张图中的差别是因为创建新链接时产生的，而且实际上，创建新链接的频率很高。

基原本说，浏览 Facebook 和使用带 DoT 的 Cloudflare DNS 的用户，不管是在用 HTTPS 链接时仍是在 DNS 层面上，均可以享受彻底加密的体验。虽然咱们已经实现了 TLS 会话恢复技术，但尚未充分利用现代协议栈提供的所有优化方法。在未来，咱们能够利用 TLS 的最新版本（TLS 1.3）和 TCP Fast Open 等技术带来的改进，进一步下降延时。

DoT 的下一步

这个试验已经证实了，咱们可使用 DoT 大规模处理生产环境的负荷，而且不会对用户体验产生任何负面影响。咱们将这个试验所获得的经验和知识，做为一种可行的经验回馈给 DNS 社区。

IETF 等标准社区开发协议时，有时候会缺少与最终实施与运行协议的组织的意见，这致使了协议设计者、实施者、运营者间的脱节。经过这个试验，咱们能够根据在生产环境中运行协议获得的经验，及时向工做组报告具体结果，同时也为有意于部署 DoT 的运营商和软件供应商提供了最佳实践。

咱们但愿这些初步的试验结果能够激励其它的行业合做伙伴加入咱们的试验，扩大 DoT 运营商的数量，并获得更多制定此协议时获得的经验，从而提升反馈水准、获得更多的运营知识和最佳实践。

感谢 Cloudflare 的 Marek Vavruša 在这个试验中作出的贡献。

若是发现译文存在错误或其余须要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。