可能暴露客户端历史记录某个子集中的状态信息. 在同一连接上将 DoH 请求与 其他 HTTP 请求混合, 也为更丰富的数据关联提供了机会.

DoH 协议设计允许应用程序充分利用 HTTP 生态系统, 包括此处未列举的特性. 利用完整的 HTTP 特性集合, 能够让 DoH 不只是一个 HTTP 隧道, 但代价是使 实现暴露于 HTTP 的完整隐私考虑集合之下.

DoH 客户端和服务器的实现需要在决定是否启用这些特性时, 考虑这些特性的 收益和隐私影响, 以及其部署语境. 建议实现只暴露实现所需特性集合所必需 的最小数据集合.

判定 DoH 实现是否需要支持 HTTP cookie [RFC6265] 尤其重要, 因为 HTTP cookie 是 HTTP 中主要的状态跟踪机制. 除非某个用例明确要求, 否则 DoH 客户端 SHOULD NOT 接受 HTTP cookie.

9. 安全考虑

在 HTTPS 上运行 DNS 依赖底层 HTTP 传输的安全性. 这缓解了基于 UDP 的 DNS 中的经典放大攻击. 使用 HTTP/2 的实现可受益于 [RFC7540] 第 9.2 节 定义的 TLS 配置文件.

会话级加密在流量分析方面存在众所周知的弱点, 处理 DNS 查询时这一点可 能尤其明显. HTTP/2 对压缩的使用 (见 [RFC7540] 第 10.6 节) 和填充的使 用 (见 [RFC7540] 第 10.7 节) 提供了进一步建议. 如果 DoH 客户端在 DNS 查询中请求 DNS 填充, DoH 服务器也可以添加 DNS 填充 [RFC7830]. [RFC8467] 中有一项实验性工作, 用于提供关于如何选择填充长度的指导.

HTTPS 连接为 DoH 服务器与客户端之间的交互提供传输安全, 但它不提供 DNSSEC 为 DNS 数据提供的响应完整性. DNSSEC 和 DoH 是相互独立且完全兼 容的协议, 各自解决不同的问题. 使用其中一个并不会降低另一个的必要性或 有用性. 客户端可以选择自行对答案执行完整的 DNSSEC 验证, 也可以信任 DoH 服务器执行 DNSSEC 验证, 并检查返回消息中的 AD (Authentic Data) bit, 以 判定答案是否真实. 如第 4.2 节所述, 不同响应 media type 会从 DNS 响应中 提供或多或少的信息, 因此这一选择可能会受到响应 media type 的影响.