DNS 是互联网的基石，但是 DNS 自发明以来一直处于未加密的状态，这为用户的隐私和安全带来风险。加密后的DNS将改善这些安全问题，本文主要讲解了两种 DNS 加密机制的原理，及加密 DNS 后带来的后续影响。
原文地址：https://blog.cloudflare.com/dns-encryption-explained/
原文标题：DNS Encryption Explained
原文作者：Peter Wu
原文写于：2019/10/29 GMT+8 下午9:00:00
译者：驱蚊器喵#ΦωΦ
翻译水平有限，有不通顺的语句，请见谅。
域名系统（Domain Name System, DNS）相当于 Internet 的通讯录。当您访问 cloudflare.com 或其他任何站点时，你的浏览器将会向 DNS 解析服务器询问可以找到该网站的 IP 地址。不幸的是，这些 DNS 查询和响应通常未受到保护。加密 DNS 将会提升用户隐私和安全性。在本文中，我们将研究两种用于加密 DNS 的机制，称为 通过 TLS 传输的 DNS（DNS over TLS,DoT）和 通过 HTTPS 传输的 DNS（DNS over HTTPS,DoH），并分别说明它们的工作原理。
应用程序通常使用 DNS，来将域名解析为 IP 地址。一般来说，编写应用程序的程序员不会明确地来完成这样的工作。取而代之，程序员编写类似于，fetch("https://example.com/news") 这样的代码，并寄希望于软件库能够将 “example.com“ 转换为 IP 地址。
在后台，软件程序中的组件库负责发现并连接到外部的递归 DNS 解析器，并使用 DNS 协议通信（参见下图），解析应用程序请求的域名。如何选择外部 DNS 解析器，以及是否提供任何隐私和安全性保护，都不在应用程序的控制范围之内。这些取决于使用的软件库，以及运行该软件的设备的操作系统提供的策略配置。
外部的 DNS 解析器
操作系统通常使用 动态主机配置协议 (Dynamic Host Configuration Protocol,DHCP) 从本地局域网中获取解析服务器的地址。在家庭网络和移动网络中，通常操作系统最终会使用 Internet 服务提供商(Internet Service Provider,ISP) 的 DNS 解析器。在公司网络中，所选的解析器通常由网络管理员控制。如果需要，用户可以修改设备的配置，使用指定的地址来覆盖默认的解析器，例如 Google 的 8.8.8.8 或 Cloudflare 的 1.1.1.1 这样的公共解析器，但是，大多数用户在连接至咖啡店或机场的公共 Wi-Fi 时不会重新设置 DNS 服务器的地址，而是使用默认的。
外部解析器的选择，直接影响最终用户的体验。大多数用户不更改他们解析服务器的设置，并且最终很可能会使用他们的网络运营商提供的 DNS 解析服务器。可以被明显观察到的两个指标是解析域名的速度和准确性。改善隐私或是安全，可能不会立即显示出来，但这将有助于防止其他人对你的浏览记录进行分析，或者干扰您的浏览活动。这在公共 Wi-Fi 网络上尤其重要，在这样的网络中，任何物理上接近的人都可以捕获和解密无线网络流量。
明文的 DNS
自 DNS 于 1987 年创建以来，它就一直处于明文裸奔（未加密）的状态。您的设备与解析服务器之间的每个人都可以监听，甚至修改您的 DNS 查询和响应。这包括您本地 Wi-Fi 网络中的任何人，您的网络运营商(Internet Service Provider,ISP)和传输提供商(transit providers)。这可能会影响您的隐私，比如您正在访问的域名将直接展现出来。
他们能看到什么呢？好吧，我们来做个实验，从连接到家庭网络的笔记本电脑来抓取网络数据包，如下图所示：
我们可以观察到以下几点：
- UDP 源端口为 53，这是标准的未加密 DNS 的端口号。因此，这个 UDP 数据包的有效数据可能是 DNS 响应。
- 这表明源 IP 地址 192.168.2.254 是 DNS 解析器的地址，而目标 IP 192.168.2.14 是发起 DNS 请求的客户端。
- UDP 数据包的有效数据，即 DNS 请求的域名，确实可以被解析，并且从 DNS 响应表明用户正在尝试访问 twitter.com。
- 如果后续有向 104.244.42.129 或 104.244.42.1 的连接，则很可能是访问” twitter.com”的流量。
- 如果后续有更多的和该 IP 的加密 HTTPS 通信，以及更多的 DNS 查询请求，则可能表明 Web 浏览器从该页面加载了其他资源。这可能会泄漏用户访问 twitter.com 时正在查看的页面。
由于 DNS 消息不受保护，因此可能会发生其他类型的攻击：
- DNS 查询可以被定向到开启了 DNS hijacking(劫持) 的解析器。例如，在英国，Virgin Media 和 BT(译者注：此 BT 似乎是一家运营商，而不是我们熟知的 BT 下载协议) 对不存在的域名返回虚假的响应，从而将用户重定向到一个搜索页面。这种重定向是可能发生的，因为计算机/电话盲目地信任由 ISP 的网关路由器使用 DHCP 提供的 DNS 解析器。
- 防火墙可以仅凭端口号进行拦截、阻止或修改任何未加密的 DNS 通信流量。值得注意的是，对明文的检查不是实现可见目标的高招(silver bullet)，因为 DNS 解析器可以被绕过。
加密的 DNS
加密的 DNS 会使偷窥者(snoopers)更难查看 DNS 消息，或是在传输过程中破坏它们。就像 web 从不加密的 HTTP 升级到加密的 HTTPS 一样，现在已经升级了对 DNS 本身进行加密的 DNS 协议。网络的加密，使隐私安全的通信与商业得以蓬勃发展。加密的 DNS 将进一步增强用户隐私。
目前有两种标准化的机制来保护您和解析服务器之间的 DNS 传输，也就是 通过 TLS 传输的 DNS 查询(2016) 和 通过 HTTPS 传输的 DNS 查询(2018)。这两者均基于安全传输层协议(Transport Layer Security,TLS)来加密，这个 TLS 协议也用于保护你与网站之间的 HTTPS 通信。在 TLS 中，服务器(Web 服务器或者是 DNS 解析服务器)使用证书对客户端(您的设备)进行身份验证。这样可以确保没有其他人可以伪造服务器(解析服务器)。
使用 TLS 传输的 DNS 查询(DNS over TLS,DoT)，原始 DNS 消息将直接嵌入安全的 TLS 信道中。从信道外看，既无法了解正在查询的域名，也无法对其进行修改。信道目标的客户端应用程序将能够解密 TLS，如下所示：
在对不加密 DNS 请求数据的跟踪中，我们可以很明显地看到，客户端直接发送了 DNS 请求，然后紧随其后的是解析服务器的 DNS 响应。但是，在加密的 DoT 情况下，在发送加密的 DNS 消息之前会交换一些 TLS 握手消息：
- 客户端发送一个
Client Hello，广播他支持的 TLS 功能。 - 服务器以
Server Hello响应，并协商将用于保护通信连接的 TLS 参数。证书(Certificate) 消息包含服务器的身份，而 证书验证(Certificate Verify) 消息将包含数字签名，客户端可以使用服务器证书对其进行验证。客户端通常会根据其本地信任的证书颁发机构(Certificate Authorities) 列表来检查此证书，但是 DoT 规范提到了 可替代的信任机制(alternative trust mechanisms)，例如公钥固定(public key pinning)。 - 一旦客户端和服务器都完成(Finished) TLS 握手后，终于它们可以开始交换加密的消息。
- 上面的图片包含一个 DNS 查询和响应，实际上，安全 TLS 连接将保持打开状态，并将重用于后续的 DNS 查询。
通过在新端口上加装 TLS 来保护未加密的协议，以下是之前已经这样实行的：
- 网络流量：HTTP (tcp/80) -> HTTPS (tcp/443)
- 发送电子邮件：SMTP (tcp/25) -> SMTPS (tcp/465)
- 接收电子邮件：IMAP (tcp/143) -> IMAPS (tcp/993)
- 现在：DNS (tcp/53 或者 udp/53) -> DoT (tcp/853)
引入新端口的带来的问题是，现有的防火墙可能会将其阻止。因为这些防火墙使用的可能是明确了启用某些服务的白名单方法，或者因为采用了网络管理员明确禁止服务的阻止方法。如果安全选项(DoT)与其不安全选项相比不太可能使用，则用户和应用程序可能会倾向于尝试回退到未加密的 DNS。然后，这就可能使攻击者迫使用户使用不安全的版本。
这种回退攻击并非只是理论。SSL stripping(剥离) 以前就用于将 HTTPS 网站降级为 HTTP，从而使攻击者能够窃取密码或劫持帐户。
另一种方法, 基于 HTTPS 的 DNS 查询(DNS Queries over HTTPS,DoH)，旨在 支持两个主要的用户需求：
- 防止沿路(on-path)的设备干扰 DNS 。这包括上面提到的，防火墙上通过端口屏蔽的问题。
- 使 Web 应用程序能够通过现有的浏览器 API 访问 DNS。
DoH 本质上是 HTTPS，这也是 Web 正使用的加密标准，并复用相同的端口号(tcp/443)。Web 浏览器已经弃用不安全的 HTTP，而是推荐使用 HTTPS。这使得 HTTPS 成为安全传输 DNS 消息的理想选择。在这里可以找到这类 DoH 请求的样例。
一些用户担心，使用 HTTPS 可能会削弱隐私，因为 cookie 可能会将用于跟踪的目的。DoH 协议设计者考虑了各方面的隐私问题，并明确建议为了防止跟踪，不要使用 HTTP cookie ，这一建议已得到广泛遵守。TLS 会话恢复(resumption)可提高 TLS 1.2 的握手性能，但可以潜在地用于关联 TLS 连接。幸运的是，TLS 1.3 可以通过默认情况下减少往返(round trips)次数来消除 TLS 会话恢复的需要，从而有效地解决了与之相关的隐私问题。
使用 HTTPS 意味着 HTTP 协议的改进也可以使 DoH 受益。例如，正在开发中的基于 QUIC 协议的 HTTP/3 协议可以在由于缺少行头阻塞而导致数据包丢失的情况下提供其他性能改进。这意味着当一个数据包丢失时，可以通过在安全通道并行发送多个 DNS 查询，而不会互相阻塞。
有关通过 QUIC 来发送 DNS (DNS/QUIC) 的草案也是存在的，这个草案与 DoT 相似，但是由于使用了 QUIC，因此没有行头阻塞问题。但是，HTTP/3 和 DNS/QUIC 都需要 UDP 端口才能访问。从理论上讲，两者都可以分别通过 HTTP/2 和 DoT 回退到 DoH。
DoT 和 DoH 的部署
由于 DoT 和 DoH 都相对新鲜，因此尚未广泛部署。在服务器端，包括 Cloudflare 的 1.1.1.1 和Google DNS 在内的主要公共解析器都支持它。但是，许多 ISP 提供的解析服务器仍然缺乏对此的支持。你可以在 DNS 服务器资源网 sources 上找到支持 DoH 的一小部分公共解析器名单，另一部分支持 DoT 和 DoH 的公共解析器的名单，可以在 DNS Privacy Public Resolvers 找到。
在用户终端设备上启用 DoT 或 DoH 有两种方法：
- 对应用程序添加支持，绕过操作系统的解析服务器服务。
- 对操作系统添加支持，为应用程序提供透明支持。
客户端上的 DoT 或 DoH 通常有三种配置模式：
- 关闭：不加密 DNS。
- 自动模式(Opportunistic mode)：尝试对 DNS 使用安全传输，但如果前者不可用，则退回到未加密的 DNS。此模式容易受到降级攻击的攻击，在降级攻击中，攻击者可以强制设备使用未加密的 DNS。这个模式的目的是在没有活跃的攻击者时为用户提供隐私保护。
- 严格模式(Strict mode)：尝试通过安全传输使用 DNS。如果不可用，则会停止尝试，并向用户显示错误。
目前，系统级别上，对 DNS 进行安全传输的配置如下：
- Android 9：通过自带的 “私有 DNS(Private DNS)”功能支持 DoT。模式：
- iOS 和 Android 用户还可以安装 1.1.1.1 app ，在严格模式下启用 DoH 或 DoT 支持。在程序内部，它使用 VPN 编程接口来对未加密 DNS 流量的拦截，然后再通过安全通道转发。
- Linux，从 systemd 239 版本开始的 systemd-resolved：可以通过 DNSOverTLS 选项开启 DoT。
- Linux，macOS 和 Windows 可以在严格模式下使用 DoH 客户端。
cloudflared proxy-dns命令在默认情况下使用 Cloudflare DNS 的解析服务器，但用户可以通过proxy-dns-upstream选项覆盖。
Web 浏览器支持 DoH ，但是不支持 DoT:
- Firefox 62 支持 DoH，并提供了几种 Trusted Recursive Resolver (TRR) 设置。默认情况下，DoH 是禁用的，但是 Mozilla 正在进行一项实验，为美国的某些用户启用 DoH。这项实验目前使用 Cloudflare 提供的 1.1.1.1 DNS 解析服务器，因为我们是目前唯一满足 Mozilla 要求的严格解析服务器策略(trict resolver policy)的提供商。由于许多 DNS 解析服务器仍不支持加密的 DNS 传输，因此 Mozilla 的方案将确保使用 DoH 保护更多用户。
- 当通过实验开启时，或是在 网络设置(Network Settings) 中启用”通过 HTTPS 传输DNS(Enable DNS over HTTPS)”选项，Firefox 将使用自动模式(network.trr.mode = 2 at about：config)。
- 严格模式，可以使用
network.trr.mode = 3来开启，但是需要指定一个明确的解析器 IP地址 (例如，network.trr.bootstrapAddress = 1.1.1.1)。 - 尽管 Firefox 会忽略系统中的默认解析服务器，但可以使用其他解析程序进行配置。此外，不支持 DoH 的解析器的企业部署环境有一个选项可以禁用 DoH。
- 如果系统默认的解析服务器地址，是 Chrome 程序中硬编码的 DoH 提供商之一(在这里查看源代码的变更)，Chrome 78 会启用 DoH 自动模式。除 Linux 和 iOS 之外，所有平台均开启了此项实验，并且默认情况下不包括企业部署环境。
- Opera 65 添加了一个选项，通过 Cloudflare 的 1.1.1.1 解析服务器来启用 DoH。默认情况下，此功能是关闭的。启用后，似乎是使用的自动模式：如果可以访问 1.1.1.1:443 (没有SNI)，则会使用。否则，它会退回到默认的解析器(不加密)。
curl 项目中的 DNS over HTTPS 页面的列表完整收集了 DoH 提供商和其他的实现方案。
作为对设备与外部DNS解析器之间的完整网络路径进行加密的一种替代方法，可以采取一个折中的方案：在设备与本地局域网的网关之间使用不加密的 DNS，但对网关路由器与外部设备之间的所有 DNS 流量进行加密。假设有一个安全的有线网络或是无线网络，这将保护本地局域网中的所有设备免受 ISP 偷窥，或是 Internet 上的其他攻击者的入侵。由于公共 Wi-Fi 热点被认为是不安全的，因此这种方法在开放的 Wi-Fi 网络并不安全。即使使用了 WPA2-PSK 对热点进行了密码保护，其他人仍然可以监听和修改未加密的 DNS 流量。
其他的安全注意事项
之前的部分介绍了安全的 DNS 传输，DoH 和 DoT。这些只会确保你的客户端从 DNS 解析服务器接收到的答案不会收到干扰。但是，它不能防止解析器返回给客户端的错误答案（通过 DNS 劫持或 DNS 缓存投毒攻击）。”正确的”响应，由域名的所有者，或者是权威的域名服务器的域来确定。DNSSEC 允许客户端验证返回的 DNS 答案的完整性，并捕获客户端与权威域名服务器之间的路径上没有任何未经授权的篡改。
但是，不正确转发 DNS 消息的中间服务器会阻碍 DNSSEC 的验证，即使 DNS 信息是可用的，应用程序使用的根解析器可能根本无法验证 DNS 查询结果。2016 年的一份报告表明 ，只有 26％ 的用户使用 DNSSEC 验证解析服务器。
DoH 和 DoT 保护客户端和公共解析器之间的传输。公共解析器可能必须与其他权威域名服务器联系才能解析域名。传统上，任何解析服务器和权威域名服务器之间的路径都使用不加密的 DNS。为了保护这些 DNS 消息，我们对 Facebook 进行了实验，在 1.1.1.1 和 Facebook 的权威域名服务器之间使用 DoT。虽然使用 TLS 设置安全通道会增加延迟，但延迟是分摊在很多查询请求内的。
传输加密可确保解析服务器的结果和元数据受到保护。例如，DNS 查询中包含的 EDNS 客户端子网(EDNS Client Subnet,ECS) 信息可能泄漏发送 DNS 查询的原始客户端 IP 地址。在消息沿路中隐藏这些信息可以提高隐私性。并且，这还可以防止由于转发 DNS 时的问题而导致损坏的中间服务器破坏 DNSSEC。
DNS 加密的操作带来的问题
DNS 加密可能给依赖监视或修改 DNS 流量的个人或团队带来挑战。安全设备依靠被动监控，监视计算机或网络边缘上的所有传入和传出的网络流量。例如，基于不加密的 DNS 查询，它们可以潜在地识别感染了恶意软件的计算机。如果 DNS 查询已加密，则被动监视解决方案将无法监视域名。
一些机构或团队希望 DNS 解析服务器因为以下目的而进行内容过滤：
- 阻止用于恶意软件分发的域名。
- 阻止广告。
- 执行家长控制过滤，阻止与成人内容相关的域名。
- 根据当地法规禁止访问提供非法内容的域名。
- 提供水平地域分割(split-horizon) DNS，根据请求来源所处的网络提供不同的响应答案。
通过 DNS 解析服务器来阻止对域名访问的一个优点是，可以中心化处理，而无需在每个单独的应用程序中重新实现。不幸的是，这种执行方式的粒度也很粗糙。假设网站在 example.com/videos/for-kids/ (为儿童提供的内容) 和 example.com/videos/for-adults/ (为成人提供的内容) 上为多类用户提供内容服务。DNS 解析服务器只能看到主域名是 example.com，并且可以选择阻止或是放行。在这种情况下，特定应用程序的插件(例如浏览器扩展)会更有效，因为它们可以查看到实际的 URL ，并有选择性地阻止内容被访问。
DNS 监控覆盖并不全面。恶意软件可能会绕过 DNS ，并且在程序中硬编码 IP 地址，或使用其他方法来查询 IP 地址。但是，并非所有的恶意软件都这么复杂，因此 DNS 监视仍可以充当深度防御(defence-in-depth)工具。
所有这些非被动式的监视，或是 DNS 阻止用例都需要 DNS 解析服务器的支持。依赖于当前解析服务器的自动 DoH/DoT 升级的部署，将保持与往常通过未加密 DNS 提供的功能相同。不幸的是，如前所述，这很容易降级。为了解决这个问题，系统管理员可以将 endpoints 指向严格模式下的 DoH/DoT 解析服务器。理想情况下，这是通过安全的设备管理解决方案(比如，MDM, 组策略等等) 来完成的。
结论
使用 DNS 将域名映射到 IP 地址是互联网的基础之一。DNS 传统上使用不安全，未加密的传输。过去，这已被 ISP 滥用用于注入广告，同时也导致了隐私泄漏。咖啡店里的管家访客可以根据未加密的 DNS 来跟踪您的活动。通过使用在 TLS 上传输 DNS(DNS over HTTPS,DoH)或 在 HTTPS 上传输 DNS(DNS over HTTPS,DoH)可以解决所有这些问题。这些保护用户的技术相对新型，并且正在被越来越多的采用。
从技术角度来看，DoH 与 HTTPS 非常相似，并且遵循行业的普遍趋势，弃用不安全的选项。与 DoH 相比，DoT 是一种比 DoH 更简单的传输模式，因为除去了 HTTP 层，但这也使得故意或偶然地阻止它变得容易。
选择安全的 DNS 解析服务器是启用安全传输的第二要务。一些供应商使用本地配置的 DNS 解析器，但会尝试将未加密的传输升级为更安全的传输（DoT 或 DoH)。不幸的是，DNS 解析器通常是 ISP 提供的默认解析器，这可能不支持安全传输。
Mozilla 采用了不同的方法。它们允许用户显式选择解析器，而不是依赖可能不支持 DoH 的本地解析器。Mozilla 推荐的解析器必须满足高标准，以便保护用户隐私。为了确保基于 DNS 的父母控制功能仍然有效，并支持水平分割的用法，Mozilla 添加了一种机制，该机制允许私有解析器禁用 DoH。
DoT 和 DoH 传输协议已为我们准备好转移到更安全的 Internet。从前面的数据包跟踪中可以看出，这些协议和确保应用程序流量安全的现有机制相似。一旦想要关闭安全和隐私的孔洞，会有 很多 很多问题需要解决。
