三大协议机制与隐私增强架构

01 · DoT深度解析（RFC 7858）

1.1 机制与封装

DoT在TCP之上运行TLS，默认端口853（IANA注册服务名“dns-tls”）。DNS报文以标准wire format传输，每条报文前附加2字节大端长度前缀（与TCP 53上的DNS over TCP封装完全一致，仅传输层由明文TCP替换为TLS）。这一设计使DoT可以复用现有DNS软件栈的报文编解码逻辑，改动面最小。

握手流程：TCP三次握手 → TLS 1.3握手（1-RTT，支持会话票证恢复实现0.5-RTT效果）→ 证书验证 → 加密DNS传输。TLS 1.3（RFC 8446）的会话恢复机制使重复连接可避免完整证书交换，但首个查询的“冷启动”延迟仍显著高于明文UDP（后者无连接建立开销）。

1.2 认证模式：严格模式与机会模式（RFC 8310）

RFC 8310定义了两种使用profile，这是工程部署中最关键的决策点：

1.3 认证方式

• 主机名验证（默认推荐）：解析器证书中的SAN/CN匹配预设域名（如 dns.example.com），依赖PKI信任链。
• SPKI Pinning：将解析器公钥的SHA-256指纹硬编码到客户端配置，不依赖CA体系，可防 rogue CA 签发，但证书轮换需同步更新pin。

1.4 已知局限

• TCP队头阻塞：单连接上丢失一个TCP段会阻塞其后的所有DNS应答，高丢包链路（移动网络）上性能劣于UDP方案。
• 专用端口的双刃剑：853端口可识别性极强——利于企业策略管控（可精确放行/阻断），但也意味着加密DNS流量可被任何中间方一眼识别并定向阻断。
• 连接复用：依赖edns-tcp-keepalive（RFC 7828）选项协商空闲连接保持时长，实现长连接复用。

02 · DoH深度解析（RFC 8484）

2.1 机制与封装

DoH将DNS查询封装为HTTP请求：POST方法携带application/dns-message媒体类型的二进制DNS报文，或GET方法将DNS报文base64url编码后以dns=参数传递（便于HTTP缓存与CDN处理）。响应同样为application/dns-message，HTTP状态码语义化映射DNS层错误。

POST /dns-query HTTP/1.1
Host: cloudflare-dns.com
Content-Type: application/dns-message
Accept: application/dns-message
Content-Length: <DNS报文字节数>

<标准DNS wire format查询报文>

2.2 与Web生态深度融合的架构后果

• 同端口同协议栈：DoH跑在443端口，使用与正常网页浏览完全一致的TLS+HTTP栈。其直接后果是：中间方无法简单通过端口区分“DNS查询”与“浏览网页”——隐私收益最大化，但企业网络的可观测性与策略管控被严重削弱（这正是第4、6页深入展开的核心矛盾）。
• CDN化部署：DoH天然可被CDN承载（任意边缘节点均可代理DoH请求），这使公共递归获得了与Web内容分发同级的全球分布式能力，也是云厂商在DoH上投入远超DoT的根本原因。
• HTTP缓存双刃剑：中间缓存可能缓存DoH应答（提高性能），也可能导致陈旧数据被复用——RFC 8484允许服务端通过Cache-Control精确控制。
• 队头阻塞缓解路径：HTTP/2 over TCP仍存在TCP层队头阻塞；迁移至HTTP/3（QUIC）后缓解，即“DoH3”。

2.3 性能特征

单次冷查询：TCP+TLS握手+HTTP请求，RTT开销大于DoT（HTTP层附加开销）；但在连接复用后（浏览器持续向同一DoH端点发送大量查询），摊销成本极低，实测性能与明文DNS相当甚至更优（复用消除了逐查询的UDP丢包重试开销）。

03 · DoQ深度解析（RFC 9250）

3.1 机制与设计约束

DoQ在QUIC v1（RFC 9000）之上承载DNS，默认端口UDP 853（IANA注册“dns-quic”）。协议设计遵循三项关键约束：

• 一条QUIC流对应一个DNS查询：每个查询在独立STREAM帧中传输，彻底消除应用层与传输层的队头阻塞——某查询丢失重传不影响其他查询。
• 一个UDP数据报只承载一个DNS查询：避免分片重组的延迟与放大攻击面。
• 不承载HTTP语义：DoQ直接在QUIC STREAM帧中传输DNS报文，不使用HTTP/3，因此不涉及HPACK/QPACK头部压缩——RFC 9250 §4.2.1明确禁止在DoQ中使用QPACK。

3.2 0-RTT与连接迁移

QUIC的0-RTT机制允许客户端在复用先前会话密钥时，于首个数据报中携带加密DNS查询——冷查询延迟从DoT的2-RTT以上（TCP握手+TLS握手）降至接近单次UDP RTT，是三大协议中冷启动性能最优的方案。同时QUIC的连接ID机制使网络切换（Wi-Fi与蜂窝间）时连接不中断，对移动设备尤为友好。

3.3 风险与现状

• 0-RTT重放风险：0-RTT数据理论上可被重放，DNS查询的幂等性使其实际影响有限，但协议实现仍应遵循RFC 9001对0-RTT的使用约束。
• UDP 853可识别可阻断：与DoT类似，专用端口赋予其可治理性，也赋予中间方定向阻断能力。
• 部署曲线：自RFC 9250（2022-05）发布以来，Cloudflare（1.1.1.1）、AdGuard、Mullvad等公共递归已提供DoQ服务，但操作系统与浏览器级原生支持仍在推进中，生态成熟度显著落后于DoH（详见第3页）。

04 · 隐私增强架构：ODoH与OHTTP

4.1 ODoH（RFC 9230）：目标-中继信任分离

加密DNS的固有残留问题是：递归解析器仍然看得见全部查询。ODoH通过引入“中继（Relay）”实体打破这一单点可见性：

ODoH的安全性依赖于一个明确的不共谋假设：中继与目标分属不同运营主体且不相串通。该假设是架构性的——它把“信任某个运营者”转化为“信任两个运营者不共谋”，这是威胁模型的质变而非量变。Cloudflare在其1.1.1.1生态中与多家合作伙伴部署过ODoH服务，用于验证该架构的可行性。

4.2 OHTTP（RFC 9292）：从DNS到任意HTTP的泛化

OHTTP将ODoH的“中继+HPKE加密”思想抽象为通用隐私架构，可承载任意HTTP请求（不限于DNS），并依赖ECH（Encrypted Client Hello，RFC 9849）保护客户端与中继之间TLS握手中的SNI明文暴露。OHTTP与ECH的组合被视为Web隐私基础设施的下一代形态：ECH消除握手阶段的域名明文，OHTTP消除应用层的请求可见性。

05 · 发现机制：SVCB/HTTPS RR与DDR

5.1 SVCB与HTTPS资源记录（RFC 9460）

HTTPS RR（SVCB RR的HTTPS专用形式）允许域名在DNS中公告其服务的连接参数：ALPN（h2/h3）、ipv4hint与ipv6hint（服务端IP提示）、ech（ECH配置）、port等。对加密DNS而言，其关键作用是加密解析器的服务端点发现与参数下发——客户端查询指定名称的HTTPS RR，即可获得该解析器支持的协议、端口与IP，避免将IP地址硬编码在客户端。

5.2 DDR：网络指定加密解析器的发现（RFC 9463）

DDR解决“设备接入网络后，如何获知网络运营商推荐的加密解析器”的问题。机制要点：

• 客户端向特殊域名 _dns.resolver.arpa 查询SVCB记录，网络（通过DHCP/RA或本地代答）返回网络指定加密解析器的ADN（认证域名）、协议与端口；
• 客户端随后验证该ADN的证书，建立加密通道，并将默认解析切换到加密模式；
• 设计目标：让加密DNS与“网络原生解析器”共存——既获得链路加密，又不绕过网络治理点。

5.3 ADN与降级策略

ADN（认证域名）是所有加密DNS配置的核心安全锚点：无论证书主机名验证还是SPKI pin，最终都落到“客户端配置的ADN是否可信”。降级策略（加密失败后是否回退明文、回退到哪个解析器）是RFC 8310之外的工程实践要点——错误的降级策略会把严格模式架空为机会模式（见第4页攻击面）。

06 · 加密DNS与DNSSEC的互补矩阵

工程结论：加密DNS与DNSSEC是正交互补关系——前者保护“传输中”，后者证明“内容真”。理想的递归配置应同时开启两者：对客户端提供加密通道，对上游应答执行DNSSEC验证。这与本专题子课题02（DNSSEC部署与验证）直接衔接。

本节参考来源（第2页）

以下均为真实可查的权威来源（IETF RFC、IETF Trust文档、IANA）。