PROTOCOLS

协议详解

先看一张规格表把「是什么、谁定的、跑在哪个端口」对齐，再逐个说清它们的取舍。最后是 ODoH —— 它换了个思路解决问题。

先把事实对齐

端口、规范编号、标准化状态。这几项最容易在转述中走样。

名称 承载 默认端口 规范 状态
明文 DNS UDP（大响应与区域传送走 TCP） 53/udp、53/tcp RFC 1035 标准
DoT DNS 直接跑在 TLS 上 853/tcp RFC 7858 标准
DoH DNS 作为 HTTP 消息（通常 HTTP/2） 443/tcp（HTTPS 默认端口） RFC 8484 标准
DoH3 同上，但换成 HTTP/3 443/udp RFC 8484 + RFC 9114 标准
DoQ DNS 直接跑在 QUIC 上（不经 HTTP） 853/udp（可协商改用 443） RFC 9250 标准
ODoH DoH + 一个中继（代理看不到内容、解析器看不到 IP） 同 DoH RFC 9230 实验性
DNSCrypt 自定义加密，非 IETF 体系 自定义（常见 443、5443） 社区规范（非 RFC） 非标准

三处最常见的记错： （1）DoH3 没有独立的 RFC —— 它就是 DoH 跑在 HTTP/3 上； （2）DoQ 与 DoT 共用 853，区别是 DoQ 走 /udp； （3）DoH 并不规定端口，443 只是 HTTPS 的默认端口，部署方可以自选。

汇总：各自的优势、代价与适用场景

上表是事实，这张是取舍。两者要一起看 —— 单看事实无法选型，单看取舍容易记错细节。

协议 主要优势 主要代价 典型适用场景
DoT 853 端口专用于 DoT，设备可明确识别，便于纳入统一策略与审计。 端口特征明显，容易被针对性阻断；首次连接多一次往返。 企业内网、可控出口环境、强调审计与变更管理。
DoH 复用 HTTPS 生态，与普通网页流量混合，旁路设备难以单独拦截。 网络管理方也失去可观测性；HTTP 层是额外开销。 终端用户、移动网络、需要高可达性的跨网络访问。
DoH3 与 DoH 同等可达性，但底层是 QUIC：少一次握手往返，丢包不互相阻塞。 UDP 443 在少数网络被整段封禁，需要回落机制。 移动网络、弱网或需要频繁新建连接的场景。
DoQ 不经 HTTP，结构最简；每查询一条独立流，并发能力优于 DoT。 支持矩阵仍在补齐；与 DoT 共用 853 但走 udp，防火墙易漏配。 对首次连接延迟敏感的弱网；递归到权威解析。
ODoH 引入中继，使任何一方都无法同时知道「你是谁」和「你在查什么」。 实验性规范；多一跳延迟；需信任中继与解析器不串通。 隐私要求高于延迟要求的场景。
DNSCrypt 除链路加密外带解析器身份认证，实现灵活。 非 IETF 规范，跨厂商一致性弱；自选端口反而成为特征。 已有 DNSCrypt 存量资产、需要平滑延续的环境。

注意「主要优势」与「主要代价」两列常常是同一件事的两面： DoH 的可达性正来自「与普通流量无法区分」，而这同时意味着治理方也看不清； DoT 的可治理性正来自端口专一，而这同时意味着它容易被单独阻断。 这一点在做取舍时比记住任何单条优缺点都重要。

差别只是「套了几层」

选择协议后，逐层剥开看里面还剩什么 —— 每剥掉一层，链路上的观察者就多看到一点。

DNS 查询 example.com
TLS :853/tcp
DNS 查询 example.com
HTTPS :443/tcp
HTTP/2
DNS 查询 example.com
HTTPS :443/udp
HTTP/3（跑在 QUIC 上）
DNS 查询 example.com
QUIC :853/udp
DNS 查询 example.com

    明文 DNS 没有任何外层 —— 中间任何一跳都能直接读到「你在查 example.com」，也能改写返回的地址。

    DoH443/tcp

    把 DNS 查询包装成一个 HTTPS 请求。这是它全部的设计，也是它全部争议的来源。

    它换来了什么

    • 复用整个 HTTPS 生态：证书体系、连接复用、压缩、缓存、重定向都能直接用。
    • 与普通网页流量混在同一条连接上，旁路设备很难「只拦 DNS」而不影响正常访问。
    • 浏览器原生支持最成熟，终端用户配置成本最低。

    它付出了什么

    • HTTP 语义叠在 DNS 之上是额外开销 —— 这正是 DoQ 想省掉的部分。
    • 网络管理方也看不清了：企业失去了对 DNS 的可观测性，审计要从别处补。
    • 常与「绕过管控」划等号，在部分网络里会被整体阻断。

    DoT853/tcp

    DNS 直接跑在 TLS 上，中间不加 HTTP 这一层。

    它换来了什么

    • 协议边界清晰：853 是专门留给「DNS over TLS/DTLS」的端口，设备能明确识别并施加策略。
    • 因此它是可治理的 —— 企业能既加密又保留审计能力，这两个目标不必对立。
    • 实现比 DoH 简单，排障工具链成熟。

    它付出了什么

    • 端口特征明显，「你在用加密 DNS」这件事藏不住，容易被针对性阻断。
    • 首次连接要付 TCP + TLS 两次握手，比 QUIC 多一个往返。
    • 在开放网络上可达性不如 DoH。

    DoH3443/udp

    DoH 跑在 HTTP/3 上。不是新协议，是同一个协议换了传输层 —— 但收益不小。

    为什么值得单列

    • QUIC 把传输握手与 TLS 握手合并成一次往返，首次连接少一个 RTT。
    • 每条查询走独立流，丢包不会互相阻塞 —— 这是 HTTP/2 over TCP 解决不了的问题。
    • 连接 ID 让连接能在网络切换时存活（笔记本从 Wi-Fi 换到手机热点不断）。
    • 仍然是 443，旁路设备看到的与普通 HTTP/3 流量无法区分。

    注意事项

    • UDP 443 在少数网络里被一律封禁，需要回落机制。
    • 排障需要能解析 QUIC，工具链比 TCP 侧薄。
    • 0-RTT 恢复能再省一次往返，但存在重放风险，服务端策略不一。

    DoQ853/udp

    DNS 直接跑在 QUIC 上，不经 HTTP。结构上最接近「把 DoT 的 TCP 换成 QUIC」。

    设计上的取舍

    • 省掉 HTTP 那一层的开销，且不受 HTTP 队头阻塞影响。
    • 每次查询用一条独立的 QUIC 流，DNS 消息 ID 建议固定为 0 —— 因为流的编号已经承担了区分作用。
    • 连接可承载的并发查询数远多于 DoT（不受 TCP 消息长度限制）。
    • 规范也承认：在客户端到递归解析器这一段，把端口协商成 443 往往更实用，因为 443 上的 QUIC/HTTP-3 流量太多，不容易被单独阻断。

    注意事项

    • 虽已标准化，但客户端与解析器的支持矩阵仍在补齐，落地前要逐项确认。
    • 与 DoT 共用 853，但一个 udp 一个 tcp —— 防火墙规则容易只放行其一。
    • RFC 9250 也明确它适用于递归到权威这一段（这类场景很少有中间代理，省掉 HTTP 更划算）。

    DNSCrypt自定义端口

    比 DoT/DoH 更早的加密方案，不在 IETF 体系内，但在隐私社区有长期实践。

    它确实做到的事

    • 链路加密之外，还带解析器身份认证 —— 客户端按公钥确认对方是不是真的那个解析器。
    • 实现灵活，端口可自选，早期就支持密钥轮换。

    为什么不是首选

    • 非 IETF 规范，跨厂商一致性弱，新客户端支持有限。
    • 自选端口反而成了特征：在严格网络里容易被当成异常流量。
    • 若已有存量资产可继续用，但新部署建议优先考虑标准协议。

    ODoH实验性 · RFC 9230

    前面五个都在解决「链路上被看到」，ODoH 解决的是另一个问题：解析器本身看得到你的全部查询。

    加密 DNS 的共同盲点：无论用哪个协议，你最终都要把明文查询交给某一个解析器 —— 于是你只是把「链路上任意节点能看到」收敛成了「你选的那一个解析器能看到」。 对隐私要求更高的场景，这个「可信第三方」本身就是问题。
    第 1 跳 你的设备 把查询加密给解析器
    中继 代理 知道你的 IP
    读不到内容
    第 2 跳 解析器 读到内容
    不知道你的 IP

    关键在于没有任何一方同时掌握「你是谁」和「你在查什么」。 代理看得到 IP 但没有解密密钥；解析器能解出查询，但发起方在它看来是中继。 代价是多一跳延迟，且需要你信任中继与解析器不串通。

    首次查询要付几次往返

    这是 DoQ / DoH3 存在的真正理由。越少越好，但只在首次连接时才有差别。

    明文 DNS
    查询 1 次往返，无连接建立
    DoT
    TCP 握手 TLS 1.3 查询 3 次
    DoH (HTTP/2)
    TCP 握手 TLS 1.3 查询 3 次
    DoH3
    QUIC 握手
    （含 TLS）     查询 2 次
    DoQ
    QUIC 握手
    （含 TLS）     查询 2 次
    时间 →
    QUIC 把传输握手与加密握手合并，省掉的正是 DoT / DoH 那一次 TCP 往返。 另有两点容易被忽略：（1）这只影响首次连接 —— 连接建立之后所有协议都是 1 次往返； （2）QUIC 的另一处好处在丢包时 —— 每条查询走独立流，丢包不会让后面的查询一起卡住 （DoH over HTTP/2 走 TCP，会遇到队头阻塞）； 此外（3）若启用 0-RTT 恢复，QUIC 系与 TLS 1.3 都能在复用连接时省到接近 0 次， 但 0-RTT 数据存在重放风险，服务端不一定会接受。

    数据来源：TLS 1.3 的 1-RTT 握手（RFC 8446）、QUIC 的 1-RTT/0-RTT（RFC 9000、RFC 9001）， 以及针对 DoQ 与 DoH 往返次数的实测研究 （A. Custura 等，On Cross-Layer Interactions of QUIC, Encrypted DNS and HTTP/3，IEEE TNSM 2024）。

    怎么选：先定约束，再选协议

    顺序很重要 —— 反过来做，往往会选到一个在目标网络里根本用不了的东西。

    1. 网络能不能通

    • 出口若封 UDP 443，DoH3 会被迫回落。
    • 若封 853，DoT 与 DoQ 同时不可用。
    • 先测可达性，再谈其余 —— 这是最常见的返工原因。

    2. 需不需要自己看得见

    • 需要审计与故障定位 → DoT（端口明确、可治理）。
    • 不需要、且优先考虑可达性 → DoH / DoH3。

    3. 首次连接的延迟在意吗

    • 频繁新建连接或弱网 → DoQ / DoH3 的少一次往返与抗丢包有实际价值。
    • 长连接复用良好 → 这一项几乎没有差别。

    4. 连「解析器信任」也要减少吗

    • 是 → 评估 ODoH。注意它是实验性规范，且要多信任一个中继。
    • 否 → 把精力放在挑选可信解析器与其日志政策上，收益更大。

    深入阅读

    本页给结论，下面提供决策过程与可复用模板。

    协议选型手册

    四步收窄流程、可复用的评分标准，以及两个结论相反的完整算例。

    阅读全文