第 5.1 节描述了本协议与 HTTP 缓存之间的交互. 能够控制客户端所用缓存的 对手, 可以影响该客户端对 DNS 的观察结果. 这与使用 HTTP 的其他协议中 HTTP 缓存带来的安全影响没有区别.

在没有 DNSSEC 信息的情况下, DoH 服务器可以响应 DNS 查询并向客户端提供 无效数据. 第 3 节禁止使用并非来自已配置服务器的 DoH DNS 响应. 这一禁 止并不保证能够防范无效数据, 但确实降低了风险.

10. 运营考虑

本地策略考虑和类似因素意味着, 不同 DNS 服务器可能会对同一查询提供不同 结果, 例如在 split DNS 配置 [RFC6950] 中. 从逻辑上说, 被查询的服务器 会影响最终结果. 因此, 客户端对 DNS 服务器的选择可能影响它从查询中获得 的响应. 例如, 在 DNS64 [RFC6147] 的情况下, 这一选择可能影响 IPv6/IPv4 转换是否能够工作.

本规范使用的 HTTPS 信道在 DoH 客户端和 DoH 服务器之间建立安全的双方通 信. 依赖 DNS 非安全传输的过滤或检查系统, 将无法在 DNS over HTTPS 环境 中工作, 原因是 TLS 提供了机密性和完整性保护.

一些 HTTPS 客户端实现会对 TLS 所用证书的吊销状态执行实时第三方检查. 如 果该检查作为 DoH 服务器连接过程的一部分执行, 并且检查本身需要 DNS 解析 才能连接到第三方, 就可能发生死锁. 使用 Online Certificate Status Protocol (OCSP) [RFC6960] 服务器, 或使用 Authority Information Access (AIA) 获取 Certificate Revocation List (CRL) (见 [RFC5280] 第 4.2.2.1 节), 都是这种死锁可能发生的示例. 为缓解死锁可能性, 对 DoH 服务器进行 的认证 SHOULD NOT 依赖 TLS 握手中指向外部资源的基于 DNS 的引用. 对于 OCSP, 服务器可以使用适合 TLS 版本的机制, 将证书状态作为握手的一部分一 并提供, 例如对于 TLS version 1.3 使用 [RFC8446] 第 4.4.2.1 节. AIA 死 锁可以通过提供中间证书来避免, 这些证书原本可能需要通过额外请求获取. 注意, 对于 DoH 服务器可能重定向到的服务器, 也需要考虑这些死锁.

当 HTTP 请求需要解析 DNS URI 的 hostname 部分时, DoH 客户端可能面临类 似的引导问题. 正如传统 DNS nameserver 的地址最初不能从该同一服务器确 定一样, DoH 客户端不能使用其 DoH