3. Design Considerations (设计考虑)
本节及其子节介绍了用于 DoQ 的设计指南. 虽然本文档中的所有其他部分都是规范性的, 但本节本质上是信息性的.
3.1. Provide DNS Privacy (提供 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] 基本相同的隐私保护, 包括严格和机会主义使用配置文件 [RFC8310]. 第 7 节对此进行了进一步讨论.
3.2. Design for Minimum Latency (最小延迟设计)
QUIC 专门设计用于减少协议引起的延迟, 具有以下特性:
-
在会话恢复期间支持 0-RTT 数据.
-
支持高级数据包丢失恢复程序, 如 "QUIC Loss Detection and Congestion Control" [RFC9002] 中所规定.
-
通过允许在多个流上并行传输数据来缓解队头阻塞 (head-of-line blocking).
DNS 到 QUIC 的这种映射将通过三种方式利用这些特性:
-
在会话恢复期间可选支持发送 0-RTT 数据 (这方面的安全和隐私影响将在后面的章节中讨论).
-
长期存在的 QUIC 连接, 在其上执行多个 DNS 事务, 生成从高级恢复功能中受益所需的持续流量.
-
将每个 DNS 查询/响应事务映射到单独的流, 以缓解队头阻塞. 这使服务器能够 "无序" 响应查询. 它还使客户端能够在响应到达时立即处理响应, 而无需等待服务器先前发布的响应的有序传递.
这些考虑反映在第 4.2 节中 DNS 流量到 QUIC 流的映射中.
3.3. Middlebox Considerations (中间盒考虑)
使用 QUIC 可能允许协议使用加密和流量分析抵抗技术 (如填充、流量调速和流量整形) 向网络路径上的设备隐藏其目的. 本规范不包括旨在避免此类分类的任何措施; 第 5.4 节中定义的填充机制旨在混淆 DNS 查询和响应中包含的特定记录, 但不是混淆这是 DNS 流量的事实. 因此, 防火墙和其他中间盒可能能够将 DoQ 与使用 QUIC 的其他协议 (如 HTTP) 区分开来, 并应用不同的处理.
本规范中缺乏避免协议分类的措施并不意味着认可此类做法.
3.4. No Server-Initiated Transactions (无服务器发起的事务)
如第 1 节所述, 本文档未指定在已建立的 DoQ 连接中支持服务器发起的事务. 也就是说, 只有 DoQ 连接的发起者可以通过连接发送查询.
DSO 确实支持现有连接中的服务器发起事务. 然而, 此处定义的 DoQ 不符合 DSO 适用传输的标准, 因为它不保证消息的有序传递; 参见 [RFC8490] 的第 4.2 节.