系统设计 / DNS · 层级、委任、缓存，以及不存在的「浸透」 / 查询的可见范围：QNAME minimisation 与加密传输 待审核 8 / 11
RFC 9156 · DoT · DoH

查询的可见范围：QNAME minimisation 与加密传输

DNSSEC 解决的是「应答是否可信」。它明确不解决另一件事：查询与应答仍然是明文，路径上的任何观察者都看得见查的是什么。

而 DNS 的查询记录是一份格外敏感的数据：它按时间顺序记下了一台设备访问过的每一个域名，包括那些从未真正建立连接的。补这一块有两条互不替代的路径。

1 · 少说话：QNAME minimisation

第一条路径不需要任何加密，只需要别说不必说的话。

原始的反复检索里，递归服务器向每一级都发送完整的查询名——问根 mail.vega.dev，问 dev 也是 mail.vega.dev。可根服务器根本不需要知道完整的名字：它能给的只有 dev 的委任，而那只取决于最右一个 label。

图 1-1 · 开与不开 minimisation 时各级服务器分别看到的名字。下半部分是 RFC 9156 的放大节奏，可拖动 label 数观察查询数如何被上限顶住。

RFC 9156 定的算法是从已知的最深委任点出发，逐级放大查询名。两个参数控制节奏：MAX_MINIMISE_COUNT（建议 10）限制总迭代次数，MINIMISE_ONE_LAB（建议 4）规定前几次每次只加一个 label。18 个 label 的名字在默认参数下得到 1,1,1,1,2,2,2,2,3,3 这个序列——极长的名字不会换来极多的查询。

中间那些查询用什么 QTYPE 也有过反复。RFC 7816 最初建议用 NS（顺便把原始类型也藏起来），而 RFC 9156 明确放宽了这条，原话是「本文档放宽 RFC 7816 中使用 NS 查询类型以隐藏原始 QTYPE 的建议」，改为推荐 A 或 AAAA——理由很实在：这两种最不容易在 DNS 软件与中间设备上引发问题。

警示 · minimisation 会撞上一类实现缺陷：空节点（见第 2 讲）。有些权威服务器对本该应答 NODATA 的空节点误报 NXDOMAIN，而 minimisation 会主动去查这些中间名。若解析器采信了中间名的 NXDOMAIN，一个本来存在的名字就被判成不存在。RFC 9156 §3 的算法（步骤 6d）因此允许两种做法，分支条件是解析器是否遵循 RFC 8020：采信，或者改用完整名重问一次。本系列的模拟器把这个选择做成了参数，两种都能跑。

minimisation 的性质值得强调：它减少了需要被信任的对象，不是把信任转移到别处。根与 TLD 服务器从此拿不到完整的查询名——不是因为它们守信，而是因为它们再也收不到。

2 · 加密传输

第二条路径是把 DNS 装进一条加密通道。四种形态：

Do53 是原始的明文形态（53/udp、53/tcp）。DoT（RFC 7858）走 853/tcp 上的 TLS。DoH（RFC 8484）走 443/tcp 上的 HTTPS。DoQ（RFC 9250）走 853/udp 上的 QUIC。

图 2-1 · 四种传输方式下，四类观察者分别还能看到什么。可切换观察者对照；把观察者切到「解析器」那一格是本图的要点。

DoH 与 DoT 的区别不在密码强度，而在可区分性。DoT 占用专属端口，于是流量类型仍可从端口号识别，也可以被整体阻断；DoH 混在 443 的 HTTPS 流量里，阻断它的代价是连带普通网页。这个差别是技术的，但它的后果主要落在政策层面——DoH 在企业与国家网络管理上引起的争议远多于 DoT。

注 · 这三种加密方式覆盖的都是 stub 到解析器这一段。解析器到权威服务器那一段的加密（DoT 到权威、或 RFC 9539 那类机会性加密）至今部署稀少。所以「用了 DoH 之后我的 DNS 查询全程加密」这个说法不成立：后半段仍是明文，只是那一段看到的是解析器的 IP 而不是客户端的，且在开了 minimisation 时看到的名字也是残缺的。

3 · 加密的作用边界

图 2-1 里最要紧的是「解析器」那一格：四种传输方式下，它都看得到完整的查询名与客户端的 IP。

这不是实现缺陷，而是它的职责——它得知道查的是什么才能代为去查。所以选择 DoH / DoT 的实质是把可见性从沿途的网络转移到一家解析器运营方，不是消除它。加上 DoH 的默认配置往往指向少数几家大型公共解析器，其净效果是把原先分散在许多 ISP 手里的可见性集中了起来。

这就是为什么 minimisation 与加密不能互相替代，也不该拿一个当另一个的理由：

加密改变的是「路上的人能看到什么」，代价是需要信任一个新的终点。

minimisation 改变的是「终点之外的各级还需要知道什么」，代价是可能多几个报文，而且不需要信任任何新的对象。

两者一起用才覆盖全场，而它们与 DNSSEC 又是第三件事——DNSSEC 管的是「答案对不对」，与「谁看得见」正交。三者都到位才算完整，而这三件事在部署上是完全独立的三条线。

4 · 参考文献

  1. Bortzmeyer, S., Dolmans, R., & Hoffman, P. (2021). DNS Query Name Minimisation to Improve Privacy (RFC 9156). IETF.（取代 RFC 7816；§2.1 是 QTYPE 的选择，§2.3 是两个参数，§3 是算法与 NXDOMAIN 的处置。）
  2. Bortzmeyer, S. (2016). DNS Query Name Minimisation to Improve Privacy (RFC 7816). IETF. （实验性，已被 RFC 9156 取代。）
  3. Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., & Hoffman, P. (2016). Specification for DNS over Transport Layer Security (TLS) (RFC 7858). IETF.
  4. Hoffman, P., & McManus, P. (2018). DNS Queries over HTTPS (DoH) (RFC 8484). IETF.
  5. Huitema, C., Dickinson, S., & Mankin, A. (2022). DNS over Dedicated QUIC Connections (RFC 9250). IETF.
  6. Wicinski, T. (Ed.). (2021). DNS Privacy Considerations (RFC 9076). IETF. （威胁模型：谁能看到什么、各段的差别。取代 RFC 7626。）
  7. Gillmor, D. K., Salazar, J., & Hoffman, P. (2024). Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS (RFC 9539). IETF.（实验性；后半段加密的一条路径。）