60、再探 DNS QNAME 最小化

再探 DNS QNAME 最小化

1. DNS 查询中的信息泄露问题

在 DNS 查询过程中，有时会出现查询返回 NXDOMAIN 响应的情况，这表明所查询的域名不存在。即便启用了查询名称最小化（qmin）功能，解析器仍可能泄露有关较低级别标签的信息，例如 Google Public DNS 的解析器就存在这种现象，但其运营商也无法解释偶尔出现的对完全限定域名进行查询的原因。

2. 受控实验

2.1 实验目的

本实验旨在研究流行的开源 DNS 解析器的最新版本在处理最小化查询时的性能表现。

2.2 实验所选解析器

考虑到解析器的受欢迎程度，选择了 Bind、Unbound、Knot Resolver 和 PowerDNS 这四个开源解析器。实验使用的各解析器版本如下：
- Unbound 1.14.0
- Bind 9.16.24
- Knot Resolver 5.4.4
- PowerDNS 4.6.0

实验中关闭了 DNSSEC，并将各解析器的缓存大小配置为相同。

2.3 实验方法

• 域名列表选择 ：使用 Cisco Umbrella Top 1M 列表中的域名进行性能和错误率测量。该列表基于其 Umbrella 全球网络上的被动 DNS 使用情况，包含了最流行的查询，不仅涵盖基于浏览器的 HTTP 用户请求，还考虑了其他协议和非终端用户的情况。
• 域名聚合 ：为避免每日和每周的波动及模式影响，从 2022 年 4 月 4 日至 4 月 19 日这两周的时间跨度内聚合域名，最终得到 130 万个域名，平均每个域名有 3.26 个标签，中位数为 3 个标签，最小为 1 个标签，最大为 104 个标签。
• 域名排序 ：将该域名列表按四种不同顺序排序，以平衡缓存效果。
• qmin 模式设置 ：解析器启用 qmin 有两种模式，即宽松模式（relaxed）和严格模式（strict）。这两种模式决定了解析器在收到来自可能有故障的名称服务器的 NXDOMAIN 或其他意外响应时，是否应回退到完整查询名称。在本次实验中：
  • Unbound 和 Bind 可以选择关闭 qmin、以宽松模式运行或严格模式运行。
  • PowerDNS 可以选择关闭 qmin 或以宽松模式开启。
  • Knot 没有关闭 qmin 的选项，仅以宽松模式运行。

2.4 实验结果

解析器版本	模式	发送数据包数量	错误率
Unbound 1.8.0 (2018)	关闭	570 万	12.6%
Unbound 1.8.0 (2018)	严格	671 万	15.9%
Unbound 1.8.0 (2018)	宽松	682 万	12.6%
Knot 3.0.0 (2018)	宽松	594 万	13.5%
Bind 9.13.3 (2018)	关闭	507 万	16.6%
Bind 9.13.3 (2018)	严格	584 万	21.6%
Bind 9.13.3 (2018)	宽松	639 万	17.1%
Unbound 1.14.0 (2022)	关闭	593 万	6.8%
Unbound 1.14.0 (2022)	严格	850 万	8.4%
Unbound 1.14.0 (2022)	宽松	868 万	6.8%
Knot 5.4.4 (2022)	宽松	314 万	7.0%
Bind 9.16.24 (2022)	关闭	709 万	11.2%
Bind 9.16.24 (2022)	严格	773 万	11.2%
Bind 9.16.24 (2022)	宽松	769 万	11.2%
PowerDNS 4.6.0 (2022)	关闭	335 万	7.0%
PowerDNS 4.6.0 (2022)	宽松	356 万	7.0%

从上述表格可以看出：
- Unbound 1.14.0 ：无论使用哪种 qmin 模式，与 Unbound 1.8.0 相比，发送的数据包数量都更多，但所有查询的错误率均有所降低，且严格模式下的错误率仍高于宽松模式，这是由于可能有故障的名称服务器会产生额外的 NXDOMAIN 响应。
- Bind 9.16.24 ：无论配置如何，与 Bind 9.13.3 相比，发送的数据包数量都更多。
- Knot 5.4.4 ：与 Knot 3.0.0 相比，数据包数量和错误率都显著降低，这与 Unbound 和 Bind 的趋势相反。
- PowerDNS 4.6.0 ：宽松 qmin 模式和无 qmin 模式下发送的数据包数量相似，这与预期中 qmin 会产生更多数据包的情况不同。不过，由于 PowerDNS 默认以宽松模式启用 qmin，因此启用和未启用 qmin 时错误率相似是可以预期的，Unbound 和 Bind 也是如此。

总体而言，与原研究相比，所有解析器的错误率都有所降低，但发送的数据包数量和错误率会因具体解析器和使用的模式而异。qmin 功能与数据包数量密切相关，因为完整的域名通常比迭代解析的最小化构建查询所需的查询次数更少。结果表明，自上次研究以来，启用 qmin 的递归 DNS 解析器的性能有所改善，但还需要进一步研究以全面了解对每个解析器的影响。

2.5 实验流程 mermaid 流程图

graph LR
    A[选择域名列表] --> B[聚合域名]
    B --> C[排序域名列表]
    C --> D[设置解析器 qmin 模式]
    D --> E[进行性能和错误率测量]
    E --> F[分析实验结果]

3. 结果分析与讨论

3.1 测量结果分析

通过对测量结果的总结，并与之前的测量结果进行对比，我们可以看到在主动测量（RIPE/open）中，qmin 的采用率有所增加。不过，RIPE Atlas 探针的 qmin 占比较高，这可能表明这些探针存在偏差。运行 RIPE Atlas 探针的用户可能技术能力较强，会管理具有最新安全和隐私功能的解析器，因此他们可能不能代表互联网上的普通解析器。但总体而言，qmin 的采用率确实在增长。

在对开放解析器的主动测量中，可能更准确地反映了 qmin 的情况，但需要注意的是，超过 80% 的响应解析器返回了错误，其中超过 90% 是 REFUSED 响应。这可能是因为解析器被配置为仅代表某些特定客户端发送查询。

以下是不同测量对象在不同年份的 qmin 采用率对比表格：
| 年份 | RIPE | 开放解析器 | K - Root | .nl ccTLD |
| — | — | — | — | — |
| 2018 | 10% | 1.6% | 0.6% | 35.5% |
| 2022 | 64% | 16.42% | 2.5% | 57.3% |
（.nl ccTLD 的数据从 2019 年开始可用）

从这个表格可以清晰地看到，在各个测量对象中，qmin 的采用率都呈现出增长的趋势，这对于互联网隐私来说是一个积极的发展。

3.2 测量方法的改进

本次对 qmin 的研究在很大程度上借鉴了之前的方法，但也通过对方法的改进带来了新的见解。
- 地理位置因素 ：在对开放解析器的主动测量中，发现三个地理位置之间没有显著差异，而之前的研究仅基于单一地理位置的测量无法得出这一结论。
- 多次查询解析器 ：之前的研究仅根据一次响应来对开放解析器进行分类，而本次研究对每个开放解析器进行了 100 次查询，这在分类解析器时揭示了更多信息。
- 使用通配符标签域名 ：为了减轻缓存委托的影响，本次研究设置了一个使用通配符标签的新域名，用于第二次对开放解析器的主动测量。而之前的 DNSThought 测量没有使用这样的域名，可能导致第一次主动测量中的一些响应是缓存的误报。

部分开放解析器在本次研究中被归类为冲突解析器。使用通配符标签可以减轻任何缓存委托的影响，例如查询一个非最小化解析器，而该解析器缓存了来自启用 qmin 的转发解析器的最近最小化查询。最可能的原因是 DNS 负载均衡器在一组解析器之间分配查询负载，根据相关研究，一些 DNS 负载均衡器可能为其后端解析器使用不同的软件包，这可能是观察到冲突的原因。此外，还观察到 73% 的冲突解析器返回的 NO 响应多于 HOORAY 响应，这与被分类为启用 qmin 和未启用 qmin 的解析器的比例相似。

3.3 qmin 深度限制

在 DNSThought 的客户端主动测量中，是在第四级域名上测量 qmin 的。这意味着在更低级别（如 TLD 和根）进行查询最小化的解析器数量可能更多。例如，在使用单独域名对开放解析器进行的主动测量中，Google Public DNS 解析器被归类为未启用 qmin，但根据 DNSThought 的数据，这些解析器自 2020 年以来一直在进行查询最小化。进一步使用不同域名进行查询发现，Google Public DNS 解析器会根据域名的不同而有不同的响应，这是因为 Google 希望在根和 TLD 级别获得查询最小化的认可，而这在 DNSThought 的统计中最初并未体现。

虽然解析器可能不会在二级域名（2LD）之外实现 qmin，但与在根和 TLD 级别完全公开查询名称相比，在权威 DNS 区域内缺乏数据最小化的问题并不那么严重。因为注册 2LD 的组织很可能了解其子域名，所以将这些标签暴露给其自己的名称服务器不会造成太大危害。但对于一些注册在如.ac.uk 或.co.jp 等域名下的组织，情况就没那么简单了。

为了解决这个问题，建议使用公共后缀列表（PSL）并额外增加一个标签（PSL + 1）来设置深度限制。PSL 是由 Mozilla 维护的一个列表，主要用于限制 cookie 设置，它包含有效的 TLD（如.com 和.net），包括那些有多个标签的 TLD（如.ac.uk 和.co.jp）。一个启用 qmin 的解析器使用 PSL + 1 方法查找 a.b.example.ac.uk 的资源记录（RR）时，应该向根发送 uk，向.uk ccTLD 发送 ac.uk，然后向.ac.uk 的名称服务器发送 example.ac.uk。之后，解析器应停止最小化，向 example.ac.uk 的名称服务器发送完整的 a.b.example.ac.uk，因为 example.ac.uk 很可能是权威 DNS 区域。

3.4 测量方法改进流程 mermaid 流程图

graph LR
    A[选择开放解析器] --> B[多次查询解析器]
    B --> C[使用通配符标签域名]
    C --> D[进行主动测量]
    D --> E[分析测量结果并分类解析器]

4. 结论

通过客户端的主动测量和名称服务器端的被动测量，我们对查询名称最小化的采用情况进行了评估。此外，还对四个开源解析器进行了受控实验，以测量性能和错误率。本次研究在之前方法的基础上进行了扩展，并为被动测量增加了额外的数据集。扩展方法包括从多个地理位置进行测量，以及向解析器发送多个查询而不是单个查询，这揭示了一些解析器会同时发送正响应和负响应的情况，而之前的方法无法观察到这一点。

从主动测量中可以看出，qmin 采用率随时间呈现出积极的增长趋势，尤其是在 2020 年 Google 的 ASN 中的解析器开始进行查询最小化后，增长迅速。绘制随时间变化的启用 qmin 的解析器比例图表显示，RIPE Atlas 探针使用的解析器中有 64% 正在进行查询最小化，与之前的研究相比有了显著的提升。

在对 Google Public DNS 的研究中发现，客户端主动测量的结果高度依赖于特定的域名。借助 NLnet Labs 的帮助，我们发现 Google 的解析器存在 qmin 深度限制，除了 DNSThought 使用的域名之外。

在受控实验中，所有解析器的错误率都有所降低，这可能是由于相关标准（如 RFC 9156）的更新，该标准更改了 RR 查询类型、指定了某些错误的回退机制，并更动态地添加标签，从而使之前的 qmin 实现（如 RFC 7816）过时。也有可能是名称服务器端发生了变化。不过，其中两个解析器的数据包数量增加，而另外两个解析器的数据包数量减少或保持较低水平，具体原因仍不明确。

在考虑性能和隐私时，我们讨论了查询名称最小化的适当程度。我们认为，在权威 DNS 区域之后，泄露敏感子域名的隐私风险会降低，因此可以将公共后缀列表作为配置最小化深度限制的可能资源。

为了便于未来再次研究 qmin，我们提供了使用的脚本。同时，在研究过程中我们也仔细考虑了测量和披露的伦理问题，使用第三方扫描的开放解析器列表，避免对 IPv4 地址空间进行自行扫描，从而减少对网络的不必要负载，并以轮询方式分散主动测量，避免在短时间内对单个解析器造成过大负载。