ICS 33.040.40 CCS L78 YD 中华人民共和国通信行业标准 YD/T XXXX—XXXX 基于 HTTPS 的 DNS 传输技术要求 Technical requirements for DNS over HTTPS （报批稿） XXXX-XX - XX 发布 XXXX-XX-XX实施 中华人民共和国工业和信息化部发布 xxxX—xxxxx 1/X 前 言 本文件按照GB/T1.1一2020《标准化工作导则第1部分：标准化文件的结构和起草规则》给出的规 定起草。 请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。 本文件由中国通信标准化协会提出并归口。 本文件起草单位：中国互联网络信息中心、中国科学院计算机网络信息中心、中国科学院计算技术 研究所、暨南大学、广东盈世计算机科技有限公司、鹏城实验室、中国信息通信研究院、互联网域名系 统北京市工程研究中心有限公司、中国联合网络通信集团有限公司、中国电信股份有限公司、中国互联 网协会。 本文件主要起草人：姚健康、张曼、周琳琳、李洪涛、董科军、延志伟、耿光刚、李彦彪、张宇、 张广兴、马迪、邹慧、傅瑜、王翠翠、张戈、刘越、李真辉、吴秀诚、钟睿、卫俊凯、张雷、贺莉娟、 王中华、丁嘉嘉、张文伟。 III Xx/T xxxxx—xxxx 基于HTTPS 的 DNS 传输技术要求 1范围 本文件规定了客户端和域名系统（DNS）解析器通过HTTPS发送DNS查询和获取DNS响应的方法和具体 技术要求。 本文件适用于DNS服务提供方，网络运营商和管理机构防范传统DNS传输存在的攻击风险， 规范性引用文件 2 下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件， 仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本 文件。 IETFRFC8484 通过HTTPS进行DNS查询（DNSQueriesoverHTTPS(DoH)） 3 术语和定义 本文件没有术语和定义。 4缩略语 下列缩略语适用于本文件。 AD 可信数据 AuthenticData CDN 内容分发网络 Content Delivery Network DNS 域名系统 Domain Name System DNS64 从IPv6客户端到IPv4服务器的网络 DNSExtensionsfor NetworkAddress 地址转换DNS扩展 Translation from IPv6 Clients to IPv4 Servers DoH 基于HTTPS的DNS DNS over HTTPS HTTP 超文本传输协议 Hyper Text Transfer Protocol HTTP GET 超文本传输协议GET方法 HTTP GET Method HTTP POST 超文本传输协议POST方法 HTTP POST Method SNI 服务器名字标识符 Server Name Indication TFO TCP快速打开 TCP Fast Open TLS 安全传输层协议 Transport Layer Security TTL 生存时间 Time to live URI 统一资源标识符 Uniform ResourceIdentifier 1 XX/T XXXXX—XXXX URL 统一资源定位符 UniformResourceLocator 5概述 本文件定义了一种特定的协议，基于HTTPS的DNS，用于使用HTTPSURI发送DNS查询并通过 HTTP获取DNS响应，以确保消息完整性和机密性。每个DNS查询-响应对应映射到一个HTTP交互中。 该方法为请求和响应建立默认的媒体类型，除了这种媒体类型协商之外，还与HTTP其它功能（例 如缓存，重定向，代理，身份验证和压缩）保持一致。 与HTTP的集成可为现有DNS客户端和寻求访问DNS的Web应用程序提供了更加隐私安全的传输方 式。 本文件规范DNS客户端与递归解析器之间的通信技术要求。 6DoH服务器的选择 DoH客户端应通过URI模板配置与服务器建立连接，该模板描述了如何构造用于解析的URL。URI 模板的配置，发现和更新应从本文件外完成。配置可手动（例如，用户在用户界面中输入URI模板选项） 或自动（例如，在DHCP或类似协议的响应中提供的URI模板）进行。 别保证。 DoH客户端应使用配置信息来选择URI，从而选择DoH服务器。客户端应对DoH服务器的身份进行 验证。 如果客户端在配置之外发现了其它URI（例如通过HTTP/2服务器推送），应对其进行可信性认证再 考虑是否使用。 7HTTP交互 7.1HTTP请求 DoH客户端应使用HTTPGET或POST方法以及本节的其他要求将单个DNS查询编码为HTTP请求。 DoH服务器应使用URI模板定义请求所使用的URI，应遵循IETFRFC8484第4节中的要求。 当HTTP方法为POST时，本文件中定义的URI模板处理时应不带任何变量，当HTTP方法为GET时 如果未来定义供DoH使用的新的媒体类型，则其规范应定义使用此协议时URI模板使用的变量。 DoH服务器应同时实现POST和GET方法。 使用POST方法时，DNS请求应放在HTTP请求的消息体内，内容类型请求头字段标识消息的媒体类 型。 使用GET方法可对许多HTTP缓存实现更加友好。 DoH客户端应包括HTTPAccept请求头字段，以指示响应中可以理解的内容类型。不论Accept请求 头字段的值，客户端应准备处理“application/dns-message”（如第9章所述）响应，但也可处理其收到 的其他与DNS相关的媒体类型。 为了最大限度地提高HTTP缓存的友好性，如果DoH客户端使用的媒体类型中包括了DNS消息头的 ID字段，则应在每个DNS请求中使用ID为0。 2 XXXX—XXXXX 1/XX 相同。 7.2HTTP响应 本文件中定义的唯一响应类型是“application/dns-message”。DoH服务器应能够处理 “application/dns-message”请求消息。 未来定义其它媒体类型时，不同的响应媒体类型可通过DNS响应提供差异化信息。不同媒体类型提 供的信息量和类型仅取决于格式，本文件未定义。 每个DNS请求-响应对应映射到一个HTTP交换。可使用HTTP的多数据流功能以任何顺序处理和传 输响应。 8.1节讨论了DNS和HTTP响应缓存之间的关系。HTTP响应示例参见附录B 7.3处理DNS和HTTP错误 DNS响应代码可指示DNS查询成功还是失败。成功的HTTP响应带有2xx状态代码可用于任何有效的 DNS响应，而与DNS响应代码无关。例如，即使DNS消息的DNS响应代码指示失败，也应使用成功的2xx HTTP状态代码，例如SERVFAIL或NXDOMAIN HTTP状态代码不成功的HTTP响应不包含对HTTP请求中原始DNS问题的答复。DoH客户端应使用 与其他HTTP客户端相同的对不成功的HTTP状态代码的语义处理。例如如果存在授权失败（HTTP状态 或服务器无法生成适合客户端的表示形式（HTTP状态代码406）等情况，DoH客户端可使用其他DoH服 务器进行重试。 8HTTP整合 8.1缓存交互 DoH交互时可使用包括HTTP和DNS的缓存层次结构。上述缓存可存在于DoH服务器与客户端之间， 也可存在于DoH客户端。 DoH服务器应考虑它们为响应GET请求而发送的HTTP缓存元数据（除非发送了特定的响应头字段 否则对POST请求的响应是不可缓存的。该功能并未得到广泛实施，也不建议在DoH中使用）。 DoH服务器应分配一个明确的HTTP刷新生存期，以便DoH客户端可使用新的DNS数据。 DoHHTTP响应的指定刷新生存期应小于或等于DNS响应的“答复”部分中的最小TTL。建议刷新 生存期等于应答部分中最小的TTL。例如，如果HTTP响应包含三个资源记录集，其TTL为30、600和300， 则HTTP更新有效期应为30秒（可将其指定为“Cache-Control：max-age=30”）。此要求有助于防止意 外使用HTTP缓存中消息中过期的资源记录集。 如果DNS响应在应答部分中没有记录，并且DNS响应在权威部分中具有授权起源记录，响应的刷新 生存期应不能大于该授权起源记录中的MINIMUM字段。 服务器可支持失效时重新验证和错误时失效缓存控制指令。客户端可重用所有已缓存条目或不重用 任何内容。 例如可将Cache-Controlmax-age设为O，或者使用Vary响应头字段来建立辅助缓存键。 3 XX/T XxXXX—XxXx 在计算响应的DNSTTL时，DoH客户端应考虑消息创建时间（Age）响应头字段的值。例如，如果 收到的DNSTTL为600的RRset，但是消息创建时间头字段指示响应已缓存250秒，则资源记录集的剩余 寿命为350秒。此要求适用于DoH客户端HTTP缓存和DNS缓存。 HTTP条件请求对DoH的价值可能有限，因为重新验证仅提供带宽优势，并且DNS事务通常受延迟 限制。此外，支持重新验证的HTTP响应头字段（例如Last-Modified和Etag）通常相当大，并且具有可 变性质，会对HTTP/2压缩字典产生恒定的压力。其他类型的DNS数据（例如区域传输）可能更大，并 可从重新验证中受益更多。 8.2HTTP/2 HTTP/2应是与DoH一起使用的HTTP的最低推荐版本。 经典的基于UDP的DNS中的消息本