DNS 隐私：DoH、DoT、DoQ 与 ODoH

客户端把 DNS 改为 HTTPS 后，本地网络通常不能直接读取查询名称，但递归解析器仍知道谁在查询什么。ODoH 又将客户端来源与查询内容拆给不同角色。比较这些协议时，最有用的问题是“对哪个观察者隐藏了什么”，其次才是端口和往返次数。

先画出信任边界

DoT、DoH、DoQ 主要保护客户端到所选服务器这段传输。服务器终止加密后需要读取 DNS 消息才能处理，仍可记录来源、名称、时间和结果；浏览器、本机恶意软件或企业管理组件也可能在加密之前看到查询。

递归器向权威的查询是另一段链路，其可见性和加密策略独立。网络观察者还可看到目的 IP、连接时序和流量大小，并可能结合后续网站连接推测行为。加密 DNS 减少直接暴露，不等于隐藏所有访问元数据。RFC 9076：DNS 隐私考虑

DNSSEC 则认证 DNS 数据。TLS 连接正确认证了某个解析器，不等于解析器提供的数据已经过 DNSSEC 验证；DNSSEC Secure 回答也不自动隐藏查询名称。

DoT：保留 DNS/TCP framing，外加 TLS

DoT 默认连接 TCP 853，建立 TLS 后发送两字节大端长度与 DNS 消息，长度不含前缀本身。多个查询可复用连接并进行流水线处理，应答未必按查询顺序返回，客户端据 ID 与上下文匹配。RFC 7858：DoT

TLS 版本、连接复用与恢复影响握手成本。ECH 不是 DoT 的内建必选项，也不会把 TLS 和底层 TCP 的全部建连成本一并消除。专用端口方便识别服务类型，但实际放行与可达性仍由网络策略决定。

服务器地址与认证名称是两个概念：连接某个 IP 后仍要依据可信配置验证预期服务身份。Strict Privacy 配置与 opportunistic 模式在认证和失败处理上不同；若握手失败就回退明文，隐私目标也随之改变。RFC 8310：DNS 隐私使用配置

DoH：HTTP 成功与 DNS 成功分开判断

RFC 8484 的二进制格式为 application/dns-message。POST 将 DNS wire message 直接放入请求体；GET 使用 dns 参数，值是去掉填充的 Base64url 编码。它不是 IDNA wire format，也不需要再加 DNS/TCP 的两字节长度前缀。RFC 8484：DoH

例如 33 B DNS 查询经 Base64url 编码为 44 个字符；POST 的 DNS body 则仍为 33 B，HTTP/TLS/QUIC 开销另算。JSON 查询 API 是特定服务另行定义的接口，不能把 application/dns-json 当作标准 DoH 客户端必须支持的协商结果。

DoH 客户端通常将 DNS ID 置零以改善 HTTP 缓存友好性，关联由 HTTP 交换提供；这与 UDP 上只靠随机 ID 的使用背景不同。HTTP 缓存还应与 DNS TTL 协调：若缓存响应 Age=20 s，不能把原 TTL=60 s 当作从现在又有完整 60 s。

DoH 可使用 HTTP/2 或 HTTP/3。HTTP/2 的流复用仍共享 TCP 的有序字节交付；HTTP/3 使用 QUIC，但 DoH over HTTP/3 与独立 DoQ 是不同应用映射，ALPN、消息格式和端口使用都不能混用。

DoH 与网页 HTTPS 使用相同常见端口，不代表完全不可区分：服务端地址、TLS 信息、流量模式或受管理终端策略仍可识别、限制相应服务。GET 参数不会在 TLS 网络路径上作为明文 URL 展示，但终止 HTTPS 的服务和日志系统仍可能记录它。

DoQ：每次交换一条客户端双向流

DoQ 协商 ALPN doq，通常使用 UDP 853。客户端为每次 DNS 查询打开一条双向流，在发送方向写两字节长度、DNS 消息并结束该方向；服务器在同一流反向返回带长度的响应并结束。DNS ID 必须为零，查询匹配依赖流。RFC 9250：DoQ

客户端双向 Stream ID 为 0、4、8、12……；它们的低两位相同，编号增加 4 不会改变发起方和方向类型。QUIC stream 本身是字节流，具有 FIN/偏移并不意味着 DoQ 规范不再需要长度前缀；接收方仍需处理分次读取与消息长度校验。

查询 A 所在流有缺口时，查询 B 的完整响应可以在另一个流交付，但它们仍共享连接拥塞控制和资源。一个包同时包含两条流的数据时，丢失也会影响两条流，不能写成无条件消除一切等待。

0-RTT 需要可用恢复状态且可能被拒绝，不是首次 DoQ 查询默认零握手。是否允许某种查询进入 early data，以及被拒绝后的处理，都应遵循 DoQ 与应用语义，而不能把协议名称当成重放安全证明。

ODoH：代理看来源，目标看内容

客户端先取得目标的 ODoH 公钥配置，使用 HPKE 保护 DNS 查询，再经 HTTPS 送给 proxy，由 proxy 转交 target。target 解密并处理查询，响应按对应密钥上下文保护后沿代理返回。RFC 9230：ODoH

要保留这种分离，不能附带把客户端地址直接告知 target 的额外元数据；客户端也要可信地获取目标配置并处理密钥轮换。查询内容若自身携带标识性名称，或攻击者能观察两侧流量时间，仍可能关联用户。

ODoH 不保证全局匿名，也不是简单“再套一层 HTTPS”：内层消息保护使代理无法终止外层 TLS 后直接读取查询。额外代理跳转、目标处理、连接复用及配置获取决定成本，不能给所有部署写死为两 RTT。

把两份观察记录拼在一起会发生什么？

这不是协议功能对照表，而是对信任假设做一次操作：只拿一侧记录时，联合信息缺一列；两侧协作后，共同事件可把两列连接起来。实际关联未必需要显式标签，时序和消息特征也可能提供线索。

时延比较：把冷连接和热连接分开

设客户端到服务器 RTT=30 ms，服务已缓存答案，无丢包，忽略处理与解析服务器地址的时间。已有可用加密连接时，一次查询/响应约需一个 RTT，即 30 ms，与协议曾经使用几步握手无关。

冷 TCP + TLS 1.3 的简化顺序预算可以是 TCP 一 RTT、TLS 一 RTT、查询/响应一 RTT，总计约 90 ms；冷 QUIC 常见握手后查询预算可约两 RTT，即 60 ms。实现发送时机、恢复、Retry 和证书传输会改变结果，这些不是协议保证值。

若已有 ODoH 外层连接，客户端到 proxy RTT=20 ms、proxy 到 target RTT=30 ms，在请求串行转交和回程对称的简化模型下，通信部分约 50 ms，再加处理和递归查询。它不能与“直接到另一地理位置服务器 RTT=80 ms”的路径只按协议名字比较。

缓存未命中所需的上游迭代、尾部丢包和连接闲置回收往往比头部字节差异更重要。应分别统计冷启动、热缓存、上游未命中及失败恢复，而非只列一个不可复现的速度排名。

引导与失败策略也是隐私的一部分

使用 https://dns.example/dns-query 前，需要知道服务器 IP，并认证这个名称。可通过预配置、已有引导解析或相应发现机制取得地址；不能要求“只依赖一个还没有地址的加密解析器来解析它自己”而不给启动方案。

浏览器可能使用独立 DoH，系统 resolver 仍走另一条路径；VPN、分流 DNS、搜索域和本地服务发现也会影响实际查询。验证应沿应用实际使用的解析路径观察，不能只看到一个 DoH 连接就宣布整台机器没有明文查询。

这些是可配置的产品行为，不能从 DoH/DoT/DoQ 的名字推断。采用哪种应围绕实际需求配置并验证，后续基础设施篇继续讲部署与观察。

本地编码对照

import base64
import struct
qname = bytes.fromhex('03777777076578616d706c6503636f6d00')
query = struct.pack('!6H',0,0x0100,1,0,0,0)+qname+struct.pack('!HH',1,1)
assert len(query)==33
# DoH POST body 无两字节 DNS/TCP 前缀。
post_body = query
get_value = base64.urlsafe_b64encode(query).rstrip(b'=')
assert len(get_value)==44
assert base64.urlsafe_b64decode(get_value+b'='*((-len(get_value))%4))==query
# DoT/DoQ 的单条消息 framing 都保留该前缀。
framed = struct.pack('!H',len(query))+query
assert len(framed)==35 and int.from_bytes(framed[:2],'big')==33
assert framed[2:]==post_body
assert [index<<2 for index in range(4)]==[0,4,8,12]
assert max(0,60-20)==40
assert 3*30==90 and 2*30==60 and 20+30==50
print('DoH 编码、DoT/DoQ 前缀、双向流号、缓存 Age 与时延预算通过')

这是消息映射与明确假设下的预算检查，未连接真实 DNS 服务、执行 HPKE 加解密或变更系统隐私设置。

继续查阅

• DNS 协议与解析：DNS wire message 与缓存。
• DNSSEC 与 DNS 安全：数据认证和 AD 的信任边界。
• DNS 基础设施：配置角色、引导、分流与故障定位。
• UDP 与 QUIC：流、握手与包保护。