摘要

  • EDNS(0) 选项 12 允许加密 DNS 的发送方加入任意长度的填充。它统一的是线格式容器，不是隐私结果；RFC 8467 所建议的查询 128 字节、应答 468 字节分块属于实验性策略。
  • 有效保护由多方共同产生：客户端决定查询填充，服务端决定应答填充，TLS、HTTP 或 QUIC 决定外层轮廓，路径承担额外流量和分片风险；时序、端点与问答次数仍可被观察。

两台 DoT 解析器都可以在配置页写着“已启用填充”，实际效果却截然不同。第一台把查询补到 128 字节的整数倍，把应答补到 468 字节的整数倍。第二台无论原始长度多少都只加 16 字节。两者都能生成合法的选项 12；但后者只是把每个原有指纹平移了一个已知常数。

传输加密保护客户端与服务端之间的内容，不会自动隐藏密文长度。常见域名、RR 类型和应答组合往往形成有辨识度的问答尺寸。掌握明文样本的观察者，可以在不解密名称的情况下尝试匹配这些轮廓。

RFC 7830 给出的修补刻意很小。EDNS 的 OPT 伪资源记录本来就用于承载扩展，Padding 使用其中的选项代码 12。每条 DNS 报文最多出现一次。长度字段计算填充字节，填充为零也合法，只是选项头本身仍占四字节。发送方通常写入 0x00，接收方必须接受其他取值；这些字节不具有 DNS 内容语义。

规范没有规定具体加多少。这不是缺陷，而是把互操作语法与本地策略分开。RFC 8467 后来比较不同方案，并以实验性建议提出分块填充：查询取最接近的 128 字节倍数，应答取 468 字节倍数。多个原始尺寸由此被压入同一可见区间。

区间并不等于无信息。如果分块大小公开，一条 256 字节查询仍暴露了原始长度的上下界。发送时间、间隔、方向和问答数量也没有改变。即使同时使用加密与填充，流量仍可能被识别为 DNS。掩护流量和人为抖动针对的是其他侧信道，也会带来另一套成本。

查询里的 Padding 不是给服务端的无限命令。服务端收到带填充的查询后必须填充应答，除非这样会超过允许的 UDP 负载。没有 Padding 但已经声明 EDNS 能力时，服务端可以主动填充；连 EDNS 都没声明时则不得添加。查询授权的是一项受容量约束的动作，并不保证服务端选择了有效的分块策略。

网络路径会把隐私策略变成可靠性问题。Padding 必须最后应用，因为它使用其他 EDNS 选项留下的空间。计算时不包含 DNS over TCP 的两字节长度前缀，否则仅仅切换传输就会产生不同区间，反而透露原始长度。接近路径 MTU 时，大分块可能造成不必要的 UDP 分片；超过 MTU 则必然分片。RFC 7830 还明确禁止在明文 DNS 上使用，因为内容本来就可见，额外字节反而可能增加放大风险。

DoH 与 DoQ 又重新分配控制面。DoH 可在认证过的 HTTPS 通道内携带 EDNS 填充，但 HTTP 头、Cookie、连接复用和时序仍可形成关联。DoQ 可以填充 DNS 报文；如果 QUIC 库暴露合适接口，也可以直接把完整 QUIC 包对齐到少数尺寸，同时考虑确认帧和流量控制帧。

因此，没有任何一方独占隐私结果。客户端控制查询与解析器选择，服务端控制应答，传输库可能控制最终包形，网络决定哪些尺寸能够稳定送达。IANA 登记代码 12 只能证明各实现拥有共同词汇，不能证明已经实现、启用或生效。

运行代码的检验不是一个开关，而是一组分布。运营者需要比较填充前后尺寸、每个区间容纳多少原始形态、带填充查询收到多少未填充应答，以及新增字节、丢包、截断、分片和回退。只有这些证据才能说明匿名集合真的扩大了。