引言：明文 DNS 时代的终结

DNS (Domain Name System) 作为互联网的基石，长期以来一直以极度不安全的 UDP 明文（端口 53）形式运作。当你试图访问 www.example.com 时，你的设备会向本地 ISP (互联网服务提供商) 的 DNS 服务器发送查询。因为是明文，这个过程中沿途的任何节点（ISP、中间人攻击者、防火墙设备）都能轻易知道你在访问什么网站，甚至可以恶意篡改响应，把你重定向到钓鱼网站，这就是所谓的 DNS 劫持 与 DNS 污染。

为了挽救这一隐私灾难，业界推出了两大加密 DNS 标准：DoT (DNS over TLS, RFC 7858) 与 DoH (DNS over HTTPS, RFC 8484)。虽然它们的目的都是为了加密 DNS 流量，但它们在架构设计、隐蔽性以及与防火墙对抗的维度上，却有着本质的分歧。

本文将深度解析 DoH 与 DoT 的底层技术差异，以及它们如何与 ESNI/ECH 技术协同，真正补全互联网隐私保护的最后一块拼图。

协议底层解析：DoT vs DoH

DoT (DNS over TLS)：专一且纯粹

DoT 的设计哲学非常直接：既然传统的明文 DNS 不安全，那就给它套上一层 TLS (Transport Layer Security) 加密壳。

工作机制：DoT 使用专用的 TCP 端口 853 进行通信。客户端首先与 DNS 服务器在 853 端口上进行 TLS 握手，建立安全的加密通道，随后在通道内部以传统的 DNS 报文格式发送查询。
性能优势：由于省去了应用层 HTTP 的封装开销，DoT 的网络栈更薄，解析延迟相对较低，对于需要处理海量并发请求的底层系统（如 Android 系统内置的 Private DNS）而言非常高效。
致命弱点 - 端口特征明显：这是 DoT 最大的短板。因为它使用了专用的 853 端口，网络管理员或防火墙设备只要在路由器上设置一条规则：DROP TCP PORT 853，就可以一刀切地封杀所有 DoT 流量。对于审查极其严格的网络环境而言，DoT 几乎没有生存空间。

DoH (DNS over HTTPS)：极致的伪装者

DoH 的设计哲学则带有明显的对抗色彩：把 DNS 流量伪装成正常的 Web 浏览流量。

工作机制：DoH 将 DNS 查询打包成普通的 HTTP 请求（通常是 HTTP/2 甚至 HTTP/3），通过 443 端口发送给 DNS 解析器。
完美隐蔽：因为 DoH 复用了标准的 HTTPS 443 端口，从外部旁路监听者的视角来看，你与 DNS 服务器的通信，和你在浏览普通的 HTTPS 网页没有任何区别。
反封锁特性：防火墙如果想要封杀 DoH，就面临一个两难困境：如果封杀 443 端口，那么整个现代互联网的 Web 服务都会瘫痪。因此，审查者只能尝试通过封锁已知 DoH 服务器的 IP 来阻止访问（例如屏蔽 8.8.8.8 或 1.1.1.1），但如果 DoH 服务器与大型 CDN (如 Cloudflare) 绑定，这种 IP 封锁往往会带来巨大的附带损伤 (Collateral Damage)。

+-----------------------+      +-------------------------+
|     传统 DNS (53)     |      |       DoT (853)         |
+-----------------------+      +-------------------------+
| 明文 DNS Payload      |      | 密文 DNS Payload        |
| UDP/TCP 封装          |      | TLS 层加密              |
| 任何人可读/可篡改     |      | TCP 封装 (端口专一易封) |
+-----------------------+      +-------------------------+
             |                              |
             v                              v
+--------------------------------------------------------+
|                     DoH (443)                          |
+--------------------------------------------------------+
| Base64 编码的 DNS 查询 (通过 GET/POST 传输)            |
| HTTP/2 或 HTTP/3 协议层封装                            |
| TLS 层加密                                             |
| 混淆在海量正常 Web 流量中，防火墙极难精准过滤          |
+--------------------------------------------------------+

技术生态站队：谁主沉浮？

有趣的是，互联网巨头们对这两种技术有着不同的偏好，这实际上反映了不同产品生态的利益考量。

操作系统的偏爱 (Android/iOS/Linux)：通常偏向于 DoT。操作系统层面需要为所有后台应用提供统一的、低延迟的 DNS 解析接口。DoT 协议轻量级，非常适合在内核或系统守护进程中运行。
浏览器的偏爱 (Chrome/Firefox/Edge)：坚定拥护 DoH。浏览器本就拥有极其强大的 HTTP 栈，实现 DoH 顺理成章。更重要的是，通过 DoH，浏览器可以越过操作系统，自己接管 DNS 解析。这不仅能防止被 ISP 劫持，也打破了本地恶意软件（或企业防火墙）对 DNS 的监控。

仅有 DoH 就足够安全了吗？—— ESNI/ECH 的协同进化

很多人认为，只要浏览器开启了 DoH，ISP 就绝对无法知道我在访问什么网站。这其实是一个常见的致命误区。

当你通过 DoH 安全地解析出 www.pornhub.com 的 IP 地址后，你接下来需要与该服务器建立 HTTPS 连接。而在传统的 TLS 1.2/1.3 握手中，有一个叫做 SNI (Server Name Indication，服务器名称指示) 的字段，它是明文传输的。

SNI 泄漏原理：因为一台服务器（同一个 IP）可能托管着成百上千个不同的网站，客户端必须在 TLS 握手的第一阶段告诉服务器：“我要访问的是 www.pornhub.com 的证书，请出示给我”。这个明文的 SNI 字段，就像黑夜中的灯塔，直接把你的意图暴露给了防火墙。防火墙通过嗅探 SNI，依然可以直接进行 RST 阻断。

破局之道：Encrypted Client Hello (ECH) 曾经被称为 ESNI (Encrypted SNI)，现已进化为更完善的标准 ECH。要实现完全的网络隐身，DoH 与 ECH 必须协同作战。

浏览器首先通过 DoH 安全地查询目标域名的 DNS 记录。
在 DNS 响应中，不仅返回 IP 地址，还会返回目标服务器的 ECH 公钥（以特定的 DNS 资源记录形式，如 HTTPS 记录）。
浏览器拿到这个公钥后，在发起 TLS 握手时，使用该公钥将 SNI 字段加密。
防火墙截获到流量，只能看到一堆乱码，既不知道你在向谁发起解析（DoH 的功劳），也不知道你要请求哪个证书（ECH 的功劳）。

总结：未来的隐私网络架构

DoT 是一位穿着制服的保安，安全但显眼，适合在企业内部或系统底层构建信任边界。而 DoH 则是混在人群中的特工，它复用 HTTP 基础设施，抗审查能力极强，是目前 C 端用户保护隐私的首选。

但我们必须清醒地认识到：隐私保护是一个系统工程。仅仅加密 DNS 是不够的。只有当 DoH (隐藏查询) + ECH (隐藏握手) + TLS 1.3 (隐藏通信内容) 组成三位一体的防护矩阵时，互联网才能真正迎来属于用户的暗网时代。在这一天到来之前，防火墙与加密协议之间的军备竞赛，仍将激烈地持续下去。