3. 设计考虑 (Design Considerations)
本节及其子节给出了 DoQ 使用的设计指南. 本文档中的所有其他章节均为规范性内容, 而本节本质上是资料性的.
3.1. 提供 DNS 隐私
DoT [RFC7858] 通过规定如何在 TLS 上传输 DNS 消息, 定义了如何缓解 "DNS Privacy Considerations" [RFC9076] 中描述的一些问题. "Usage Profiles for DNS over TLS and DNS over DTLS" [RFC8310] 为 DoT 指定了 Strict 和 Opportunistic 使用配置文件, 包括桩解析器如何认证递归解析器.
QUIC 连接建立包括使用 TLS 协商安全参数, 如 "Using TLS to Secure QUIC" [RFC9001] 所规定, 从而启用 QUIC 传输加密. 在 QUIC 上传输 DNS 消息将提供与 DoT [RFC7858] 基本相同的隐私保护, 包括 Strict 和 Opportunistic 使用配置文件 [RFC8310]. 第 7 节对此作进一步讨论.
3.2. 面向最低时延设计
QUIC 专门设计用于减少协议引入的延迟, 具有如下特性:
-
在会话恢复期间支持 0-RTT 数据.
-
支持 "QUIC Loss Detection and Congestion Control" [RFC9002] 中指定的高级分组丢失恢复过程.
-
通过允许在多个流上并行交付数据来缓解队头阻塞.
这种 DNS 到 QUIC 的映射会从三个方面利用这些特性:
-
可选支持在会话恢复期间发送 0-RTT 数据 (其安全和隐私影响将在后续章节讨论).
-
在长生命周期 QUIC 连接上执行多个 DNS 事务, 生成利用高级恢复特性所需的持续流量.
-
将每个 DNS 查询/响应事务映射到独立流, 以缓解队头阻塞. 这使服务器能够"乱序"响应查询. 它还使客户端能够在响应到达后立即处理, 而无需等待服务器先前发送的响应按序交付.
这些考虑反映在第 4.2 节中 DNS 流量到 QUIC 流的映射中.
3.3. 中间盒考虑
使用 QUIC 可能允许协议借助加密以及填充、流量节奏控制和流量整形等抗流量分析技术, 向网络路径上的设备隐藏其用途. 本规范不包含任何旨在避免此类分类的措施; 第 5.4 节定义的填充机制旨在混淆 DNS 查询和响应中包含的具体记录, 但并不混淆这是 DNS 流量这一事实. 因此, 防火墙和其他中间盒可能能够将 DoQ 与其他使用 QUIC 的协议 (例如 HTTP) 区分开来, 并施加不同处理.
本规范没有提供避免协议分类的措施, 并不表示认可这类做法.
3.4. 无服务器发起事务
如第 1 节所述, 本文档不规定在已建立的 DoQ 连接内支持服务器发起的事务. 也就是说, 只有 DoQ 连接的发起方可以通过该连接发送查询.
DSO 确实支持在现有连接内进行服务器发起的事务. 然而, 这里定义的 DoQ 不满足 DSO 适用传输的标准, 因为它不保证消息按序交付; 见 [RFC8490] 第 4.2 节.