8. 隐私考虑

[RFC7626] 从 "在线路上" (见 [RFC7626] 第 2.4 节) 和 "在服务器中" (见 [RFC7626] 第 2.5 节) 两个语境讨论了 DNS 隐私考虑. 这同样是分析 DoH 隐私考虑时有用的框架.

8.1. 在线路上

DoH 会加密 DNS 流量并要求对服务器进行认证. 这缓解了被动监控 [RFC7258], 也缓解了试图将 DNS 流量转移到恶意服务器的主动攻击 (见 [RFC7626] 第 2.5.1 节). DNS over TLS [RFC7858] 提供类似保护, 而直 接基于 UDP 和 TCP 的传输容易受到这类攻击. [RFC8467] 中有一项实验性 工作, 用于提供关于如何选择填充长度的指导.

此外, 使用 HTTPS 默认端口 443, 以及能够在同一连接上将 DoH 流量与其他 HTTPS 流量混合, 可以阻止无特权的路径上设备干扰 DNS 操作, 并使 DNS 流 量分析更加困难.

8.2. 在服务器中

DNS 线路格式 [RFC1035] 不包含客户端标识符. 但是, DNS 查询和响应的各种 传输方式确实会提供可用于关联请求的数据. HTTPS 为关联带来了新的考虑因 素, 例如显式 HTTP cookie, 以及对 HTTP 请求头部字段的唯一集合和排序进行 隐式指纹识别.

DoH 实现构建在 IP, TCP, TLS 和 HTTP 之上. 每一层都包含一个或多个常见 特性, 可用于将查询关联到同一身份. DNS 传输通常会继承用于实现它们的各 层的隐私属性. 例如, IP, TCP 和 TLS 的属性适用于 DNS over TLS 的实现.

在 DoH 中使用 HTTPS 层所带来的隐私考虑, 是在 DNS over TLS 的隐私考虑 之上的增量. 目前并不知道 DoH 会引入除 HTTPS 相关问题之外的新担忧.

在 IP 层, 客户端地址提供了明显的关联信息. 可以通过 NAT, 代理, VPN 或 随时间进行简单的地址轮换来缓解这一点. 如果 DNS 服务器能够将实时地址信 息与其他个人标识符关联起来, 这一问题可能会加剧, 例如 DNS 服务器和 DHCP 服务器由同一实体运营时.

使用一个 TCP 连接承载多个 DNS 请求的 DNS 实现, 会直接把这些请求归为一 组. 长连接的性能行为优于短连接. 但是, 长连接会聚合更多请求, 这可能向关 联与汇总暴露更多信息. 基于 TCP 的方案也可能通过使用 TCP Fast Open [RFC7413] 来追求性能. TCP Fast Open 使用的 cookie 允许服务器关联 TCP 会话.

基于 TLS 的实现通常通过某种形式的会话恢复机制获得更好的握手性能, 例 如 [RFC8446] 第 2.2 节. 会话恢复为服务器关联多个 TLS 连接提供了直接 机制.

HTTP 的特性集合也可以通过多种不同方式用于识别和跟踪. 例如, Authentication 请求头部字段会显式标识正在使用的配置文件, 而 HTTP cookie 被设计为客户端与服务站点之间的显式状态跟踪机制, 并且经常用作认证机制.

此外, User-Agent 和 Accept-Language 请求头部字段通常会传达关于客户端版 本或区域设置的具体信息. 这有助于内容协商, 也有助于为实现缺陷提供运营 层面的规避方案. 控制缓存的请求头部字段