APNIC 在 2020 年 9 月复盘 DNS 查询隐私保护进展，重点考察 RFC 7816 定义的 QNAME 最小化技术在解析器端的部署变化。2019 年 8 月测量显示仅 3% 用户查询经由启用该特性的解析器，一年后数据如何成为核心看点。
隐私泄露根因与两类缓解路径：
DNS 协议设计初期未将隐私置于首位，查询与响应明文传输，易遭中间人篡改，且向权威服务器泄露完整域名等冗余信息。业界形成双轨对策：一是引入加密传输，如 DoT 与 DoH；二是从源头减少查询载荷，即 QNAME 最小化。后者依据 RFC 6973（2013 年 7 月）“数据最小化”原则，仅向各级权威发送必要标签，压缩泄露面。
QNAME 最小化机制与标准化进程：
RFC 7816（2016 年 3 月）将该技术定为实验标准：解析器不再一次性发送完整 QNAME，改为从根区开始逐级迭代，仅在必要时追加下一级标签。例如查询 www.example.com，首包仅含 com.，后续再请求 example.com.，最后才查 www。此法可阻断根、顶级域服务器获取完整主机名，但需解析器实现迭代逻辑变更，且可能增加往返延迟。
部署测量现状与数据缺口：
原文指出 2019 年 8 月仅 3% 用户流量经过启用 Qmin 的解析器，但 2020 年复测的具体比例、采样规模、主要解析器软件版本分布等关键指标原文未给出具体数据。亦未披露是否纳入 DoT/DoH 加密场景下的 Qmin 叠加效果，或对比递归与权威侧的部署差异。
对运维而言，QNAME 最小化属于无感升级——仅需在 Unbound、Knot Resolver 等主流软件中开启 qname-minimisation 选项，即可在不改动网络架构前提下降低隐私风险。若配合 DoT/DoH 部署，可形成“少泄露+防窃听”双层防线，建议在解析器升级窗口期同步开启并监控延迟指标。
原文: APNIC Blog（2020-09-11）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog