ICS 33.040.40 YD CCS L78 中华人民共和国通信行业标准 YD/TXXXXXXXXX 快速UDP网络连接（QUIC）的DNS 传输技 术要求 （报批稿） XXXX-XX- XX 发布 XXXX-XX- XX 实施 中华人民共和国工业和信息化部发布 XXXX—XXXXX 1/XX 前言 本文件按照GB/T1.1一2020《标准化工作导则第1部分：标准化文件的结构和起草规则》给出的规 定起草。 请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。 本文件由中国通信标准化协会提出并归口。 本文件起草单位：中国互联网络信息中心（CNNIC）、北京邮电大学、暨南大学、中国电信集团 有限公司。 本文件主要起草人：张曼、延志伟、李洪涛、董科军、姚健康、时金桥、耿光刚 IV xxxXxxxxX 1/XX 快速UDP网络连接（QUIC）的DNS传输技术要求 1范围 本文件规定了利用快速UDP网络连接为DNS查询和响应提供安全和隐私保护的技术要求，包括连接 建立和管理、消息映射机制、错误码定义、会话恢复等技术要求，以及身份认证、地址验证、填充、并 行处理、流量控制等具体实现要求。 本文件适用于网络连接中传统DNS面临主动和被动攻击的场景，改善明文DNS传输存在的问题。 2规范性引用文件 下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件， 仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本 文件。 IETFRFC7766基于TCP的DNS实现要求（DNSTransportoverTCP-ImplementationRequirements） IETFRFC9000QUIC：基于UDP的多路复用安全传输（QUIC：AUDP-BasedMultiplexedandSecure Transport) IETFRFC9250基于专用QUIC连接的DNS(DNSoverDedicatedQUICConnections) 3术语和定义 本文件没有需要界定的术语和定义。 4缩略语 下列缩略语适用于本文件。 ALPN 应用层协议协商 ApplicationLayerProtocolNegotiation API 应用程序编程接口 Application Programming Interface AXFR DNS区域传输协议 AuthoritativeZone Transfer DNS 域名系统 Domain Name System DoH 基于HTTPS的DNS DNS over HTTPS DoQ 基于QUIC的DNS DNS over QUIC DoT 基于TLS 的DNS DNS over TLS DSO DNS状态操作 DNS Stateful Operations HTTP 超文本传输协议 Hyper Text Transfer Protocol IXFR 增量区域传输 Incremental Zone Transfer MTU 最大传输单元 Maximum Transmission Unit 1 xXxX—XxxxX 1/XX NAT 网络地址转换 NetworkAddress Translation QUIC 快速UDP网络连接 Quick UDP Internet Connections RTT 往返时延 Round-Trip Time TLD 顶级域 Top-level Domain TLS 安全传输层协议 Transport Layer Security URL 统一资源定位符 Uniform Resource Locator XoT 基于TLS的DNS区域传输 DNS Zone Transfer over TLS 5概述 本文件介绍将DNS协议消息映射到QUIC交互的规范。DoQ映射的目的在于： 提供与DoT相同的DNS隐私保护功能。客户端可选择相应的机制对服务器进行认证； 相比传统的DNSoverUDP，提供更高级别的DNS服务器源地址验证； 提供一种不对DNS响应大小施加路径MTU限制的传输方式。 为了达到上述目的，本文件的范围包括以下方面： 客户端到递归解析器场景； 一递归解析器到权威服务器场景； 名称服务器到名称服务器场景（主要用于区数据传输）。 本文件指定QUIC作为DNS的通用传输机制。 本文件的目标不包括以下方面： 避免中间盒对DoQ流量的阻塞： 支持由服务器端发起的事务，其仅用于DSO场景。 定义基于QUIC的应用传输应说明应用层消息如何映射到QUIC流中，及该应用层协议如何使用 QUIC。本文件在定义DNS消息通过QUCI传输的方式。 DoH能够使用HTTP/3来获取QUIC的一些优势。但是DoQ采取直接映射的方式，有更少的中间方介 入，更加适合递归解析器到权威服务器以及区数据传输的场景。在这些场景中，HTTP的额外开销不会 被HTTP代理和缓存等带来的优势所抵消。 本文件中第6章介绍了设计目标和理由，第7章详细说明了DoQ的映射，第8章描述了DoQ实现、应 用和部署的指导方针。 6设计考虑因素 6.1提供DNS隐私 DoT具体说明了如何通过TLS传输DNS消息，并详细说明了如何缓解可能存在的DNS隐私问题。DoT 和基于DTLS的DNS可分别使用严格模式和机会主义模式。 QUIC连接建立应包括使用TLS进行安全参数的协商，具体过程参见IETFRFC9001。通过QUIC传 送DNS信息，将执行与DoT基本相同的隐私保护，包括严格和机会主义模式。第10章将对此展开进一步 讨论。 6.2最小延迟设计 QUIC专门设计用于降低协议端延退。其包括以下特点： 2 xXxX—xxxxX1/XX 一一会话恢复时支持0-RTT数据； 一支持丢包检测机制； 通过在多个流上并行传递数据来缓解队头阻塞问题。 DNS到QUIC的映射应通过以下三种方式对上述特性加以利用： 可在会话恢复期间发送0-RTT数据（其安全性和隐私问题将在后续章节讨论）； 一一单个QUIC长连接支持传输多个DNS消息，生成持续的流量，而这是丢包检测机制所需要的； 一一本文件将每个DNS查询/响应事务映射到单独的流，以减少队头阻塞现象。这使得服务器能够 务器之前提交的响应。 本文件第7.2节将DNS流量映射到QUIC流将考虑这些因素。 6.3中间件注意事项 使用QUIC可能允许协议使用加密和流量分析抵抗技术（如填充、流量速度和流量控制）对网络路 径上的设备掩盖其目的。本文件不包括任何旨在避免这种分类的措施；第8.4节中定义的填充机制旨在 混淆DNS查询和响应中包含的具体记录，但不包括这是DNS流量这一事实。 防火墙和其他中间件可能会将DoQ与其他使用QUIC的协议（如HTTP）区分开来，并采用不同的处 理方法。 本文件中缺乏避免协议分类的措施，并不是对这种做法的认可。 6.4不包括服务器发起的交互 如第5章所述，本文件不支持服务器发起的交互。只有DoQ连接的发起者可以通过该连接发送查询。 DSO确实支持现有连接中由服务器发起的交互。DoQ不能保证消息的有序传递，并不符合DSO适用 的传输标准。 6.5DoQ连接管理与消息映射规范连接建立 6.5.1端口选择 DoQ连接应按照QUIC传输规范中的描述建立。在连接建立期间，DoQ支持应通过在加密握手中选 择ALPN扩展"doq"来表示。 默认情况下，支持DoQ的DNS服务器应在专用UDP端口853上监听和接受QUIC连接，除非双方协商 使用另外端口。 默认情况下，在特定服务器上使用DoQ的DNS客户端应在服务器上的UDP853端口建立一个QUIC 连接，除非双方同意使用其他端口。 DoQ连接不应使用UDP端口53。禁止在DoQ中使用53端口是为了避免DoQ和通过UDP使用DNS之 间的混淆。即使双方同意使用53端口，也存在混淆的风险，其他各方在不知道该协议的情况下，仍可能 尝试使用该端口。 在用户客户端到递归解析器的情况下，使用443端口作为双方同意的替代端口在操作上是有益的， 443端口被许多使用QUIC和HTTP-3的服务使用，比其他端口更不可能被封。 6.6流映射和使用 6.6.1流映射规则 QUIC流映射规则如下： 3 xXxX—XxxxX 1/XX QUIC流上的DNS流量映射应遵循IETFRFC9000第2章中详述的QUIC流特性和IETFRFC9250 中的要求 -DNS查询/响应流量应遵循一个简单的模式，即客户端发送一个查询，而服务器提供一个或多 个响应（在区数据传送中可能出现多个响应）。 响应信息。 一客户端应遵循IETFRFC9000中规定的QUIC传输规范，为QUIC连接上的每个后续查询选择下 一个可用的客户端发起的双向流， 一客户端应在选定的流上发送DNS查询，并且应通过STREAMFIN机制表明不会在该流上进一步 发送数据。 一服务器应在同一流上发送响应，并且应在最后一个响应之后通过STREAMFIN机制表明将不会 在该数据流上发送进一步的数据。为了对多个响应进行解析，应使用一个2字节的长度字段，其方式与 通过TCP定义的DNS的2字节长度字段完全相同。这样做的实际结果是，每个QUIC流的内容与管理一个 查询的TCP连接的内容完全相同。 通过DoQ连接发送的所有DNS消息（查询和响应）应被编码为2字节的长度字段开头，其后是中规 定的消息内容。 数据包丢失和其他网络事件可能导致查询以不同的顺序到达。服务器应在查询到达时进行处理，否 则会造成不必要的延迟。 0的流上，第二个查询发生于ID为4的流上，以此类推