本文是关于DNS如何使用QUIC的网络规范文档译文，尚未完成翻译，欢迎指正。

本文档描述了如何使用QUIC来为DNS提供传输层上的机密性。QUIC与TLS提供的两种加密间具有相似的特性，但是QUIC传输能够避免TCP传输带来的队头阻塞问题，并且有着比起UDP更高效的丢包恢复机制。基于QUIC的DNS（DoQ）在隐私方面的属性与RFC 7858中定义的基于TLS的DNS（DoT）类似，在延迟方面的特征与传统的基于UDP的DNS类似。本规范描述了如何将DoQ用作一种通用的DNS传输方法，还涉及到如何将DoQ用于存根解析器与递归解析器的交互、递归解析器与权威域名服务器的交互，以及区域传送等场景。

本文是互联网标准追踪文档。

本文产自互联网工程任务组（IETF），已接受公开审查，并由互联网互联网工程指导委员会（IESG）批准出版。更多互联网标准相关信息详见RFC 7841第2章。

关于本文当前状态、勘误及反馈方式等相关信息请移步https://www.rfc-editor.org/info/rfc9250。

版权所有（c）2022 IETF信托及确认为文档作者的个人。保留所有权利。

本文遵守BCP 78及在本文发布之日起生效的IETF信托涉及IETF文档的法律条文（https://trustee.ietf.org/license-info）。请仔细阅读相关条文，因为其描述了你对本文所有的权利及限制。从本文中摘录的代码组件必须包含信托法律条文第4.e章的简版BSD License文件，并且不附带任何该文件所描述的保证。

域名系统（DNS）这一概念是在《域名——概念与基础设施》（详见《RFC1034》）中建立的。《域名——实现与规范》（详见《RFC1035》）则介绍了DNS查询与响应基于UDP和TCP的传输方式。

本文档描述了DNS协议的一种基于QUIC传输（详见《RFC9000》和《RFC9001》）的映射。下文使用DoQ来指代基于QUIC的DNS，这是符合“DNS术语”（详见《DNS-TERMS》）的。

DoQ映射的目标是：

1. 提供与DoT（详见《RFC7858》）一致的DNS隐私保护。这包括为客户端提供一项可选的使用认证域名来验证服务器身份的机制，《基于TLS和DTLS的DNS的配置用例》（详见《RFC8310》）中介绍了这项机制。

2. 比起传统的基于UDP的DNS，为DNS服务器提供经过改进的源地址验证机制。

3. 提供一种不会根据路径MTU来限制DNS响应尺寸的传输方式。

为了达成以上目标，以及支持正在进行的DNS加密方面的工作，本文档讨论的范畴包含：

• “存根解析器与递归解析器交互”场景（本文档中也会称之为“存根与递归”场景）；

• “递归解析器与权威域名服务器交互”场景（本文档中也会称之为“递归与权威”场景）；以及

• “域名服务器与域名服务器交互”场景（主要被用于区域传送（XFR，详见《RFC1995》和《RFC5936》））。

换句话说，本文档将QUIC视作DNS的一种通用传输方式。

以下内容并非本文档的目标：

1. 致力于回避中间设备可能引发的DoQ流量阻塞。

2. 支持由服务器发起的事务，这只会在DNS有状态操作（DSO，详见《RFC8490》）中被用到。

要为基于QUIC的应用制定传输方式，需要规定如何将应用消息映射到QUIC流上，以及指定应用如何使用QUIC。《超文本传输协议版本3（HTTP/3）》（详见《HTTP/3》）中就是这么做的。本文档的意图是定义如何经由QUIC来传输DNS消息。

可以结合使用HTTP/3和经由HTTPS的DNS（DoH，详见《RFC8484》）来利用QUIC的部分优势。然而，直接且轻量的DoQ映射天生更适用于权威性递归和区域传送的场景，这些场景几乎不会牵涉到中间设备。而在这些场景中，HTTP的额外开销并不会因为HTTP代理或缓存行为而被消除。

在本文档中，第3章介绍了本设计是如何成型的。第4章规定了DoQ实际的映射方式。第5章指导了如何实现、使用和部署DoQ。

本文中的关键字“必须（MUST）”、“必须不（MUST NOT）”、“需要（REQUIRED）”、“强烈要求（SHALL）”、“强烈要求不（SHALL NOT）”、“应该（SHOULD）”、“不应该（SHOULD NOT）”、“推荐（RECOMMENDED）”、“不推荐（NOT RECOMMENDED）”、“可以（MAY）”，以及“可选（OPTIONAL）”应理解为BCP 14 《RFC2119》《RFC8174》所描述的，当且仅当它们像本段一样以斜体加粗方式出现的时候。

本章及其子章节介绍了设计DoQ时所遵循的方针。本文档的其他章节都是规范性的，而本章的内容是资料性的。

DoT（详见《RFC7858》）通过规定如何经由TLS来传输DNS消息的方式，针对在《关于DNS隐私的考量》（详见《RFC9076》）中描述的部分攻击，定义了抵御方法。《基于TLS和DTLS的DNS的配置用例》（详见《RFC8310》）中为DoT分别指定了“严格”和“投机”两种配置，其中包括存根解析器如何认证递归解析器。

按照《QUIC-TLS》（详见《RFC9001》）所规定的那样，QUIC连接的建立过程中使用TLS来协商与安全性有关的参数，这使得QUIC传输受到了加密保护。经由QUIC发送DNS消息能从根本上提供与DoT（详见《RFC7858》），无论使用的是“严格”还是“投机”配置（详见《RFC8310》），一致的隐私保护效果。第7章对此进行了深入探讨。

QUIC是专门被设计出来降低由协议引入的延迟的，并且具有以下特性：

1. 在会话恢复期间支持0-RTT数据。

2. 支持高级的丢包恢复机制，《QUIC恢复》（详见《RFC9002》）定义了这种机制。

3. 通过允许在多个流上并行发送数据的方式抵御队头阻塞。

从DNS至QUIC的映射将在三个方面利用以上特性：

1. 在会话恢复期间对于0-RTT数据的可选支持（后续章节讨论了这一点对于安全性和隐私性的影响）。

2. 进行过多次DNS事务的稳定的QUIC连接所产生的持续流量使连接能够从高级的丢包恢复机制中受益。

3. 为了抵御队头阻塞而将每项DNS查询/响应事务映射至一条独立流的做法使得服务器能够“乱序”响应查询。这还使得客户端能够随时处理刚刚抵达的响应，而无需等待服务器发送的前序响应。

这些考量被反映在了第4.2章内从DNS流量到QUIC流的映射中。

利用QUIC可以使得某协议针对网络路径上的设备掩饰自身的目的，方法是对流量进行加密，以及使用填充、流量调速或流量构造等针对流量分析的抵御技术。本规范并不包含任何被设计用于回避中间设备的协议分类的方法；第5.4章中定义的填充机制是为了混淆在DNS查询和响应中包含着的特定记录，而不是掩盖它是DNS流量的事实。因此，防火墙或其他中间设备可能将DoQ与其他使用QUIC的协议，如HTTP，区分开来，然后区别对待。

本规范中缺少回避协议分类的方法并不意味着支持此类做法。

如第1章所述，本文档没有规定如何在已建立的DoQ连接上支持由服务器发起的事务。也就是说，只有DoQ连接的发起者可以经由连接发送查询。

在一条已建立的连接上，DSO不支持由服务器发起的事务。然而，本文定义的DoQ并不满足一种可适用DSO的传输方式的标准，因为它无法保证消息的有序分发；详见《RFC8490》的第4.2章。

DoQ连接是按照QUIC传输规范《RFC9000》来建立的。在连接建立期间，通过在加密握手中选择应用层协议协商（ALPN）词汇doq来表明对DoQ的支持。

默认情况下，支持DoQ的DNS服务器必须在专门的UDP端口853上监听并接受QUIC连接（详见第8章），除非它与客户端约定了使用另一端口。

默认情况下，希望与某特定服务器使用DoQ的DNS客户端必须与服务器的UDP端口853建立QUIC连接，除非它与服务器约定了使用另一端口。

DoQ连接必须不使用UDP端口53。避免为DoQ使用53端口的这项要求是为了防止混淆DoQ与基于UDP的DNS（详见《RFC1035》）。混淆的后果在于即便双方约定使用53端口，也仍然存在不知道这一约定的第三方，它会在该端口试图使用不受支持的协议。

在存根至递归场景中，将443端口用作双方约定的替代端口的做法也许存在益处，因为比起其他端口，443端口被许多QUIC和HTTP/3服务所使用，更不太可能被封锁。一些可被存根服务器用于发现递归服务器的机制尚处在研究过程中，它们能提供加密的传输方式并支持使用自定义端口。

基于QUIC流的DNS流量映射利用了在QUIC传输规范《RFC9000》的第2章中介绍的QUIC流特性。

DNS查询/响应的流量（详见《RFC1034》和《RFC1035》）遵循着简单的模式：由客户端发送一条查询，然后服务器提供一条或多条响应（多条响应会出现在区域传送场景中）。

本文规定的映射需要客户端为每次查询选择一条单独的QUIC流。接着服务器使用同一条流来为该查询提供所有响应消息。为了使得数条响应都能得到解析，会用到一个2字节的长度字段，其用法与在基于TCP的DNS（详见《RFC1035》）中定义的2字节字段完全一致。该操作的作用是使得每条QUIC流的内容与传递单条查询的TCP连接的内容完全一致。

经由DoQ连接发送的所有DNS消息（查询与响应）必须以一个2字节的长度字段加上在《RFC1035》中规定的消息内容的形式构造。

客户端必须为同一条QUIC连接上的连续查询，以符合QUIC传输规范《RFC9000》的形式，接连选择下一条可由客户端发起的双向流。丢包和其他网络事件可能使得查询乱序抵达。服务器应该随时处理刚刚抵达的查询，因为不这么做就会引入不必要的延迟。

客户端必须在所选的流上发送DNS查询，且必须通过流的FIN置位机制来表明它不会再在流上发送更多数据。

服务器必须在同一条流上发送响应，且必须在发送完最后一条响应后通过流的FIN置位机制来表明它不会再在流上发送更多数据。

因此，一次DNS事务会消耗掉一条由客户端发起的双向流。这意味着客户端的首条查询会出现在QUIC流0上，第二条则在流4，以此类推（详见《RFC9000》的第2.1章）。

服务器可以推迟处理查询，直到客户端在所选的流上进行了流的FIN置位。

服务器和客户端可以监视“悬而未决”的流数量。这类流指的是到实现指定的超时时间为止出现了以下事件的开放流：

• 未接收到期望的查询或响应，或

• 接收到了期望的查询或响应，但缺少流的FIN置位。

实现可以对此类“悬而未决”的流数量设置上限。如果数量到达了上限，那么实现可以关闭连接。

在经由QUIC连接发送查询时，DNS消息ID必须被置为0。DoQ的流映射使得查询和响应能够被明确关联起来，因此不需要消息ID字段。

这会影响从其他传输方式或向其他传输方式对DoQ消息进行代理。例如，代理可能不得不考虑到DoQ比起基于TCP的DNS能够支持更多处于进行状态的查询的事实，因为DoQ不会被消息ID空间所限制。这个问题已经在DoH中出现过，其中就推荐将消息ID置为0。

当从DoQ向另一种传输方式转发DNS消息时，必须根据正在使用的协议规则来指定DNS消息ID。当从其他传输方式向DoQ转发DNS消息时，必须将消息ID置为0。

以下错误码被定义出来，它们可以被用于对流突然发起终止的情形，可以在中止对流的读取时被用作应用协议错误码，也可以被用于立即关闭连接的情形。

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章。

QUIC中的停止发送帧能要求对端停止在某条流上的传输。如果DoQ客户端希望取消某正在进行的请求，那么它必须发送QUIC的停止发送帧，并且它应该使用错误码DOQ_REQUEST_CANCELLED。它可以使用一个按第8.4章所述来注册的更准确的错误码。客户端可以随时发送停止发送帧，但是一旦服务器已经将响应发送出来，这个帧就不会产生任何效果，在这种情况下客户端会直接将发送过来的响应丢弃掉。与之相应的DNS事务必须被舍弃。

接收到停止发送帧的服务器要按照《RFC9000》的第3.5章来作出反应。如果服务器接收到了停止发送帧，那么它不应该继续处理DNS事务。

服务器可以对被取消请求的总数或请求被取消的速率施加上限。一旦触及该上限，服务器就可以关闭连接。在这种情况下，愿意帮助客户端调试问题的服务器可以使用错误码DOQ_EXCESSIVE_LOAD。在帮助善意的客户端调试问题与允许拒绝服务攻击者测试服务器的防御能力之间总是需要权衡取舍；根据情况不同，服务器可以选择发送不同的错误码。

注意，这项机制为辅服务器提供了一种不需要关闭QUIC连接就能够取消某条流上的单次区域传送的方法。

如果服务器在客户端进行流的FIN置位前就从客户端处接收到了流重置帧，那么它必须不继续处理DNS事务。服务器必须发送流重置帧，以表明该事务已被舍弃，除非：

• 它已经出于其他理由而发送过该帧了，或

• 它已经将响应发送出去，且对流进行了FIN置位。

正常情况下，服务器通过向事务所在的流发送DNS响应的方式来完成事务，即便DNS响应中表明了某DNS错误。比如，应该通过响应码被置为SERVFAIL的响应来告知客户端有关服务器故障（详见《RFC1035》）的消息。

如果出于某内部错误的原因，服务器无法发送DNS响应，那么它应该发送QUIC的流重置帧。该帧中的错误码应该被置为DOQ_INTERNAL_ERROR。相应的DNS事务必须被舍弃。客户端可以对在同一条连接上意外接收到QUIC流重置帧的次数设置上限，一旦超过就关闭连接。

注意，这项机制为主服务器提供了一种不需要关闭QUIC连接就能够取消某条流上的单次区域传送的方法。

其他错误可能因为事务中畸形、不完整或意料外的消息而发生。这包括（但不限于）：

• 客户端或服务器接收到了消息ID非零的消息

• 客户端或服务器在接收完由2字节的长度字段指定的完整消息数据前就接收到了流的FIN置位

• 客户端在接收到所有应该收到的响应前就遇到了流的FIN置位

• 服务器在一条流上接收到了多条查询

• 客户端在一条流上接收到的响应数量与预期不同（例如，对A记录的查询出现了数条响应）

• 客户端接收到了停止发送帧

• 客户端或服务器没有在发送完请求或响应后对流进行FIN置位（详见第4.2章）

• 实现接收到了包含着EDNS(0)选项edns-tcp-keepalive（详见《RFC7828》）的消息（详见第5.5.2章）

• 客户端或服务器企图打开单向的QUIC流

• 服务器企图发起一条双向QUIC流

• 服务器在0-RTT数据中接收到了“可重放”的事务（但服务器不愿意处理这种情况，详见第4.5章）

如果对端表现出了此类错误行为，那么终端会将此认为是致命的错误。它应该使用QUIC的连接关闭帧机制来强行中止连接，并且应该使用DoQ错误码DOQ_PROTOCOL_ERROR。在某些情况下，它可以静默地舍弃该连接，这种做法占用的本地资源更少，但是使得出错的对端处的调试变得更加困难。

注意，上述对于EDNS(0)选项的限制会影响从TCP/DoT/DoH向DoQ对消息进行代理。

本规范在第4.3.1章、第4.3.2章和第4.3.3章中介绍了专用的错误码。这些错误码是为了向故障及其他意外情况的调试提供依据。将来版本的DoQ可能定义新的错误码，也可以按照第8.4章中的规定来注册新错误码。

由于无需协商就可以定义新的错误码，如果接收到了未知的或意料外的错误码，那么就必须将它们被视作错误码DOQ_UNSPECIFIED_ERROR。

实现可以通过使用本文档未列出的错误码来测试对错误码扩展机制的支持，也可以使用错误码DOQ_ERROR_RESERVED。

QUIC传输规范《RFC9000》的第10章规定，可以使用以下三种方法关闭连接：

• 空闲超时

• 立即关闭

• 无状态重置

实现DoQ的客户端和服务器应该对空闲超时的值进行协商。因空闲超时而关闭连接时无需数据包通信，这最小化了协议开销。按照QUIC传输规范《RFC9000》的第10.1章所述，空闲超时的有效值为两侧终端宣告的值中较小的那个。第5.5.2章中讨论了在实际设置空闲超时时的考量。

客户端应该监视它与服务器间的连接的空闲时长，该时长的定义为从最后一次接收到来自服务器的数据包起所经过的时间。当客户端准备向服务器发送新的DNS查询时，它应该检查当前的空闲时长是否低于空闲计时器的设置值。如果是，那么客户端**应该通过现有的连接来发送DNS查询。否则，客户端应该建立一条新连接并通过此连接来发送查询。

客户端可以在临近空闲超时时舍弃它与服务器间的连接。若客户端尚有正在进行中的查询，那么它应该主动使用QUIC的连接关闭帧机制来关闭连接，并在帧中使用DoQ错误码DOQ_NO_ERROR。

客户端和服务器可以出于其他各种理由，使用QUIC的连接关闭帧来关闭连接。使用已被对端舍弃的连接来发送数据包的客户端和服务器可能会接收到无状态重置。如果连接出现故障，那么该连接上所有尚未完成的事务都必须被舍弃。

如果服务器支持，那么客户端可以将QUIC传输《RFC9000》和QUIC-TLS《RFC9001》所支持的会话恢复和0-RTT机制利用起来。客户端在决定使用会话恢复机制前应该考虑到与之相关的潜在的隐私方面的问题，并且仔细权衡本文档各章节中描述的利弊。第7.1章和第7.2章详述了隐私方面的问题，而第5.5.3章中讨论了关于实现的考量。

必须不使用0-RTT机制来发送并非“可重放”事务的DNS请求。在本规范中，只有OPCODE（操作码）为QUERY或NOTIFY的事务才是可重放的；因此，必须不在0-RTT数据中发送其他OPCODE。有关此处为何包含了NOTIFY的详细讨论，详见附录A。

服务器可以支持会话恢复，与此同时可以支持或不支持0-RTT，《RFC9001》的第4.6.1章中描述了0-RTT机制。在接收到0-RTT数据中的不可重放的事务时，支持0-RTT的服务器必须不立即处理它们，而是必须选择以下行为之一来操作：

• 将不可重放的事务排入队列，并在完成QUIC握手后再处理它们，详见《RFC9001》的第4.1.1章。

• 按照在《RFC6891》中定义的扩展的RCODE机制和在《RFC8914》中定义的扩展的DNS错误，使用响应码REFUSED和扩展的DNS错误码Too Early来响应不可重放的事务；详见第8.3章。

• 使用错误码DOQ_PROTOCOL_ERROR来关闭连接。

DoQ查询和响应是在QUIC流上发送的，理论上可以携带至多262字节的数据。然而在实践中，DNS消息的最大尺寸被限制为65535字节。该最大尺寸是根据基于TCP的DNS（详见《RFC1035》）和DoT（详见《RFC7858》）中2字节的消息长度字段，以及DoH（详见《RFC8484》）的application/dns-message定义而得到的。DoQ使用与它们相同的最大尺寸。

《DNS的扩展机制（EDNS(0)）》（详见《RFC6891》）允许对端指定UDP消息的尺寸。该参数会被DoQ忽略。DoQ实现总是假定消息的最大尺寸为65535字节。

对于存根至递归场景，关于认证的要求与DoT（详见《RFC7858》）和《基于TLS和DTLS的DNS的配置用例》（详见《RFC8310》）中所述的一致。《RFC8932》中指出，DNS隐私服务应该向客户端提供用于验证服务器身份的凭据。基于这一点，同时为了与DoH的认证模型一致，DoQ存根服务器应该选用“严格”配置。没有任何关于DNS的RFC提到过在受到加密保护的存根至递归场景下的客户端认证。

对于区域传送场景，关于认证的要求与《RFC9103》中所述的一致。

对于递归至权威场景，关于认证的要求尚未制定，它是工作草案《DNS PRIVate Exchange (DPRIVE)》的内容。

如果DoQ连接的建立失败了，那么客户端可以尝试回退至DoT，再接着按照DoT（详见《RFC7858》）和《基于TLS和DTLS的DNS的配置用例》（详见《RFC8310》）的规定，根据其配置回退至明文传输。

DNS客户端应该记住不支持DoQ的服务器的IP地址。移动端的客户端还可以按照场景（例如，根据网络类型或所用的域名）来记忆不支持DoQ的IP地址。

超时、连接受拒，以及QUIC握手的失败都是服务器不支持DoQ的依据。在一段合理的时间内（例如对每台服务器设置一小时的时长），客户端不应该向不支持DoQ的服务器尝试DoQ查询。遵循使用带外数据固定密钥配置（详见RFC7858）的DNS客户端可以在经历DoQ连接失败后更激进地发起重试。

为了避免服务器被用于地址放大攻击，QUIC传输规范《RFC9000》的第8章定义了地址验证的流程。DoQ实现必须遵从该规范，它能将最坏情况下的放大系数限制至3。

DoQ实现应该考虑将服务器配置为使用QUIC传输规范《RFC9000》的第8.1.2章中定义的重试数据包流程来进行地址验证。该流程向客户端源地址的回程可达性验证增加了一个单次往返时间的延迟，这与DNS Cookies机制（详见《RFC7873》）的效果类似。

将地址验证配置为使用重试数据包的DoQ实现应该实现定义在QUIC传输规范《RFC9000》的第8.1.3章中的适用于未来连接的地址验证流程。它定义了服务器在验证完客户端地址后如何向客户端发送新令牌帧，为的是在来自相同地址的客户端发起后续连接时减少一个单次往返时间的延迟。

实现必须通过巧妙地注入填充数据的方式抵御第7.5章中描述的流量分析攻击。这可以通过使用EDNS(0)的填充选项（详见《RFC7830》）来填充单条DNS消息或通过填充QUIC数据包（详见《RFC9000》的第19.1章）的方式来做到。

理论上，在QUIC数据包层面的填充可以在达到相同保护效果的前提下取得更好的性能，因为填充的数据量会考虑到非DNS帧的数据，例如确认或流量控制的更新，还因为QUIC数据包能够携带多条DNS消息。然而，只有在QUIC实现提供了合适的API，应用才能控制QUIC数据包中的填充量。这引出了以下推荐做法：

• 如果QUIC实现提供了能够设置填充策略的API，那么DoQ应该使用此API来将数据包尺寸对齐至少数的固定尺寸。

• 如果QUIC数据包层面的填充是不可用的或未使用的，那么DoQ必须使用《RFC7830》中规定的EDNS(0)的填充扩展来确保所有DNS查询和响应都被填充至少数固定尺寸

如果重用现有的用于其他加密传输方式的DNS消息填充逻辑更为简单，那么实现可以选择不使用QUIC的API来填充。

在缺少填充尺寸标准的情况下，实现应该遵循处于试行（Experimental）状态《针对DNS扩展机制（EDNS(0)）的填充策略》（详见《RFC8467》）中的推荐做法。尽管处于试行状态，但本文还是引用了其中的推荐做法，因为它们是为DoT实现和部署的，且提供了与本规范完全兼容的实现方法。

《基于TCP的DNS传输——对实现的要求》（详见《RFC7766》）为基于TCP的DNS提供了经过更新的指导，其中部分内容适用于DoQ。本节为DoQ对连接的处理提供了类似的建议。

知名的DNS客户端实现都为每条DNS查询打开和关闭专门的TCP连接。为了抵消连接建立时的开销，客户端和服务器都应该以在一条持续的QUIC连接上多次发送查询与响应的方式支持连接的重用。

为了达到与UDP同等的性能，DNS客户端应该经过同一条QUIC连接上的多个QUIC流并发地发送其查询。也就是说，当DNS客户端经由QUIC连接向服务器发送多条查询时，它在发送下一条查询前不应该为尚未接收到的响应而等待。

能否恰当地管理已建立的和空闲的连接对于DNS服务器的健康运行非常重要。

DoQ实现应该遵循与为基于TCP的DNS（详见《RFC7766》）而规定的最佳实践类似的做法，特别是：

• 并发的连接（详见《RFC7766》的第6.2.2章，及《RFC9103》的第6.4章中的更新内容）

• 关于安全性的考量（详见《RFC7766》的第10章）

不这么做可能导致服务器的资源被耗尽并拒绝服务。

想要维持长时间DoQ连接的客户端应该使用QUIC传输规范《RFC9000》的第10.1章中定义的空闲超时机制。客户端和服务器在任何消息中都必须不发送EDNS(0)选项edns-tcp-keepalive（因为它的使用仅限于使用TCP/TLS作为传输协议的情况，详见《RFC7828》）。

本文档没有为空闲连接的超时时间做出推荐。客户端和服务器应该根据可用资源的水平重用和/或关闭连接。在网络活动较少的时期，超时时间可以变长，较多的时期则变短。

为DoQ使用0-RTT具有强大的优势。客户端无需受到连接延迟的影响就能够建立连接并发送查询。因此服务器可以为连接计时器协商一个较低的值，这能减少它们需要管理的连接总数。之所以服务器可以这么做，是因为使用0-RTT的客户端在为新查询建立连接时不会受到连接延迟的影响。

会话恢复和0-RTT数据的传输会带来隐私上的风险，第7.1章和第7.2章中详述了这一点。以下推荐做法是为了在降低隐私上的风险的同时利用0-RTT数据带来的性能提升，它们受到第4.5章所述限制的制约。

按照《RFC8446》的附录C.4所述，客户端应该一次性地使用会话恢复票据。默认情况下，如果客户端的连接环境发生了变化，那么就不应该使用会话恢复。

通过新令牌帧机制，客户端可能从服务器处接收到地址验证令牌；详见《RFC9000》的第8章。第7.3章中提及了受到对这种关联进行的追踪的风险。客户端应该仅在使用了会话恢复时才使用地址验证令牌，从而避免额外的受到追踪的风险。

服务器应该为签发的会话恢复票据设置足够长的有效期（例如，6小时），以使得客户端既不会尝试维持连接也不会频繁地向服务器要求更新会话恢复票据。服务器应该实现《RFC8446》的第8章中规定的抗重放机制。

DoQ实现可以考虑使用《RFC9000》的第9章中定义的连接迁移特性。这些特性使得连接能随着客户端连接环境的变化而继续运行。如第7.4章所述，这些特性为了低延迟而牺牲了隐私。默认情况下，应该将客户端配置为以隐私为优先，在连接环境变化时启用新会话。

正如《基于TCP的DNS传输——对实现的要求》（详见《RFC7766》）的第7章所述，推荐解析器支持并行地为响应进行准备，且发送响应时无需按照顺序。在DoQ中，服务器的做法是尽可能快地将响应在各自的流上发送，而不需要按顺序准备响应。

《RFC9103》定义了基于TLS的区域传送（XoT），并且包含着对于《RFC1995》（IXFR）、《RFC5936》（AXFR）和《RFC7766》的更新。其中介绍的有关XoT连接重用的考量可以被类似地应用到使用DoQ连接实现的区域传送上。重申这些规范的原因之一是当前的TCP/TLS区域传送实现均缺乏有效的连接重用机制。以下为推荐做法：

• DoQ服务器必须有能力处理在单条QUIC连接上的并发的IXFR请求。

• DoQ服务器必须有能力处理在单条QUIC连接上的并发的AXFR请求。

• DoQ实现应该

  • 为指向同一台主服务器的AXFR和IXFR请求使用同一条QUIC连接。

  • 一旦这些请求进入队列，就立即并行地发送它们，也就是说，在连接上发送下一条请求前不会等待响应的抵达（这与TCP/TLS连接上的流水线请求类似）。

  • 一旦响应抵达，就立即发送它们，也就是说，可以乱序发送响应流。

服务器和客户端使用《RFC9000》的第4章中定义的机制来进行流量控制。这些机制使得客户端和服务器能够指定流的最大创建数量、单条流上发送的最大数据量，以及在所有流上发送的最大数据总量。对于DoQ来说，控制流的最大创建数量使服务器得以控制客户端能够在给定连接上发送的新请求数量。

流量控制的出现是为了保护终端的资源。对于服务器来说，全局性的和单条流上的流量控制上限能够调整客户端能够发送的数据量。该机制还使得客户端能够控制服务器发送的数据量。过小的值将不必要地限制性能。过大的值可能使终端暴露于过载或内存耗尽的风险之中。实现或部署需要调整流量控制上限从而平衡这些问题。特别是，区域传送的实现需要小心地控制这些限制值以确保巨大且并发的区域传送能够得到妥善处理。

在连接起始时的参数的初始值控制了客户端和服务器能够发送多少请求和数据。这些值是在连接握手期间交换的传输参数中指定的。在初次连接中接收到的参数值还控制了使用0-RTT数据的客户端在恢复的会话中能够发送多少请求和数据。为这些参数使用过小的值将限制0-RTT数据的使用效果。

《RFC3833》中可以找到对于域名系统的威胁分析。这份分析写于DoT、DoH和DoQ的开发之前，可能需要更新。

DoQ在安全性方面的考量应该与DoT（详见《RFC7858》）中的考量相当。《RFC7858》中定义的DoT仅讨论了存根至递归场景，但是有关中间人攻击、中间设备，以及来自明文连接的数据缓存的考量同样适用于DoQ的递归至权威场景。正如第5.1章指出的那样，对于保护使用DoQ的区域传送的认证要求与基于DoT的区域传送的要求一致；因此，安全性上的一般考量与《RFC9103》中描述的考量完全类似。

DoQ依赖于QUIC，后者依赖于TLS1.3，且默认支持对《BCP195》中描述的降级攻击进行抵御。《RFC9000》的第21章介绍了特定于QUIC的问题及其抵御方法。

在《关于DNS隐私的考量》（详见《RFC9076》）中提供的对于加密传输通用的考量对DoQ是适用的。其中提供的几点的考量并不区分DoT还是DoQ，这里不再赘述。类似地，《有关DNS隐私服务操作符的推荐》（详见《RFC8932》，它涵盖了DNS隐私服务的可操作性、策略，及其安全方面的考量）同样适用于DoQ服务。

QUIC内部使用的是TLS 1.3（详见《RFC8446》）的机制，这使得QUIC能够传输“0-RTT”数据。它在延迟方面能提供吸引人的收益，但是它引发了两点担忧：

• 攻击者可以重放0-RTT数据，并从接收到数据的服务器的行为中推断数据内容。

• 0-RTT机制依赖于TLS的会话恢复特性，这使得客户端相继的数次会话被关联起来。

第7.1章和第7.2章中展开讨论了这些问题。

0-RTT数据可能被攻击者重放。此数据可能触发递归解析器向权威解析器的查询。攻击者可能可能挑选一个方便观察递归解析器传出流量的时间，从而找出它为0-RTT数据查询的那个域名。

此风险的本质是在《关于DNS隐私的考量》（详见《RFC9076》）中讨论的递归解析器行为观察问题的子集。该攻击可以通过降低此流量的可观察性来部分抵御。在TLS 1.3（详见《RFC8446》）中强制性的重放保护机制能够限制重放的风险，但是无法完全消除。只能在狭窄的时间窗口内重放0-RTT数据包，该窗口的宽度仅足够用来容许时钟偏差和网络传输的波动。

对于TLS 1.3（详见《RFC8446》）的推荐做法是默认情况下禁用0-RTT数据，且仅在用户明确理解相关风险的情况下启用。在DoQ的场景中，允许0-RTT数据能够带来巨大的性能提升，不推荐使用0-RTT数据的要求很有可能会被忽略。相反，第4.5章和第5.5.3章中提供了一系列可实践的推荐做法。

在第4.5章中的规范能够阻挡大多数重放攻击的直接风险，因为它仅允许了不会修改服务器持久数据的事务。

上文描述的攻击适用于存根至递归的场景，但类似地攻击也可以被实行在递归至权威的场景，而该抵御方法仍然适用。

QUIC的会话恢复机制降低了重新建立会话所需的成本，并支持了0-RTT数据。如果同一个恢复令牌被多次使用，那么会出现与会话恢复相关的关联性问题。在客户端与服务器间的路径上的攻击者能够观察到令牌的重复使用，并利用它来将出现在不同时间或不同地区的客户端关联起来。

会话恢复机制使得服务器能够将恢复的会话与初始的会话关联起来从而追踪同一个客户端。它创建了一个虚拟的持久会话。服务器可以使用在该会话中的一系列查询来辨识客户端。当客户端地址保持不变时，服务器总是可以做到这一点，但是会话恢复票据使得这种追踪能够不受客户端地址变化的影响。

在第5.5.3章中的推荐做法被设计用来抵御此类风险。一次性地使用会话票据的做法能够消除被第三方追踪的风险。如果地址发生变化，那么放弃恢复会话能够消除被服务器追踪的增量风险（但仍存在通过IP地址追踪的风险）。

隐私性的利弊可能随场景而变化。存根解析器会有强烈的动机去用延迟换取隐私，因为它们经常改变定位。然而，使用一组少量固定IP地址的递归解析器更有可能选择由会话恢复带来的低延迟，并且即使会话的IP地址发生了变化，也会认为这是使用会话恢复票据的合理理由。

加密的区域传送（详见《RFC9103》）没有试图隐藏与传送有关的各方的身份；同时，这类传送对延迟并不是特别敏感。这意味着支持区域传送的应用可能选择使用与存根至递归场景中的应用类似的保护措施。

QUIC在《RFC9000》的第8章中规定了地址验证机制。地址验证令牌使得QUIC服务器能够在新连接上避免花费额外的往返时间。地址验证令牌经常与IP地址绑定。QUIC客户端通常仅当从曾使用过的地址发起新连接时才使用这些令牌。然而，客户端并不总是注意到它们正在使用新的地址。这可能是NAT的原因，或者因为客户端没有能够用来检查IP地址是否发生变化的API（这经常在IPv6中发生）。如果客户端在无感知的情况下移动到新地址后又错误地使用了地址验证令牌，就会产生关联性问题。

在第5.5.3章中的推荐做法通过将新令牌帧的使用与会话恢复的使用绑定的方法，抵御了这类攻击，尽管该推荐做法没有覆盖到客户端没有感知到地址变化的情况。

会话恢复的潜在替代方案是使用持久会话：如果某会话长时间处于打开状态，那么在发送新查询时就不需要引入建立连接所需的延迟。值得指出的是，这两种方案在隐私方面具有相似的特征。会话恢复可以使得服务器有能力追踪客户端的IP地址，但是持久会话也有相同的效果。

特别是，DoQ实现可能利用QUIC的连接迁移特性从而在客户端的连接环境发生变化时维持会话，例如，客户端从某Wi-Fi连接迁移到蜂窝网络连接，随后又迁移到另一个Wi-Fi连接。服务器将有能力通过监测该持久会话相继使用的IP地址的方式来追踪客户端的位置。

在第5.5.4章中的推荐做法能够消除有关使用多个客户端地址的持久连接的隐私问题。

即便QUIC数据包是受到加密保护的，攻击者仍然可以通过观测查询与响应的数据包长度及耗时的方法获取信息。许多DNS请求都是由网络浏览器触发的。加载某网页可能需要解析十几个域名。如果应用采用了将每次查询或响应映射至一个数据包，或“每个数据包对应一个QUIC流帧”的做法，那么这些连续数据包的长度提供的信息也许足以用来辨识所请求的站点。

实现应该使用第5.4章中定义的机制来抵御此类攻击。

本文档在注册表“TLS应用层协议协商（ALPN）协议ID”（详见《RFC7301》）中为DoQ的标识符创建了一条注册项。

字符串doq标识着DoQ：

协议（Protocol）：

DoQ

标识序列（Identification Sequence）：

0x64 0x6F 0x71（“doq”）

规范（Specification）：

本文档

目前，TCP和UDP的端口853因为《运行于TLS/DTLS上的DNS查询-响应协议》（详见《RFC7858》）而被保留使用。

然而，经由DTLS的DNS（DoQ）的规范（详见《RFC8094》）处于试行状态、仅适用于存根至递归场景，并且据作者所知尚未出现有关实现或部署（即使距离该规范出版已有数年时间）。

本规范为DoQ额外保留了UDP端口853的使用。QUIC版本1被设计为可以在同一端口与其他协议共存，包括DTLS；详见《RFC9000》的第17.2章。这意味着在某端口同时提供DoD和DoQ（基于QUIC版本1）服务的实现将有能力通过UDP载荷的第二最高有效位来将它们解复用。这类部署应该在为了提供DNS服务而将QUIC和DTLS的将来版本或扩展（例如《GREASING-QUIC》）部署到同一端口前对其检查其签名。

IANA已经在“服务名称与传输协议端口号注册表”的系统部分中更新了一下值。该部分的注册项需要得到IETF审查或IESG批准（详见《RFC6335》）。

服务名称（Service Name）：

domain-s

端口号（Port Number）：

853

传输协议（Transport Protocol(s)）：

UDP

指派（Assignee）：

IESG

联系方式（Contact）：

IETF主席

描述（Description）：

运行于DTLS或QUIC上的DNS查询-响应协议

参考文献（Reference）：

《RFC7858》、《RFC8094》、本文档

除此之外，出于连续性和清晰性的考虑，IANA已经将与TCP端口853分配相关项的描述字段更新为“运行于TLS上的DNS查询-响应协议”，并将《RFC8094》从TCP分配项的参考文献字段中移除。

IANA在注册表“扩展的DNS错误码”（详见《RFC8914》）中注册了以下值：

信息码（INFO-CODE）：

26

含义（Purpose）：

过早

参考文献（Reference）：

本文档

IANA在网页“域名系统（DNS）参数”上为“经由QUIC的DNS的错误码”添加了一个注册表。

注册表“经由QUIC的DNS错误码”管理着62比特位长的空间。该空间被分为三段使用不同策略来管理的区域：

• 值在0x00至0x3f之间（十六进制，包含两端）的永久注册项，它们会以标准行为（Standards Action）或IESG批准的方式指定，详见《RFC8126》的第4.9章和第4.10章。

• 值大于0x3f的永久注册项，它们会以强制规范（Specification Required）的方式指定，详见《RFC8126》。

• 值大于0x3f的临时注册项，它们会以专家评审（Expert Review）的方式指定，详见《RFC8126》的第4.5章。

临时注册项与一些永久注册项共享大于0x3f的值范围。这种设计是有意的，从而使得无需修改部署系统就能够将临时注册项转换为永久注册项。（该设计符合《RFC9000》的第22章中的原则。）

该注册表中的注册项必须包含以下字段：

值（Value）：

分配的码点

状态（Status）：

“永久”或“临时”

联系方式：

注册者的联系方式

除此之外，永久注册项中必须包含

错误（Error）：

该参数简短的帮助记忆的名称

规范（Specification）：

指向一份公开可用的针对此值的规范的引用（该字段对临时注册项是可选的）

描述（Description）：

对该错误码语义的简要描述，当提供了指向规范文件的引用时，此内容可以是一份概述。

码点的临时注册项是为了支持私有用途和DoQ的实验性扩展。然而，临时注册项可以被释放或重新指定为另一用途。除了上方列出的字段外，临时注册项还必须包括：

日期：

最后一次更新此注册项的日期

对任何临时注册项的日期进行更新的申请不需要经过专家（组）的评审。

表1为该注册表的初始内容，所有项目均使用以下字段和值：

状态：

永久

联系方式：

DPRIVE WG

规范：

第4.3章

本附录讨论了为何允许在0-RTT数据中发送NOTIFY（详见《RFC1996》）。

第4.5章中提到，必须不使用0-RTT机制来发送并非“可重放”事务的DNS请求。本规范支持在0-RTT数据中发送NOTIFY的原因是尽管技术上NOTIFY会改变接收它的服务器的状态，但是重放NOTIFY所能够造成的实际影响微乎其微。

NOTIFY消息向辅服务器发出提醒，使其根据是否有新版本的可用区域来向主服务器发送SOA查询或XFR请求。NOTIFY可以被伪造，并且理论上可以被用来使辅服务器向主服务器发送重复的冗余请求，这是众所周知的。基于这个原因，大多数实现都具有某种机制，从而限制因接收到NOTIFY而触发的SOA/XFR查询频次。

《RFC9103》描述了与NOTIFY和SOA查询有关的隐私方面的风险，且没有涉及如何在加密区域传送场景中消除这些风险。因此，将DoQ用于NOTIFY的做法在隐私方面的好处并不明确，但是出于相同的理由，将NOTIFY作为0-RTT数据来发送的做法在隐私方面的风险并不会高于使用明文DNS来发送它时的风险。

本文档从Mike Bishop编辑的HTTP/3规范《HTTP/3》及由Zi Hu、Liang Zhu、John Heidemann、Allison Mankin、Duane Wessels，和Paul Hoffman撰写的DoT规范《RFC7858》中摘抄了内容。

有关0-RTT数据和会话恢复的隐私问题是由Daniel Kahn Gillmor（DKG）在发向IETF DPRIVE工作组的消息中分析的（详见《DNS0RTT》）。

感谢Tony Finch对本文档的初始草案进行的大量评审，和Robert Evans对0-RTT隐私问题的讨论。Paul Hoffman和Martin Thomson的早期评阅和Stephane Bortzmeyer进行的互操作性测试对提升协议的定义颇有帮助。

还要感谢Martin Thomson和Martin Duke在后期对于底层QUIC细节的审阅，这帮助澄清了DoQ的许多方面。感谢Andrey Meshkov、Loganaden Velvindron、Lucas Pardue、Matt Joras、Mirja Kuelewind、Brian Trammell，和Phillip Hallam-Baker的评阅与贡献。

Christian Huitema

Private Octopus Inc.

427 Golfcourse Rd

Friday Harbor, WA 98250

United States of America

Email: huitema@huitema.net

Sara Dickinson

Sinodun IT

Oxford Science Park

Oxford

OX4 4GA

United Kingdom

Email: sara@sinodun.com

Allison Mankin

Salesforce

Email: allison.mankin@gmail.com

译

• Yunzhe

  • Email: yunzhe@zju.edu.cn

• ruokeqx

  • Email: ruokeqx@163.com

• 方秋航

  • Email: fangqiuhang@163.com