摘要

  • DoH 保护客户端与解析器之间的通道，却不会替用户的具体网络环境决定应当选用哪个解析器。
  • 发现机制可以把已知的网络解析器升级为加密服务，但最终是否采用仍由客户端策略决定。
  • 私有命名空间、过滤、回退和日志管辖会随解析器选择一同移动，即使 TLS 会话完全健康。
  • 应以一张解析器策略图把指定、认证、选择、命名空间和数据实践连成同一控制面。

设想一个假设场景。两台受管笔记本接入同一个办公网络。第一台由操作系统发现并验证网络指定解析器的加密端点，内部服务名仍可解析。第二台的浏览器选择公共 DoH 服务，加密连接成功，私有名称却消失，网络原有的 DNS 过滤也不再位于路径中。两条加密通道都没有故障，区别在于解析权由谁选择，以及它带来了哪一套策略。

RFC 8484 把每一组 DNS 查询与响应映射为 HTTPS 交换，由 TLS 提供机密性和完整性。该标准同时指出，本地策略和分割 DNS 会让不同解析器对同一查询给出不同答案；依赖明文 DNS 的检查与过滤系统也无法观察 DoH 流量。因此，加密解决了通道暴露，却让一个原本隐含的问题变得突出：真正负责回答的解析器由哪个组件决定。

RFC 9462 的“指定解析器发现”给出了受约束的升级路径。客户端可以从已知的非加密解析器，转到由同一运营者或合作方提供的加密服务。验证式发现要求有效的证书链，而且证书的 IP 地址 subjectAltName 必须覆盖提出指定的解析器。机会式发现则允许加密与非加密服务共用同一 IP 地址，并建议这种方式只用于私有或本地地址。它保护传输，却不通过证书名称认证解析器身份。两种方式提供的保证不同，都没有取消客户端的选择权。

RFC 9463 让接入网络能够通过 DHCPv4、DHCPv6 或 IPv6 路由器通告指定加密解析器，其中可包含认证域名、地址、协议信息和服务优先级。但“指定”是一项提议，不等于对所有客户端强制执行。操作系统或应用可以接受、比较或拒绝。责任因此分布在接入网络、客户端平台、应用和解析器运营者之间。

数据治理也随之迁移。RFC 8932 建议 DNS 隐私服务减少数据收集，将运营留存缩短到可行的最短期限，限制人员访问，并公开说明实践。应用改用另一个解析器时，处理地点、留存期限、法律管辖和事件证据可能同时改变。

可执行的控制是一张解析器策略图。对每类客户端和网络环境，记录策略负责人和决策时间、谁指定了解析器、身份如何认证、哪个组件作出选择、它服务哪些命名空间、采用什么过滤或保护，以及允许怎样回退。图中还应明确查询与日志的管理者、留存期限和适用管辖地。测试应同时覆盖公共与私有名称，并在浏览器、系统、DHCP 配置、证书或端点变化后重做。

来源