RFC9250 基于专用QUIC的DNS

摘要

本文介绍了通过QUIC为DNS提供传输保密性的使用方法。QUIC提供的加密类似TLS，但QUIC避免了TCP的队头阻塞问题，并且提供了比UDP更有效的丢包恢复。基于QUIC的DNS（DoQ）的隐私性类似DoT（DNS over TLS，RFC7858），而时延类似基于UDP的经典DNS。本文描述了DoS作为DNS的通用传输的使用，以及在stub解析器到递归解析器、递归解析器到权威解析器、区域传送场景的使用。

1. 介绍

Domain Name System (DNS) 的概念在"域名-概念和设施" [RFC1034]中介绍。DNS基于UDP和TCP的查询发送和回复在"域名– 实现和规范" [RFC1035]中指定。
本文展示了基于QUIC传输（ [RFC9000] [RFC9001]）DNS协议映射。根据“DNS术语”[DNS-TERMS]，基于QUIC的DNS这里称为DoQ。
DoQ映射的目标：
 提供跟DoT [RFC7858]一样的隐私保护。这包括客户端认证服务端的选项，通过“TLS上DNS和DTLS上DNS的使用说明书”[RFC8310]中规定的身份验证域名。
 为DNS服务器提供改进的源地址验证，基于UDP的经典DNS并不支持。
 不影响能发送DNS回复大小的路径MTU限制。
为了达到以上目标，并且支持DNS加密，本文场景包括：
 "stub解析器到递归解析器"场景（本文中也叫"stub到递归"场景）
 "递归解析器到权威名称服务器"场景（本文中也叫"递归到权威"场景）
 “名称服务器到名称服务器”场景（主要用于区域传送XFR [RFC1995] [RFC5936]）

换句话说，本文指定了QUIC作为DNS的通用传输层。
以下各点不是本文的目标：
 没有避免中间件对DoQ流量的潜在阻塞。
 没有支持服务器发起的事务，这些事务仅用于DNS有状态操作（DSO）[RFC8490]。
指定通过QUIC传输应用需要指定应用的消息如何映射到QUIC流，以及应用将如何使用QUIC。HTTP已经完成了相关工作，见 [HTTP/3]。本文目的是定义DNS消息在QUIC上传输的方式。
基于HTTPS的DNS (DoH) [RFC8484] 可以与HTTP/3一起使用，以便从QUIC中受益。然而，DoQ的轻量级直接映射可以被视为更自然地适用于递归到权威和区域传送场景，这两种场景很少涉及中间层。在这些场景中，HTTP的额外开销不会被HTTP代理和缓存行为的好处所抵消。
本文第3节介绍了指导拟议设计的推理。第4节规定了DoQ的实际映射。第5节介绍了DoQ的实现、使用和部署指南。

2. 关键词

3. 设计考虑

本节介绍了用于DoQ的设计指南。虽然本文中的所有其他章节都是规范性的，但本节本质上是信息性的。

3.1. 提供DNS隐私性

DoT [RFC7858]定义了通过TLS传输DNS时怎样解决"DNS隐私考虑" [RFC9076] 中的一些问题。“基于TLS和DTLS的DNS使用规范” [RFC8310] 为DoT规定了严格和机会型的使用规范，包括stub解析器怎样验证递归解析器。
QUIC连接建立包括使用TLS协商安全参数，如"Using TLS to Secure QUIC" [RFC9001]所规定，在QUIC连接上使能加密。在QUIC上传输DNS消息可以提供与DoT [RFC7858] 基本一样的隐私保护，包括严格和机会型使用规范 [RFC8310]。第7章将提供进一步的讨论。

3.2. 最小时延设计

QUIC特别设计了减少协议引发的延迟，特性如下：

1. 会话重建时支持0-RTT数据
2. 支持高级丢包恢复步骤，如“QUIC丢包检测和拥塞控制” [RFC9002]所规定。
3. 通过允许多流并发传输数据缓解了队头阻塞

DNS到QUIC的映射以以下三种方式利用了这些特性：

1. 会话恢复期间0-RTT数据发送的可选支持（后面章节会讨论安全性和隐私性影响）。
2. 执行多DNS事务的QUIC长连接，产生受益于高级恢复功能的持续流量。
3. 将每个DNS查询/响应事务映射到一个单独的数据流，以减轻队头阻塞的情况。这让服务器能够不按顺序响应查询。它还使客户能够在响应到达时立即进行处理，而不必等待服务器先前发布的按序交付相应。
   将DNS流量映射到QUIC流将考虑这些因素。

3.3. 中间件考虑

使用QUIC可能允许协议使用加密和流量分析抵抗技术（如填充、流量节奏和流量整形）对网络路径上的设备掩盖其目的。本规范不包括任何旨在避免这种分类的措施；第5.4节中定义的填充机制旨在混淆DNS查询和响应中包含的具体记录，但不包括这是DNS流量这一事实。因此，防火墙和其他中间件可能会将DoQ与其他使用QUIC的协议（如HTTP）区分开来，并采用不同的处理方法。
本规范中缺乏避免协议分类的措施，并不是对这种做法的认可。

3.4. 没有服务器发起的交易

如第1节所述，本文不支持已建立的DoQ连接中服务器发起的交易。也就是说，只有DoQ连接的发起者可以通过该连接发送查询。
DSO（DNS Stateful Operations）确实支持现有连接中由服务器发起的交易。然而，这里定义的DoQ并不符合DSO适用的传输标准，因为它不能保证消息的有序传递；见[RFC8490] 4.2。

4. 规定

4.1. 连接建立

DoQ连接是按照QUIC传输规范[RFC9000]中的描述建立的。在连接建立期间，DoQ支持通过在加密握手中ALPN令牌"doq"来表示。

4.1.1. 端口选择

默认情况下，支持DoQ 的DNS服务器必须在专用UDP端口853上监听和接受QUIC连接，除非双方协商使用另外端口。
默认情况下，希望在特定服务器上使用DoQ的DNS客户端必须在服务器上的UDP 853端口建立一个QUIC连接，除非双方同意使用其他端口。
DoQ连接决不能使用UDP端口53。这个反对在DoQ中使用端口53的建议是为了避免DoQ和通过UDP使用DNS [RFC1035]之间的混淆。即使双方同意使用53端口，也存在混淆的风险，因为其他各方在不知道该协议的情况下，仍可能尝试使用该端口。
在stub到递归的情况下，使用443端口作为双方同意的替代端口在操作上是有益的，因为443端口被许多使用QUIC和HTTP-3的服务使用，因此比其他端口更不可能被封。Stub解析器发现提供加密传输的递归解析器的几种机制，包括使用的自定义端口，是目前工作的主题。

4.2. 流映射和使用

QUIC流上的DNS流量映射利用了QUIC传输规范[RFC9000]第2节中详述的QUIC流特性。
DNS查询/响应流量[RFC1034][RFC1035]遵循一个简单的模式，即客户端发送一个查询，而服务器提供一个或多个响应（在区域传送中可能出现多个响应）。
这里规定的映射要求客户端为每个查询选择一个单独的QUIC流。然后服务器使用同一流来提供该查询的所有响应信息。为了对多个响应进行解析，使用了一个2字节的长度字段，其方式与通过TCP定义的DNS的2字节长度字段完全相同[RFC1035]。这样做的实际结果是，每个QUIC流的内容与管理一个查询的TCP连接的内容完全相同。
通过DoQ连接发送的所有DNS消息（查询和响应）必须被编码为2字节的长度字段，然后是[RFC1035]中规定的消息内容。
客户端必须按照QUIC传输规范[RFC9000]，为QUIC连接上的每个后续查询选择下一个可用的客户端发起的双向流。数据包丢失和其他网络事件可能导致查询以不同的顺序到达。服务器应在查询到达时进行处理，否则会造成不必要的延迟。
客户端必须在选定的流上发送DNS查询，并且必须通过STREAM FIN机制表明不会在该流上进一步发送数据。
服务器必须在同一流上发送响应，并且必须在最后一个响应之后通过STREAM FIN机制表明将不会在该数据流上发送进一步的数据。
因此，单个DNS事务消耗单个客户端发起的双向流。这意味着客户端的第一个查询发生在QUIC流0上，第二个查询发生于4上，以此类推（参见[RFC9000] 2.1）。
服务器可以延迟查询的处理，直到在客户端选择的流上出现FIN。
服务器和客户端可以监视“悬空”流的数量。这些是打开的流，其中在实现定义的超时之后未发生以下事件：
 预期的查询或回复还没有被接收到，或者
 预期的查询或回复已经接收到，但没有收到FIN
实现可以规定这样悬空流的上限。如果到了上限，实现可以关闭连接。

4.2.1. DNS消息ID

通过QUIC连接发送查询时，DNS消息ID必须设置为0。DoQ的流映射允许查询和响应之间的明确关联，因此不需要消息ID字段。
这对将DoQ消息代理使用其他传输有影响。例如，代理可能必须管理这样一个事，即DoQ可以在单个连接上支持比TCP上的DNS更多的未完成查询，因为DoQ不受消息ID空间的限制。DoH已存在此问题，建议消息ID为0。
当通过另一传输从DoQ转发DNS消息时，必须根据正在使用的协议规则生成DNS消息ID。通过DoQ从其他传输转发DNS消息时，消息ID必须设置为0。

4.3. DoQ错误码

定义了以下错误代码，用于突然终止流时，作为中止流读取的应用协议错误代码，或用于立即关闭连接：
DOQ_NO_ERROR (0x0)：没有错误。用来表示连接或流需要关闭时，没有错误要发送。
DOQ_INTERNAL_ERROR (0x1)：DoQ实现遇到一个内部错误，无法继续事务或连接。
DOQ_PROTOCOL_ERROR (0x2)：DoQ实现遇到一个协议错误，正在强制中止连接。.
DOQ_REQUEST_CANCELLED (0x3)：DoQ客户端使用这个错误码来表示它想取消一个未完成的事务。
DOQ_EXCESSIVE_LOAD (0x4)：DoQ实现由于负载过大而关闭连接时发送此错误码。
DOQ_UNSPECIFIED_ERROR (0x5)：DoQ实现没有更具体的错误代码的情况下使用它。
DOQ_ERROR_RESERVED (0xd098ea5e)：用于测试的错误码。

注册新错误码见8.4.

4.3.1. 事务取消

在QUIC中，发送STOP_SENDING要求对端停止在流上发送数据。如果DoQ客户端想要取消一个未完成请求，它必须发送QUIC STOP_SENDING，并且应该使用错误码DOQ_REQUEST_CANCELLED。也可以使用依据8.4注册的更具体的错误码。STOP_SENDING请求可以在任何时候发送，但如果服务端已经发送了回复就没有效果了，这时客户端将简单丢弃收到的回复。相应的DNS事务必须放弃。
收到STOP_SENDING的服务器按照[RFC9000] 3.5进行操作。如果服务器收到STOP_SENDING，则不应继续处理DNS事务。
服务器可能会对取消请求的总数或速率加以限制。如果到了上限，服务器可能会关闭连接。在这种情况下，希望帮助客户调试的服务器可能会使用错误代码DOQ_EXCESSIVE_LOAD。在帮助善意客户调试问题和允许拒绝服务攻击者测试服务器防御之间总是有一个权衡；根据情况，服务器很可能选择发送不同的错误代码。
请注意，这种机制为secondaries提供了一种方法，以取消发生在特定流上的单一区域传送，而不必关闭QUIC连接。
如果服务器在客户端发出STREAM FIN之前收到客户端的RESET_STREAM请求，则不得继续处理DNS事务。服务器必须发出RESET_STREAM以表明交易被放弃，除非：
 它已经由于其他原因这样做了，或者
 它已经发送了响应并指示了STREAM FIN。

4.3.2. 事务错误

服务器通常通过在事务流上发送一个DNS响应（或多个响应）来完成事务，包括DNS响应显示DNS错误的情况。例如，应该通过响应代码SERVFAIL来通知客户端服务器故障（SERVFAIL，[RFC1035]）。
如果服务器由于内部错误而无法发送DNS响应，它应该发出一个QUIC RESET_STREAM帧。错误代码应被设置为DOQ_INTERNAL_ERROR。相应的DNS事务必须被放弃。在选择关闭连接之前，客户端可以限制在一个连接上收到的非请求的QUIC RESET_STREAM帧的数量。
请注意，这种机制为primaries提供了一种方法，可以中止发生在特定数据流上的单一区域传送，而不必关闭QUIC连接。

4.3.3. 协议错误

在事务过程中，由于错误的、不完整的或意外的信息，可能会发生其他错误情况。这些情况包括（但不限于）：
 客户端或服务器收到一个消息ID为非零的消息
 客户端或服务器在收到2字节长度字段中的所有字节之前收到STREAM FIN
 客户端在收到所有预期的响应之前收到一个STREAM FIN
 服务器在一个流上收到超过一个查询
 客户端在一个流上收到的响应数量与预期的不同（例如，对一个A记录的查询有多个响应）。
 客户端收到STOP_SENDING请求
 客户端或服务器在发送请求或响应后没有发送预期的STREAM FIN（见4.2）。
 实现收到包含edns-tcp-keepalive EDNS(0)选项的消息[RFC7828]（见5.5.2）。
 客户端或服务器试图打开一个单向的QUIC流
 服务器试图打开由服务器发起的双向QUIC流
 服务器收到0-RTT数据中的"可重放"事务（对于不愿意处理这种情况的服务器，见4.5）。

如果一对端遇到这样的错误条件，会被认为是致命的错误。应该使用QUIC的CONNECTION_CLOSE机制强行中止连接，并且应该使用DoQ错误码DOQ_PROTOCOL_ERROR。在某些情况下，可能会默默地放弃连接，这样做使用的本地资源较少，但会使违规节点的调试工作更加困难。
请注意，对使用上述EDNS(0)选项的限制对通过DoQ代理TCP/DoT/DoH的消息有影响。

4.3.4. 替代错误码

本规范在4.3.1、4.3.2和4.3.3描述了具体的错误码。这些错误码旨在促进对故障和其他事件的调查。新的错误码可以在未来的DoQ版本中定义，或者按照8.4的规定注册。
因为新的错误代码可以不经协商就被定义，所以在意外情况下使用错误码或收到未知的错误码，必须被视为等同于DOQ_UNSPECIFIED_ERROR。
实现者可能希望通过使用本文中未列出的错误代码来测试对错误码扩展机制的支持，或者可能使用DOQ_ERROR_RESERVED。

4.4.连接管理

[RFC9000]的第10章（QUIC传输规范）规定了连接可以通过以下三种方式关闭：
 空闲超时
 立即关闭
 无状态重置

实现DoQ的客户端和服务器应该协商使用空闲超时。闲置超时的关闭是在没有任何数据包交换的情况下进行的，这样可以最大限度地减少协议开销。根据QUIC传输规范[RFC9000] 10.1节，空闲超时的有效值为两端通告值的最小值。5.5.2讨论了设置空闲超时的实际考虑。
客户端应该监控与服务器连接的空闲时间，其定义是自收到服务器的最后一个数据包后所经过的时间。当客户端准备向服务器发送一个新的DNS查询时，应该检查空闲时间是否足够低于空闲计时器。如果是，客户端应该通过现有连接发送DNS查询。如果不是，客户端应该建立一个新的连接并通过该连接发送查询。
客户端可以在空闲超时之前放弃与服务器的连接。有未完成查询的客户端应使用QUIC的CONNECTION_CLOSE机制和DoQ错误代码DOQ_NO_ERROR明确关闭连接。
客户端和服务器可能会因为其他各种原因关闭连接，并使用QUIC的CONNECTION_CLOSE表示。通过被其对端丢弃的连接发送数据包的客户端和服务器可能会收到无状态重置指示。如果一个连接失败，该连接上的所有正在进行的事务必须被放弃。

4.5. 会话恢复和0-RTT

如果服务器支持 QUIC [RFC9000] 和QUIC TLS [RFC9001]的会话恢复和 0-RTT 机制，则客户可以利用这些机制。客户端在决定使用该机制之前应考虑与会话恢复相关的潜在隐私问题，并具体评估本文各部分提出的权衡。隐私问题在7.1和7.2中详细说明，而实施方面的考虑则在5.5.3中讨论。
0-RTT机制决不能用于发送不属于"可重放"事务的DNS请求。在本规范中，只有OPCODE为QUERY或NOTIFY的事务才认为是可重放的；因此，其他OPCODES决不能在0-TT数据中发送。关于为什么NOTIFY被包括的详细讨论，请参见附录 A。
服务器可以支持会话恢复，并且可以使用[RFC9001] 4.6.1中描述的机制，在支持或不支持0-RTT的情况下进行恢复。支持0-RTT的服务器不得立即处理在0-RTT数据中收到的不可重放的事务，而是必须采用以下行为之一：
 按照[RFC9001] 4.1.1的定义，对违规事务进行排队，并仅在QUIC握手完成后进行处理。
 使用[RFC6891]中定义的扩展RCODE机制和[RFC8914]中定义的扩展DNS错误，以响应码REFUSED和扩展DNS错误码（EDE）"Too Early"回复违规事务；见8.3节。
 以错误码DOQ_PROTOCOL_ERROR关闭连接。

4.6. 消息大小

DoQ查询和响应是在QUIC流上发送的，理论上最多可以携带262 字节。然而，DNS消息在实践中被限制在65535字节内。这个最大尺寸是通过在DNS over TCP[RFC1035]和DoT[RFC7858]中使用2字节的消息长度字段，以及为DoH[RFC8484]定义的 "application/dns-message"来执行的。DoQ也执行同样的限制。
DNS的扩展机制（EDNS(0)）[RFC6891]允许对端指定UDP消息的大小。这个参数被DoQ所忽略。DoQ的实现总是假设消息大小上限是65535字节。

5. 实现要求

5.1. 认证

对于stub到递归的场景，认证要求与 DoT [RFC7858] 和 “DNS over TLS 和DTLS 的使用规定” [RFC8310] 中描述的相同。[RFC8932]指出，DNS隐私服务应提供客户端可用于验证服务器的凭证。鉴于此，为了与 DoH 的认证模型保持一致，DoQ stub应遵循严格的使用规定。任何DNS RFC中都没有描述加密stub到递归场景的客户认证。
对于区域传送，认证要求与 [RFC9103] 中描述的相同。
对于递归到权威的场景，认证要求在编写本文时没有明确指定，是DPRIVE工作组正在进行的工作主题。

5.2. 连接失败回退到其他协议

如果DoQ连接建立失败，客户可能会试图退回到DoT，然后可能是明文，如DoT [RFC7858]和"DNS over TLS和DTLS的使用规定"[RFC8310]中规定的，取决于他们的使用规定。
DNS客户端应该记住不支持DoQ的服务器IP地址。移动客户端也可能在每个环境下（例如，每个网络或供应域）通过给定的IP地址记住不支持DoQ的情况。
超时、连接拒绝和QUIC握手失败都表明服务器不支持DoQ。客户端不应该一段时间内（例如每个服务器一小时）向不支持DoQ的服务器进行DoQ查询（即必须在超过特定时间后才能进行DoQ尝试）。遵循out-of-band key-pinned使用规范[RFC7858]的DNS客户端在DoQ连接失败后可能会更积极地进行重试。

5.3. 地址验证

QUIC传输规范[RFC9000]的第8章定义了地址验证过程，以避免服务器被用于放大攻击。DoQ实现必须符合该规范，该规范将最坏情况下的放大率限制为系数3。
DoQ实现应考虑将服务器配置为使用QUIC传输规范[RFC9000] 8.1.2中定义的使用重试包的地址验证过程。该过程对验证客户端源地址的返回路由性施加了1-RTT延迟，类似于DNS Cookies机制[RFC7873]。
使用重试包配置地址验证的DoQ实现应实现QUIC传输规范[RFC9000] 8.1.3中定义的未来连接的地址验证程序。这定义了服务器在客户地址被验证后向客户发送NEW_TOKEN帧，以避免客户从同一地址进行后续连接时的1-RTT惩罚。

5.4. 填充

实施方案必须通过明智地注入填充来防止7.5中描述的流量分析攻击。这可以通过使用EDNS(0)填充选项[RFC7830]对单个DNS消息进行填充或对QUIC数据包进行填充来实现（见[RFC9000] 19.1）。
理论上，在QUIC层面上的填充可以带来更好的等效保护性能，因为填充量可以考虑到非DNS帧，如确认或流量控制更新，也因为QUIC可以携带多个DNS消息。然而，只有当QUIC的实现暴露出足够的API时，应用程序才能控制QUIC数据包中的填充量。这导致了以下建议：
 如果QUIC的实现暴露了设置填充策略的API，DoQ应该使用该API将数据包长度调整为一些固定的尺寸。
 如果QUIC级别的填充不可用或不使用，DoQ必须确保所有DNS查询和响应被填充为一些固定尺寸，使用[RFC7830]中规定的EDNS(0)填充扩展。
如果使用适用于其他加密传输的现有DNS消息填充逻辑明显更简单，那么实现者可能选择不使用QUIC API进行填充。
在没有关于填充大小的标准规定情况下，实施者应遵循实验状态"DNS扩展机制的填充规定（EDNS(0)）"的建议 [RFC8467]。这些建议虽然是试验性的（是为DoT实施和部署的），可以为实施者提供了一种完全符合本规范的方法。

5.5. 连接处理

“TCP上的DNS传输–实施要求”[RFC7766]提供了关于TCP上的DNS的最新指导，其中一些适用于DoQ。本节就DoQ的连接处理提供了类似的建议。

5.5.1. 连接拒绝

众所周知，DNS客户端的历史实现是为每个DNS查询打开和关闭TCP连接。为了摊薄连接建立成本，客户和服务器都应该支持连接重用，在一个持久的QUIC连接上发送多个查询和响应。
为了实现与UDP相同的性能，DNS客户应该通过QUIC连接上的流同时发送查询。也就是说，当DNS客户端通过QUIC连接向服务器发送多个查询时，不应该在发送下一个查询之前等待一个未完成的回复。

5.5.2. 资源管理

正确管理已建立的和空闲的连接对DNS服务器的健康运行非常重要。
DoQ的实现应遵循与TCP上的DNS[RFC7766]类似的最佳实践，特别是在以下方面：
 并发连接（[RFC7766] 6.2.2，由[RFC9103] 6.4更新）
 安全考虑因素（[RFC7766]第10章）

不这样做可能会导致资源耗尽和拒绝服务。
希望维持DoQ长连接的客户端应该使用QUIC传输规范[RFC9000] 10.1中定义的空闲超时机制。客户端和服务器不得在DoQ连接上发送的任何消息中发送edns-tcp-keepalive EDNS(0)选项[RFC7828]（因为它是针对使用TCP/TLS作为传输方式的）。
本文没有对空闲连接的超时值做出具体建议。客户端和服务器应该根据可用资源情况来重新使用和/或关闭连接。在活动少的时期，超时可能更长，在活动多的时期，超时可能更短。

5.5.3. 使用0-RTT和会话恢复

为DoQ使用0-RTT有许多优势。客户端可以在不产生连接延迟的情况下建立连接和发送查询。因此，服务器可以协商低值的连接定时器，这就减少了他们需要管理的连接总数。他们可以这样做是因为如果查询需要新的连接，使用0-RTT的客户端不会产生延迟惩罚。
会话恢复和0-RTT数据传输会产生隐私风险，详见7.1和7.2。下面的建议是为了减少隐私风险，同时享受0-RTT数据的性能优势，但要遵守4.5规定的限制。
如[RFC8446]的附录C.4所规定，客户端应该只使用一次恢复令牌。默认情况下，如果客户端的连接发生了变化，客户端不应该使用会话恢复。
客户端可以使用NEW_TOKEN机制从服务器接收地址验证令牌；见[RFC9000]第8章。相关的跟踪风险在7.3中提到。客户端应该只在会话恢复时使用地址验证令牌，从而避免额外的跟踪风险。
服务器应该发布具有足够长的寿命（例如6小时）的会话恢复令牌，这样客户就不会被要求保持连接或频繁地轮询服务器以更新会话恢复令牌。服务器应该实现[RFC8446]第8节中规定的防重放机制。

5.5.4. 控制连接迁移以保护隐私

DoQ实现可以考虑使用[RFC9000]第9节中定义的连接迁移功能。这些特性使连接能够在客户端的连接变化时继续运行。正如7.4中所述，这些功能以隐私为代价换取延迟。默认情况下，客户端应该被配置为优先考虑隐私，并在其连接变化时启动新的会话。

5.6. 并行处理查询

正如 [RFC7766] "TCP上的DNS传输–实施要求 "的第7节所规定的，建议解析器支持并行地准备响应，且不按顺序发送。在 DoQ中，通过尽快在特定流上发送响应来做到这一点，而不需要等待先前打开流响应的可用性。

5.7. 区域传送

[RFC9103]规定了TLS（XoT）上的区域传送，包括对[RFC1995]（IXFR）、[RFC5936]（AXFR）和[RFC7766]的更新。其中描述的与重用XoT连接有关的考虑因素类似地适用于使用DoQ连接进行的区域传送。重申这种具体指导的原因之一是目前现有的TCP/TLS区域传送实现中缺乏有效的连接重用。以下建议适用：
 DoQ服务器必须能够在一个QUIC连接上处理多个并发的IXFR请求。
 DoQ服务器必须能够在一个QUIC连接上处理多个并发的AXFR请求。
 DoQ的实现应该：
 对同一主站的AXFR和IXFR请求使用相同的QUIC连接
 一旦这些请求被排队，就立即并行发送，即在连接上发送下一个查询之前不等待响应（这类似于TCP/TLS连接上的流水线请求）
 在每个请求可用时立即发送响应，即响应流可以混合发送。

5.8. 流控机制

服务器和客户端使用[RFC9000] 4节中定义的机制管理流量控制。这些机制允许客户和服务器指定可以创建多少个流，在一个流上可以发送多少数据，以及在所有流上可以发送多少数据。对于DoQ来说，控制创建多少个流允许服务器控制客户端在一个给定的连接上可以发送多少个新请求。
流控的存在是为了保护端点资源。对于服务器来说，全局和每个流的流量控制限制控制了客户端可以发送多少数据。同样的机制允许客户端控制服务器可以发送多少数据。太小的值会不必要地限制性能。太大的值可能会使端点面临过载或内存耗尽的问题。实施或部署将需要调整流量控制限制，以平衡这些问题。特别是，区域传送的实现将需要仔细控制这些限制，以确保大型和并发的区域传送都得到良好的管理。
参数的初始值控制客户端和服务器在连接开始时可以发送多少请求和多少数据。这些值是在连接握手期间交换的传输参数中指定的。在初始连接中收到的参数值也控制着客户端在恢复连接时使用0-RTT数据可以发送多少请求和多少数据。使用太小的初始参数值会限制0-RTT数据的作用。

6. 安全考虑

域名系统的威胁分析可在[RFC3833]中找到。该分析是在 DoT、DoH 和 DoQ 发展之前写的，可能需要更新。
DoQ 的安全考虑应与DoT [RFC7858]的考虑相当。[RFC7858]中规定的DoT只涉及stub到递归的情况，但是关于中间人攻击、中间件和明文连接的数据缓存的考虑也适用于DoQ到解析器到权威服务器的情况。如5.1所述，使用DoQ保证区域传送安全的认证要求与通过DoT进行区域传送的要求相同；因此，一般的安全考虑因素与[RFC9103]中描述的完全类似。
DoQ依赖于QUIC，QUIC依赖于TLS 1.3，因此默认支持[BCP195]中描述的针对降级攻击的保护措施。QUIC的具体问题及其缓解措施在[RFC9000]第21节中描述。

7. 隐私考虑

“DNS隐私考虑”[RFC9076]中提供的加密传输一般考虑因素适用于DoQ。那里提供的具体考虑因素对于DoT和DoQ没有区别，在此不作进一步讨论。同样，“对 DNS隐私服务运营商的建议”[RFC8932]（涵盖DNS隐私服务的操作、策略和安全考虑）也适用于 DoQ 服务。
QUIC纳入了TLS 1.3 [RFC8446]的机制，这使得QUIC可以传输0-RTT数据。这可以提供有趣的延迟收益，但也引发了两个问题：

1. 攻击者可以重放0-RTT数据并从接收服务器的行为中推断其内容。
2. 0-RTT机制依赖于TLS会话恢复，可以关联连续的客户端会话。
   这些问题将在第7.1和7.2节中展开。

7.1. 0-RTT数据的隐私问题

0-RTT数据可以被对手重放。该数据可能触发递归解析器对权威解析器的查询。对手可能会挑选一个可以观察到递归解析器出站流量的时间，从而找出在0-RTT数据中查询的名称。
这种风险实际上是"DNS隐私考虑"[RFC9076]中讨论的观察递归解析器行为的一般问题的一个子集。通过减少该流量的可观察性，可以部分缓解该攻击。TLS 1.3 [RFC8446]中的强制重放保护机制限制了重放的风险，但并没有消除重放的风险。0-RTT数据包只能在一个窄窗内被重放，这个窗口的宽度只够时钟偏移和网络传输的变化。
TLS 1.3 [RFC8446]的建议是，使用0-RTT数据的能力应该默认关闭，只有在用户清楚地了解相关风险的情况下才可以启用。在DoQ的情况下，允许0-RTT数据提供了显著的性能提升，人们担心不使用它的建议会被简单地忽略。相反，在4.5和5.5.3中提供了一套实用的建议。
4.5中的规范阻止了最明显的重放攻击的风险，因为它们只允许不会改变服务器长期状态的事务。
上面描述的攻击适用于stub解析器到递归解析器的情况，但是在递归解析器到权威解析器的情况下也可能存在类似的攻击，同样的缓解措施也适用。

7.2. 会话重用的隐私问题

QUIC会话恢复机制降低了重新建立会话的成本，使0-RTT数据成为可能。如果相同的恢复令牌被多次使用，就会出现与会话恢复相关的可关联性问题。客户端和服务器之间路径上的攻击者可以观察到令牌的重复使用，并利用这一点在一段时间内或在多个地点跟踪客户端。
会话恢复机制允许服务器将恢复的会话与最初的会话联系起来，从而跟踪客户端。这就创造了一个虚拟的长时会话。该会话中的一系列查询可以被服务器用来识别客户。如果客户的地址保持不变，服务器很可能已经可以做到这一点，但是会话恢复令牌也可以在客户的地址改变后进行跟踪。
5.5.3中的建议是为了减轻这些风险。只使用一次会话令牌可以减轻被第三方跟踪的风险。如果地址发生变化，拒绝恢复会话，可以减轻被服务器追踪的增量风险（但被IP地址追踪的风险仍然存在）。
这里的隐私权衡可能是针对具体环境的。stub解析器将有强烈的动机来选择隐私而不是延迟，因为它们经常改变位置。然而，使用一小部分静态 IP 地址的递归解析器更有可能倾向于会话恢复所提供的低延迟，并且可能认为这是使用恢复令牌的有效理由，即使 IP 地址在会话之间发生变化。
加密的区域传送（[RFC9103]）明确地不试图隐藏参与传输的各方的身份；同时，这种传输对延迟不是特别敏感。这意味着支持区域传送的应用可以决定对递归应用使用与stub相同的保护措施。

7.3. 地址验证令牌的隐私问题

QUIC在[RFC9000]第8章中规定了地址验证机制。使用地址验证令牌允许QUIC服务器避免新连接的额外RTT。地址验证令牌通常与一个IP地址联系在一起。QUIC客户端通常只在从以前使用的地址建立新的连接时使用这些令牌。然而，客户端并不总能意识到正在使用一个新的地址。这可能是由于NAT，或者因为客户端没有可用的API来检查IP地址是否已经改变（对于IPv6来说，这可能是很常见的）。如果客户端在不知情的情况下移动到一个新的地点后错误地使用了地址验证令牌，就会有关联性风险（观察者讲前后两个地址关联起来）。
5.5.3中的建议通过将NEW_TOKEN的使用与会话恢复的使用联系在一起来减轻这种风险，尽管该建议并不包括客户端不知道地址改变的情况。

7.4. 长会话的隐私问题

会话恢复的一个潜在替代方案是使用长会话：即一个会话长时间保持打开，可以在不产生连接建立延迟的情况下发送新的查询。值得指出的是，这两种解决方案具有类似的隐私特征。会话恢复可能允许服务器跟踪客户的IP地址，但长会话也有同样的效果。
特别是，DoQ的实施可能会利用QUIC的连接迁移功能来维持会话，即使客户端的连接发生变化，例如，如果客户端从Wi-Fi连接迁移到蜂窝网络连接，然后迁移到另一个Wi-Fi连接。服务器将能够通过监测长连接所使用的IP地址的连续情况来跟踪客户的位置。
5.5.4中的建议减轻了与使用多个客户端地址的长会话有关的隐私问题。

7.5. 流量分析

尽管QUIC报文是加密的，但对手可以通过观察数据包的长度（包括查询和响应）以及数据包的时间获得信息。许多DNS请求是由网络浏览器发出的。加载一个特定的网页可能需要解析几十个DNS名称。如果应用采用每包一个查询或响应的简单映射，或"每包一个QUIC STREAM帧"，那么连续的数据包长度可能提供足够的信息来识别所请求的网站。
实现应使用5.4中定义的机制来缓解这种攻击。