查询名最小化是递归解析器的一种问法：还没问到负责这个名字的权威服务器时，只送出比已知区多一个或几个标签，而不是整串名字。截至 2026 年 10 月，客户端交给解析器的仍是完整查询。VPN 改变的是这一问发给谁，不代替那台解析器是否把名字截短。
传统问法多送了什么
一个可独立引用的定义句：查询名最小化（QNAME minimisation，RFC 9156）是递归解析器的行为：向一台尚未确认负责原始名字的权威服务器查询时，不发送完整查询名和原始类型，只发送够用来取得委托的那一段名字。
它不修改 DNS 协议。RFC 9156 写明，向权威服务器发送完整名字是传统，不是协议要求。该文档取代 RFC 7816。旧文档曾建议用 NS 类型来掩盖原始类型；现行文本放宽了这一点，NS 仍然允许，但不再比其他类型更有优势。
下面两张表取自 RFC 9156 的例子：冷缓存、要查 a.b.example.org 的 MX。最小化用 A 作为掩盖类型，只说明一种允许的选法。解析器也可以选 AAAA 或其他符合规定的类型。用来掩盖的类型不应当由用户原始类型推出来。DS、NSEC、NSEC3 这类权威在父区的类型，不拿来做这道掩盖。
不最小化时，冷缓存的三问都带着完整名字和 MX：
| 问谁 | 名字 | 类型 |
|---|---|---|
| 根 | a.b.example.org | MX |
.org | a.b.example.org | MX |
example.org | a.b.example.org | MX |
最小化时，RFC 9156 的同一例子改成：
| 问谁 | 名字 | 类型 |
|---|---|---|
| 根 | org | A |
.org | example.org | A |
example.org | b.example.org | A |
example.org | a.b.example.org | A |
example.org | a.b.example.org | MX |
原始类型若本来就是 A，最后那一次用 A 再问完整名字就可以省掉。最小化因此不总是比传统问法多出固定的几问。
根在这个例子里只看见 org。.org 的服务器看见 example.org，看不见左边的 a.b。完整名字会送到当前已知委托的那一台，用来继续找区切。若下面还有一层委托，下一台也会看到完整名字。区切不一定落在每个点上。
谁仍然看得到完整名字
一个可独立引用的结论句：查询名最小化不向递归解析器隐藏名字。存根解析器发出的仍是用户要查的完整查询名和原始类型。
据 RFC 9156 第 2.4 节，存根或转发解析器也可以最小化，但这藏不住它交给上游解析器的数据，因为完整查询终究会到达那台解析器。只有上游自己不做最小化时，存根提前截短，才可能减少权威服务器看见的标签。没有区切缓存的存根若这样做，发出的查询会明显变多。
负责这条记录的权威服务器仍会收到完整名字，否则它无法回答。最小化减少的是更上层、只需要给出委托的那些服务器所看见的标签。
这和加密传输不是一层。DoH/DoT 保护的是到解析器的这一跳，查询内容不对这条路上的旁观者展开。解析器自己仍看到完整名字。查询名最小化不加密，它只减少解析器继续发给上层权威服务器的那一部分。据 RFC 9156 第 6 节，对付线路上的窃听，加密是更直接的办法；最小化可以单方面部署，并且不改协议。
DNSSEC 给记录签名，用来发现应答被改写。签名不隐藏查询名，最小化也不验证签名。两件可以同时存在，也可以只做一件。
和 VPN 各改哪一跳
隧道不编辑 DNS 报文里的查询名。加密隧道在两端之间让沿途读不到这个报文。报文到了解析器，解析器仍按自己的策略决定上游看见多少标签。
连上 VPN 之后若改用另一台递归解析器，下一次缓存未命中就按那一台的策略走。它最小化，上层才少看见标签。它仍发送完整名字，根就仍看见完整名字。图标是否接通，不是这个策略本身。
已经开着的缓存不会跟着换解析器搬走。一台缓存较暖的解析器已经知道更近的委托，后续查询可以少做几步探测，见 DNS 缓存。冷缓存则更接近上一节的表：从根附近开始，一步步把标签加上去。
分离 DNS 决定哪个后缀问哪一台解析器。问出去之后是否截短，仍看那一台。浏览器若另走自己的加密解析器，系统为 VPN 选的那一台就不是这次查询的策略来源。
EDNS 客户端子网 是另一项可选信息：解析器可以把截短后的地址前缀交给权威服务器，用来挑选 CDN。它不决定查询名被截成几段。一台解析器可以最小化名字，同时仍附带地址前缀；也可以两样都不做。
本文不提供挑选解析器或打开最小化的步骤。
查询会不会变多
名字上的标签越多，冷缓存时上游查询可能越多：传统问法往往一问就拿到委托或答案，最小化则可能每个标签问一次。缓存变暖之后，两边的差距会缩小。
解析器必须限制每一条用户请求引出的上游查询数。RFC 9156 给出的一个建议上限是 10 次迭代。只追加一个标签的前几步，文中给的一个可用值是 4。剩下的标签可以在后续迭代里一次追加多个，因此很深的名字不一定每层都只暴露一个标签。以下划线开头的标签，实现也可以选择一次拼回去。这些是允许的收法，不是每一台解析器的实测参数。
据 RFC 9156 引用的一项研究，查询名最小化最多约增加 26% 的查找，并带来最多约 5% 的额外失败。该文同时写明，生产解析器把缓存填上之后，这份开销会减轻。本文没有在 2026 年 10 月复测这个比例，也没有测量某一台公共解析器是否最小化。
短名字若得到 NXDOMAIN，支持 RFC 8020 的解析器可以把「这个名字之下都没有」用于原始查询，从而少问几次。不支持的实现不能从这一次否定推出同样的结论。这和负缓存的寿命是两件事：能不能沿用否定答案，见 DNS 缓存一文；这里只说明最小化有时反而减少发往根的重复查询。
一个可独立引用的结论句：根服务器看不看得到完整域名，取决于解析器有没有把查询截短，不取决于 VPN 图标。
现象对照
| 现象 | 更可能先看什么 |
|---|---|
| 换了 VPN 之后，CDN 或解析路径变了 | 先看换了哪一台解析器，而不是隧道会不会改查询名 |
| 只有第一次访问某个后缀较慢，之后正常 | 冷缓存在逐段探测区切；变暖后步骤变少 |
| 很深的名字偶发解析失败 | 迭代次数碰到实现自己的上限，或某一跳不回答截短后的查询 |
| 本地网络仍能看见完整域名 | 这次查询没有进加密隧道，最小化也不隐藏交给解析器的那一跳 |
| 权威侧仍按完整名字回答 | 负责该区的服务器本来就会收到完整名字 |
核对清单
- 先分清两跳：客户端到解析器送出的是完整名字；解析器到上层权威服务器才可能截短；
- VPN 换的是解析器，不是查询名：那一台不做最小化，根仍能看见完整名字；
- 负责该区的权威服务器仍看见完整名字：截短的是还在给委托的上层；
- 不要把它和 DoH、DNSSEC、客户端子网合成一项：加密、签名、地址前缀、查询名长度各管一段；
- 冷缓存会多问几步：规范要求限制查询次数。26% 和 5% 是文献里的上限量级，不是本文的测量。