加密 DNS：DoH 与 DoT

上一课把一次普通的 DNS 查询比作一张明信片：沿途经手的任何人都能读到它。有两项 IETF 标准，就是为了把这张明信片装进信封：基于 TLS 的 DNS（DoT，RFC 7858）和基于 HTTPS 的 DNS（DoH，RFC 8484）。二者加密的是同一种查询，主要区别在于它们承载查询的方式不同。

基于 TLS 的 DNS

RFC 7858 直接说明了它的目标：“TLS 提供的加密消除了窃听和路径上篡改 DNS 查询的机会”，以此应对“几乎所有 DNS 查询都是未加密发送的，这使得它们容易被攻击者窃听”这一现实。DoT 使用自己专属的端口 853，而不是通常的 53 端口。该 RFC 解释了原因：“建议不在 853 端口之外的 53 端口上使用基于 TLS 的 DNS，是为了避免在选择是否使用 TLS 时产生混淆，并降低降级攻击的风险。”

基于 HTTPS 的 DNS

RFC 8484 采取了不同的路线：“每一对 DNS 查询与应答都被映射为一次 HTTP 交换”，通过普通 HTTPS 流量所使用的同一个 443 端口传输。该 RFC 指出这带来了一个附带的好处：“HTTPS 默认使用的 443 端口，以及能够把 DoH 流量与同一连接上的其他 HTTPS 流量混合在一起，都能阻止不具备特权的路径中间设备干扰 DNS 操作”，因为当一次查询看起来和其他任何网页请求毫无区别时，就更难被单独挑出来加以屏蔽。

加密隐藏了什么，又依然没有隐藏什么

这两种标准都能阻止网络运营商或 Wi-Fi 窃听者在传输途中读取你的查询。但它们都不会对你发送查询的那个解析器隐藏这些查询。RFC 8484 明确指出，DoH 并不会改变服务器本身能看到什么：它指出“DNS 查询和应答的各种传输方式，本身就提供了可用于关联请求的数据”，而且客户端 IP 地址、Cookie 和 TLS 会话信息等普通网页机制意味着，在服务器端，“目前尚未发现 DoH 会引入超出 HTTPS 本身相关问题之外的新隐患”。RFC 7858 同样指出，DoT “并不解决 DNS 中的其他安全问题”，而且“即便消息已加密，处于有利位置的一方仍有可能通过分析消息的时间和大小来窥探出某些细节”。简而言之：加密 DNS 只是把“谁能看到你的查询”这一问题，转移回了你所选择的那个解析器运营者身上，并没有彻底消除可见性。

还有第二个值得了解的漏洞。仅仅加密 DNS 查询，本身并不能隐藏你接下来要连接的是哪个网站：紧随其后的 TLS 握手，通常会以明文形式包含主机名。正如 Cloudflare 对服务器名称指示（SNI）的解释：“SNI 会在 Client Hello 消息中包含主机名，而这正是 TLS 握手的第一步”——发生在加密建立之前。同一来源解释说，一项名为“加密 SNI”（ESNI）的扩展“在 SNI 扩展的基础上，对 Client Hello 中的 SNI 部分进行加密”，从而“阻止客户端与服务器之间的任何窥探者看到客户端请求的是哪张证书”。但隐藏 SNI 的支持依然取决于浏览器和网站双方是否都同意采用，目前还不是每一条连接的标准做法。

macOS 是如何支持它的

Apple 为 Mac、iPhone 和 iPad 记录了一项“DNS 设置”配置，正是用来做这件事的：它能让设备“通过基于 HTTPS 的 DNS 或基于 TLS 的 DNS，把设备的 DNS 查询路由到一台加密的 DNS 服务器”。它以配置描述文件的形式下发，可以通过“补充匹配域名”把加密解析器限定在特定域名范围内，也可以通过能匹配网络 SSID 等条件的“按需规则”，只在特定网络上生效。