非官方中文译本声明：本页为 IETF RFC 8484《DNS Queries over HTTPS (DoH)》 的非官方中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布、不受版权限制；依据 BCP 78，本译本为署名翻译作品，译文力求忠实但不构成官方版本，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc8484。

RFC 8484《DNS over HTTPS（DoH）规范》中文译本

IETF · RFC 8484 · 标准跟踪（Standards Track）· 2018 年 10 月

摘要

本文档定义了一种通过 HTTPS 发送 DNS 查询并获取 DNS 响应的协议。每一对 DNS 查询—响应都被映射为一次 HTTP 交换。

1. 引言

本文档定义了一种具体的协议——DNS over HTTPS（DoH），用于使用 https [RFC2818] URI（并因此获得 TLS [RFC8446] 所提供的完整性与机密性保护），通过 HTTP [RFC7540] 发送 DNS [RFC1035] 查询并获取 DNS 响应。每一对 DNS 查询—响应都被映射为一次 HTTP 交换。

所描述的方法不只是一条基于 HTTP 的隧道。它为请求与响应确立了默认的媒体格式类型，但使用常规的 HTTP 内容协商机制来选择端点在应对新用例时可能更偏好的替代格式。除这种媒体类型协商之外，它还与缓存、重定向、代理、认证和压缩等 HTTP 特性保持一致。

与 HTTP 的集成为既有的 DNS 客户端以及希望访问 DNS 的原生 Web 应用提供了一种合适的传输方式。

在本协议的开发过程中主要考虑了两类用例：一是防止路径上的设备（on-path devices）干扰 DNS 操作，二是允许 Web 应用以符合跨源资源共享（CORS）[FETCH] 的安全方式，通过既有的浏览器 API 访问 DNS 信息。本协议未为启用或阻止其他用例作出特别的努力。本文档聚焦于 DNS 客户端（例如操作系统的存根解析器）与递归解析器之间的通信。

2. 术语

支持本协议的服务器称为「DoH 服务器」，以区别于「DNS 服务器」（后者仅通过为 DNS 标准化的一种或多种其他传输协议提供 DNS 服务）。类似地，支持本协议的客户端称为「DoH 客户端」。

本文档中的关键词 "MUST"（必须）、"MUST NOT"（不得）、"REQUIRED"（需要）、"SHALL"（应）、"SHALL NOT"（不应）、"SHOULD"（应当）、"SHOULD NOT"（不应）、"RECOMMENDED"（推荐）、"NOT RECOMMENDED"（不推荐）、"MAY"（可以）和 "OPTIONAL"（可选），当且仅当它们如本处所示以全大写形式出现时，应按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释。

3. DoH 服务器的选择

DoH 客户端配置有一个 URI 模板（URI Template）[RFC6570]，该模板描述了如何构造用于解析的 URL。URI 模板的配置、发现与更新在本协议之外（out of band）完成。请注意，配置既可能是手工的（例如用户在「选项」界面中键入 URI 模板），也可能是自动的（例如由 DHCP 或类似协议在响应中提供 URI 模板）。DoH 服务器可以（MAY）支持多个 URI 模板。这使得不同的端点可以具备不同的属性，例如不同的认证要求或服务水平保证。

DoH 客户端依据配置来选择 URI，进而选择用于解析的 DoH 服务器。[RFC2818] 定义了 HTTPS 如何校验 DoH 服务器的身份。

DoH 客户端不得（MUST NOT）仅因某个 URI 是在客户端配置之外被发现的（例如通过 HTTP/2 服务器推送），或因某服务器主动提供了一个看似对某 DNS 查询的有效应答，就使用该不同的 URI。本规范不会把 DNS 解析特权扩展到那些未被 DoH 客户端识别为已配置 URI 的 URI 上。此类场景可能带来额外的运营、追踪与安全隐患，需要加以限制才能安全使用。未来的规范可能会支持这一用例。

4. HTTP 交换

4.1. HTTP 请求

DoH 客户端使用 HTTP GET 或 POST 方法，并遵循本节的其他要求，将单个 DNS 查询编码进一个 HTTP 请求。DoH 服务器通过使用 URI 模板来定义请求所使用的 URI。

当 HTTP 方法为 POST 时，本文档定义的 URI 模板在处理时不带任何变量。当 HTTP 方法为 GET 时，定义了单个变量 "dns"，其内容为 DNS 请求的内容（如第 6 节所述），并以 base64url [RFC4648] 编码。

未来为 DoH 定义新媒体类型的规范必须（MUST）定义在本协议中用于 URI 模板处理的变量。

DoH 服务器必须（MUST）同时实现 POST 与 GET 方法。

使用 POST 方法时，DNS 查询作为 HTTP 请求的消息体，Content-Type 请求头字段指示该消息的媒体类型。以 POST 发送的请求通常比其等效的 GET 请求更小。

使用 GET 方法则对许多 HTTP 缓存实现更为友好。

DoH 客户端应当（SHOULD）包含 HTTP Accept 请求头字段，以指明其在响应中能够理解何种类型的内容。无论 Accept 请求头字段的取值如何，客户端必须（MUST）做好处理 "application/dns-message" 响应（如第 6 节所述）的准备，但也可以（MAY）处理其收到的其他 DNS 相关媒体类型。

为了最大限度提升 HTTP 缓存友好性，使用了包含 DNS 报文头中 ID 字段的媒体格式（例如 "application/dns-message"）的 DoH 客户端，应当（SHOULD）在每个 DNS 请求中都使用值为 0 的 DNS ID。HTTP 会把请求与响应关联起来，因此在诸如 "application/dns-message" 这样的媒体类型中不再需要 ID。使用变化的 DNS ID 会导致语义上等价的 DNS 查询被分别缓存。

DoH 客户端可以像其他 HTTP/2 客户端使用（或不使用）HTTP/2 填充与压缩 [RFC7540] 那样使用它们。

4.1.1. HTTP 请求示例

以下示例采用 [RFC7540] 的 HTTP/2 风格格式。

这些示例所使用的 DoH 服务，其 URI 模板为 "https://dnsserver.example.net/dns-query{?dns}"，用于解析 IN A 记录。

请求以媒体类型 "application/dns-message" 的消息体形式表示。

第一个示例请求使用 GET 查询 "www.example.com"。

:method = GET
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
accept = application/dns-message

针对 "www.example.com" 的同一 DNS 查询，若使用 POST 方法，则为：

:method = POST
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query
accept = application/dns-message
content-type = application/dns-message
content-length = 33

<33 bytes represented by the following hex encoding>
00 00 01 00 00 01 00 00  00 00 00 00 03 77 77 77
07 65 78 61 6d 70 6c 65  03 63 6f 6d 00 00 01 00
01

在该示例中，这 33 字节是 DNS 线格式（wire format）[RFC1035] 的 DNS 报文，从 DNS 报文头开始。

最后，给出一个针对 "a.62characterlabel-makes-base64url-distinct-from-standard-base64.example.com" 的基于 GET 的查询示例，用以强调 base64url 的编码字母表不同于常规 base64，且省略了填充字符。

以 DNS 线格式表示的该 DNS 查询为 94 字节，如下所示：

00 00 01 00 00 01 00 00  00 00 00 00 01 61 3e 36
32 63 68 61 72 61 63 74  65 72 6c 61 62 65 6c 2d
6d 61 6b 65 73 2d 62 61  73 65 36 34 75 72 6c 2d
64 69 73 74 69 6e 63 74  2d 66 72 6f 6d 2d 73 74
61 6e 64 61 72 64 2d 62  61 73 65 36 34 07 65 78
61 6d 70 6c 65 03 63 6f  6d 00 00 01 00 01

:method = GET
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query? (no space or Carriage Return (CR))
        dns=AAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJl (no space or CR)
        bC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1z (no space or CR)
        dGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ
accept = application/dns-message

4.2. HTTP 响应

本文档中定义的唯一响应类型是 "application/dns-message"，但未来有可能定义其他响应格式。DoH 服务器必须（MUST）能够处理 "application/dns-message" 请求报文。

不同的响应媒体类型会从 DNS 响应中提供或多或少的信息。例如，某种响应类型可能包含来自 DNS 报文头字节的信息，而另一种则可能将其省略。某一媒体类型给出的信息数量与类型完全取决于该格式本身，本协议对此不作定义。

每一对 DNS 请求—响应都映射为一次 HTTP 交换。这些响应可以利用 HTTP 的多流（multi-streaming）功能以任意顺序处理与传输（参见 [RFC7540] 第 5 节）。

第 5.1 节讨论了 DNS 与 HTTP 响应缓存之间的关系。

4.2.1. DNS 错误与 HTTP 错误的处理

DNS 响应码指示该 DNS 查询是成功还是失败。对于任何有效的 DNS 响应，无论其 DNS 响应码为何，都使用带 2xx 状态码的成功 HTTP 响应（参见 [RFC7231] 第 6.3 节）。例如，即使某 DNS 报文的 DNS 响应码指示失败（如 SERVFAIL 或 NXDOMAIN），仍使用成功的 2xx HTTP 状态码。

带有非成功 HTTP 状态码的 HTTP 响应不包含对 HTTP 请求中原始 DNS 问题的应答。DoH 客户端需要像其他 HTTP 客户端一样，对非成功的 HTTP 状态码采用相同的语义化处理。这可能意味着 DoH 客户端向同一 DoH 服务器重试该查询，例如在出现授权失败时（HTTP 状态码 401；参见 [RFC7235] 第 3.1 节）。也可能意味着 DoH 客户端改用另一台 DoH 服务器重试，例如遇到不支持的媒体类型时（HTTP 状态码 415；参见 [RFC7231] 第 6.5.13 节），或服务器无法生成适合该客户端的表示时（HTTP 状态码 406；参见 [RFC7231] 第 6.5.6 节），等等。

4.2.2. HTTP 响应示例

以下是对 "www.example.com" 的 IN AAAA 记录、并开启递归的查询的一个响应示例。该响应携带一条应答记录，地址为 2001:db8:abcd:12:1:2:3:4，TTL 为 3709 秒。

:status = 200
content-type = application/dns-message
content-length = 61
cache-control = max-age=3709

<61 bytes represented by the following hex encoding>
00 00 81 80 00 01 00 01  00 00 00 00 03 77 77 77
07 65 78 61 6d 70 6c 65  03 63 6f 6d 00 00 1c 00
01 c0 0c 00 1c 00 01 00  00 0e 7d 00 10 20 01 0d
b8 ab cd 00 12 00 01 00  02 00 03 00 04

5. 与 HTTP 的集成

本协议必须（MUST）与 https URI 方案 [RFC7230] 一同使用。

第 8 节与第 9 节讨论了与 HTTP 集成相关的更多考虑事项。

5.1. 与缓存的交互

一次 DoH 交换可能会穿过由 HTTP 专用缓存和 DNS 专用缓存共同构成的缓存层级。这些缓存可能位于 DoH 服务器与客户端之间，也可能就存在于 DoH 客户端自身之上。HTTP 缓存在设计上是通用的，也就是说，它们并不理解本协议。即便某个 DoH 客户端已修改其缓存实现使之感知 DoH 语义，也并不意味着所有上游缓存（例如串接式代理、服务端网关和内容分发网络）都会如此。

因此，DoH 服务器需要审慎考虑其在响应 GET 请求时所发送的 HTTP 缓存元数据（对 POST 请求的响应除非发送了特定的响应头字段否则不可缓存；这一点尚未被广泛实现，且不建议在 DoH 中采用）。

特别地，DoH 服务器应当（SHOULD）指定一个显式的 HTTP 新鲜度生存期（freshness lifetime，参见 [RFC7234] 第 4.2 节），以便 DoH 客户端更有可能使用新鲜的 DNS 数据。之所以有此要求，是因为 HTTP 缓存能够自行指定启发式新鲜度（例如 [RFC7234] 第 4.2.2 节所描述的那样），从而使缓存内容的控制权脱离 DoH 服务器之手。

DoH HTTP 响应所指定的新鲜度生存期必须（MUST）小于或等于该 DNS 响应 Answer 节中最小的 TTL。推荐（RECOMMENDED）将新鲜度生存期取为等于 Answer 节中最小的 TTL。例如，若某个 HTTP 响应携带了 TTL 分别为 30、600 和 300 的三个 RRset，则 HTTP 新鲜度生存期应为 30 秒（可通过 "Cache-Control: max-age=30" 来指定）。该要求有助于防止 HTTP 缓存中报文里已过期的 RRset 被无意间提供出去。

如果该 DNS 响应的 Answer 节中没有任何记录，而其 Authority 节中有一条 SOA 记录，则该响应的新鲜度生存期不得（MUST NOT）大于该 SOA 记录中的 MINIMUM 字段（参见 [RFC2308]）。

在服务器策略允许的情况下，stale-while-revalidate 与 stale-if-error 这两个 Cache-Control 指令 [RFC5861] 可能非常适合 DoH 实现。这些机制允许客户端在服务器许可下，复用一条已不再新鲜的 HTTP 缓存条目。在这种情况下，客户端要么复用某条缓存条目的全部内容，要么完全不复用。

DoH 服务器在生成并非全局有效的响应时，同样需要考虑 HTTP 缓存。例如，如果某 DoH 服务器根据客户端身份对响应进行了定制，它就不会希望该响应被全局复用。这可以通过多种 HTTP 技术来实现，例如将 Cache-Control 的 max-age 设为 0，或使用 Vary 响应头字段（参见 [RFC7231] 第 7.1.4 节）来建立次级缓存键（参见 [RFC7234] 第 4.1 节）。

DoH 客户端在计算某个响应的 DNS TTL 时，必须（MUST）计入 Age 响应头字段的值 [RFC7234]。例如，若收到的某个 RRset 的 DNS TTL 为 600，但 Age 头字段表明该响应已被缓存 250 秒，则该 RRset 的剩余生存期为 350 秒。该要求同时适用于 DoH 客户端的 HTTP 缓存与 DoH 客户端的 DNS 缓存。

DoH 客户端可以通过使用 "no-cache" 请求 Cache-Control 指令（参见 [RFC7234] 第 5.2.1.4 节）及类似的控制手段，来请求某个 HTTP 响应的未缓存副本。请注意，某些缓存可能不会遵从这些指令，原因可能在于其配置，也可能在于与不具备此类机制的传统 DNS 缓存之间的交互。

HTTP 条件请求 [RFC7232] 对 DoH 的价值可能有限，因为重新验证（revalidation）只带来带宽方面的收益，而 DNS 事务通常受时延约束。此外，用于启用重新验证的那些 HTTP 响应头字段（例如 "Last-Modified" 和 "Etag"）相较于 DNS 响应的整体大小往往相当庞大，且具有多变的特性，会对 HTTP/2 压缩字典 [RFC7541] 造成持续压力。其他类型的 DNS 数据（例如区传送）可能更大，也能从重新验证中获得更多收益。

5.2. HTTP/2

HTTP/2 [RFC7540] 是推荐（RECOMMENDED）用于 DoH 的最低 HTTP 版本。

经典的基于 UDP 的 DNS [RFC1035] 中的报文本质上是无序的，且开销很低。一种具备竞争力的 HTTP 传输需要支持重排序、并行、优先级和头部压缩，才能达到类似的性能。这些特性是在 HTTP/2 [RFC7540] 中引入 HTTP 的。更早版本的 HTTP 能够表达 DoH 的语义要求，但可能导致非常糟糕的性能。

5.3. 服务器推送

在将 DoH 响应数据用于 DNS 解析之前，客户端必须（MUST）确认该 HTTP 请求 URI 可用于 DoH 查询。对于由 DoH 客户端发起的 HTTP 请求，这一点隐含在 URI 的选择之中。对于 HTTP 服务器推送（参见 [RFC7540] 第 8.2 节），则必须格外小心，以确保被推送的 URI 正是客户端在自行发起该请求时会将同一查询发往的那个 URI（这是在服务器推送通常所需的其他安全检查之外的额外要求）。

5.4. 内容协商

为最大限度实现互操作性，DoH 客户端与 DoH 服务器必须（MUST）支持 "application/dns-message" 媒体类型。按照 HTTP 内容协商所定义的方式（参见 [RFC7231] 第 3.4 节），可以（MAY）使用其他媒体类型。这些媒体类型必须（MUST）足够灵活，能够表达通常会在 DNS over UDP 中发送的每一个 DNS 查询（包括使用 DNS 扩展的查询与响应，但不包括那些需要多个响应的情形）。

6. "application/dns-message" 媒体类型的定义

"application/dns-message" 媒体类型的数据载荷是一条采用 [RFC1035] 第 4.2.1 节所定义的 DNS 线上（on-the-wire）格式的单个报文，该节又进一步引用了同一 RFC 第 4.1 节所定义的完整线格式。

尽管 [RFC1035] 称「由 UDP 承载的报文被限制为 512 字节」，但这一点后来已被 [RFC6891] 更新。本媒体类型将 DNS 报文的最大尺寸限制为 65535 字节。

请注意，本媒体类型所使用的线格式不同于 [RFC7858] 中使用的线格式（后者使用 [RFC1035] 第 4.2.2 节所定义的、包含两个长度字节的格式）。

使用本媒体类型的 DoH 客户端可以（MAY）在请求中携带一个或多个 DNS 扩展机制（EDNS）选项 [RFC6891]。使用本媒体类型的 DoH 服务器必须（MUST）忽略 DNS 请求中给出的 EDNS UDP 载荷大小的值。

使用 GET 方法时，本媒体类型的数据载荷必须（MUST）以 base64url [RFC4648] 编码，然后作为名为 "dns" 的变量提供给 URI 模板展开。不得（MUST NOT）包含 base64url 的填充字符。

使用 POST 方法时，本媒体类型的数据载荷不得（MUST NOT）被编码，而是直接用作 HTTP 消息体。

7. IANA 考虑

7.1. "application/dns-message" 媒体类型的注册

类型名（Type name）：application

子类型名（Subtype name）：dns-message

必需参数（Required parameters）：N/A

可选参数（Optional parameters）：N/A

编码考虑（Encoding considerations）：这是一种二进制格式。其内容为 RFC 1035 所定义的 DNS 报文。此处使用的格式面向 DNS over UDP，即 RFC 1035 中图示所定义的格式。

安全考虑（Security considerations）：参见 RFC 8484。其内容为 DNS 报文，因而不是可执行代码。

互操作性考虑（Interoperability considerations）：无。

已发布规范（Published specification）：RFC 8484。

使用本媒体类型的应用（Applications that use this media type）：希望交换完整 DNS 报文的系统。

附加信息（Additional information）：

Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A

供进一步咨询的联系人与电子邮件地址（Person & email address to contact for further information）：Paul Hoffman <paul.hoffman@icann.org>

预期用途（Intended usage）：COMMON

使用限制（Restrictions on usage）：N/A

作者（Author）：Paul Hoffman <paul.hoffman@icann.org>

变更控制方（Change controller）：IESG

8. 隐私考虑

[RFC7626] 分别在「线路之上」（on the wire，[RFC7626] 第 2.4 节）与「服务器之中」（in the server，[RFC7626] 第 2.5 节）两种语境下讨论了 DNS 隐私考虑。这同样是审视 DoH 隐私考虑的一个有用框架。

8.1. 线路之上

DoH 对 DNS 流量进行加密，并要求对服务器进行认证。这既缓解了被动监视 [RFC7258]，也缓解了试图将 DNS 流量导向流氓服务器的主动攻击（参见 [RFC7626] 第 2.5.1 节）。DNS over TLS [RFC7858] 提供了类似的保护，而基于 UDP 和 TCP 的直接传输则易受此类攻击影响。关于如何选择填充长度的指导性实验工作可参见 [RFC8467]。

此外，使用 HTTPS 默认端口 443，以及能够在同一连接上将 DoH 流量与其他 HTTPS 流量混合，可以阻止无特权的路径上设备干扰 DNS 操作，并使 DNS 流量分析更加困难。

8.2. 服务器之中

DNS 线格式 [RFC1035] 本身不包含任何客户端标识符；然而，DNS 查询与响应的各种传输方式确实会提供可用于关联请求的数据。HTTPS 带来了新的关联性考虑，例如显式的 HTTP cookie，以及对 HTTP 请求头字段的独特集合与排列顺序进行的隐式指纹识别。

DoH 实现构建于 IP、TCP、TLS 与 HTTP 之上。每一层都包含一项或多项可被用来将查询关联到同一身份的常见特性。DNS 传输通常会继承其实现所使用的各层的隐私属性。例如，IP、TCP 与 TLS 的属性同样适用于 DNS over TLS 的实现。

在 DoH 中使用 HTTPS 层所带来的隐私考虑，是在 DNS over TLS 之上的增量。目前尚不知晓 DoH 会引入超出 HTTPS 本身所关联问题之外的新顾虑。

在 IP 层面，客户端地址提供了显而易见的关联信息。这可以通过使用 NAT、代理、VPN 或随时间进行简单的地址轮换来缓解；而如果所使用的 DNS 服务器能够将实时的寻址信息与其他个人标识符相关联（例如 DNS 服务器与 DHCP 服务器由同一实体运营时），情况则可能加剧。

对多个 DNS 请求使用同一条 TCP 连接的 DNS 实现，会直接把这些请求归为一组。长连接比短连接具有更好的性能表现；但它们会把更多请求归为一组，从而可能向关联与整合暴露更多信息。基于 TCP 的方案还可能通过使用 TCP Fast Open [RFC7413] 来追求性能。TCP Fast Open 中所用的 cookie 使服务器能够关联多个 TCP 会话。

基于 TLS 的实现常常通过某种形式的会话恢复机制（例如 [RFC8446] 第 2.2 节）来获得更好的握手性能。会话恢复为服务器把多个 TLS 连接相互关联提供了轻而易举的手段。

HTTP 的特性集同样可以通过多种不同方式被用于识别与追踪。例如，认证（Authentication）请求头字段会显式标识出所使用的配置档（profile），而 HTTP cookie 本就被设计为客户端与所访问站点之间的显式状态追踪机制，且常被用作认证手段。

此外，User-Agent 与 Accept-Language 请求头字段往往会传递关于客户端版本或区域设置的具体信息。这有利于内容协商，也便于为实现缺陷提供运营层面的变通措施。控制缓存行为的请求头字段可能会暴露客户端部分历史记录的状态信息。在同一连接上将 DoH 请求与其他 HTTP 请求混合，也为更丰富的数据关联提供了机会。

DoH 的协议设计允许应用充分利用 HTTP 生态系统，包括此处未一一列举的特性。使用完整的 HTTP 特性集使 DoH 不只是一条 HTTP 隧道，但其代价是让实现暴露于 HTTP 的全部隐私考虑之下。

DoH 客户端与服务器的实现者在决定是否启用这些特性时，需要考量它们的收益、隐私影响以及部署环境。建议实现只暴露达成所需特性集所必需的最小数据集。

判断某个 DoH 实现是否需要支持 HTTP cookie [RFC6265] 尤为重要，因为 HTTP cookie 是 HTTP 中主要的状态追踪机制。除非某个用例明确要求，否则 DoH 客户端不应（SHOULD NOT）接受 HTTP cookie。

9. 安全考虑

在 HTTPS 之上运行 DNS 依赖于底层 HTTP 传输的安全性。这缓解了基于 UDP 的 DNS 所面临的经典放大攻击。采用 HTTP/2 的实现可从 [RFC7540] 第 9.2 节所定义的 TLS 配置档中获益。

会话级加密在流量分析方面存在众所周知的弱点，在处理 DNS 查询时这一点可能尤为突出。HTTP/2 就压缩的使用（参见 [RFC7540] 第 10.6 节）与填充的使用（参见 [RFC7540] 第 10.7 节）给出了进一步的建议。若 DoH 客户端在 DNS 查询中提出要求，DoH 服务器还可以添加 DNS 填充 [RFC7830]。关于如何选择填充长度的指导性实验工作可参见 [RFC8467]。

HTTPS 连接为 DoH 服务器与客户端之间的交互提供了传输安全，但它并不提供 DNSSEC 所提供的那种 DNS 数据的响应完整性。DNSSEC 与 DoH 是相互独立且完全兼容的协议，各自解决不同的问题。使用其中之一并不会削弱对另一者的需要或其有用性。客户端可以自行选择：要么对应答执行完整的 DNSSEC 验证，要么信任 DoH 服务器去做 DNSSEC 验证，并检查返回报文中的 AD（Authentic Data，可信数据）位以判定某个应答是否可信。如第 4.2 节所述，不同的响应媒体类型会从 DNS 响应中提供或多或少的信息，因此这一选择可能会受到响应媒体类型的影响。

第 5.1 节描述了本协议与 HTTP 缓存的交互。能够控制客户端所用缓存的攻击者，可以影响该客户端所看到的 DNS 视图。这与 HTTP 缓存对其他使用 HTTP 的协议所带来的安全影响并无不同。

在缺少 DNSSEC 信息的情况下，DoH 服务器可以在响应某个 DNS 查询时向客户端返回无效数据。第 3 节禁止使用并非源自已配置服务器的 DoH DNS 响应。这一禁止规定并不能保证免受无效数据的影响，但确实降低了风险。

10. 运营考虑

本地策略方面的考量及类似因素意味着，不同的 DNS 服务器可能对同一查询给出不同的结果，例如在分离式 DNS（split DNS）配置 [RFC6950] 中。由此在逻辑上可以推出：被查询的服务器能够影响最终结果。因此，客户端对 DNS 服务器的选择可能会影响其查询所得到的响应。例如，在 DNS64 [RFC6147] 的情形下，这一选择可能会影响 IPv6/IPv4 转换能否正常工作。

本规范所使用的 HTTPS 通道在 DoH 客户端与 DoH 服务器之间建立了安全的双方通信。由于 TLS 提供了机密性与完整性保护，那些依赖 DNS 明文传输的过滤或检查系统，将无法在 DNS over HTTPS 环境中运作。

某些 HTTPS 客户端实现会对 TLS 所使用证书的吊销状态执行实时的第三方检查。如果该检查是作为 DoH 服务器连接过程的一部分完成的，而检查本身又需要通过 DNS 解析才能连接到第三方，就可能发生死锁。使用在线证书状态协议（OCSP）[RFC6960] 服务器，或使用颁发机构信息访问（AIA）来获取证书吊销列表（CRL）（参见 [RFC5280] 第 4.2.2.1 节），都是可能引发此类死锁的例子。为缓解死锁的可能性，对给定 DoH 服务器的认证不应（SHOULD NOT）在 TLS 握手中依赖基于 DNS 的外部资源引用。对于 OCSP，服务器可以使用与其 TLS 版本相适应的机制，在握手过程中一并携带证书状态，例如对 TLS 1.3 使用 [RFC8446] 第 4.4.2.1 节。AIA 死锁则可以通过提供那些原本需要额外请求才能获取的中间证书来避免。请注意，对于 DoH 服务器可能重定向到的服务器，也需要考虑这些死锁问题。

当 HTTP 请求需要解析 DNS URI 中的主机名部分时，DoH 客户端可能面临类似的引导（bootstrapping）问题。正如传统 DNS 名称服务器的地址无法最初就从该服务器自身获得一样，DoH 客户端也无法用其 DoH 服务器来最初解析该服务器自身的主机名以获取地址。客户端可采用的替代策略包括：1）将初始解析结果作为配置的一部分；2）使用基于 IP 的 URI 以及相应的、面向 HTTPS 的基于 IP 的证书；或 3）通过传统 DNS 或另一台 DoH 服务器解析该 DNS API 服务器的主机名，同时仍通过 HTTPS 对由此建立的连接进行认证。

HTTP [RFC7230] 是一种无状态的应用层协议，因此 DoH 实现不会在不同请求之间提供有状态的顺序保证。DoH 不能用作其他要求严格顺序的协议的传输。

允许 DoH 服务器以任何有效的 DNS 响应来应答查询。例如，一个有效的 DNS 响应可能在 DNS 报文头中置位 TC（截断）位，以表明服务器未能为该查询获取完整的应答，但提供了它所能得到的最佳应答。对于无法满足的查询，DoH 服务器可以用 HTTP 错误来应答。仍以此为例，DoH 服务器可以使用 HTTP 错误，来替代一个置位了 TC 位的非错误响应。

多年来，人们利用 [RFC6891] 定义了许多 DNS 扩展。那些与传输方式的选择相关的扩展（例如 [RFC7828]）并不适用于 DoH。

11. 参考文献

11.1. 规范性参考文献

11.2. 资料性参考文献

附录 A. 协议的形成过程（Protocol Development）

本附录描述了用于设计 DoH 的各项需求。此处列出这些需求，是为了帮助读者理解当前的协议，而非限制该协议未来可能的发展方向。本附录为非规范性内容。

本文档所描述的协议，其设计基于以下协议需求：

以下内容被视为非需求：

附录 B. DNS over HTTP 或其他格式方面的既往工作

以下是一份并不完整的清单，列出了与 DNS over HTTP/1 或以其他格式表示 DNS 数据相关的早期工作。

该清单中包含指向 tools.ietf.org 站点的链接（因为这些文档均已过期）以及相关软件的网站。

致谢（Acknowledgments）

这项工作需要不同技术领域的专家之间高水平的协作。感谢 Ray Bellis、Stephane Bortzmeyer、Manu Bretelle、Sara Dickinson、Massimiliano Fantuzzi、Tony Finch、Daniel Kahn Gilmor、Olafur Gudmundsson、Wes Hardaker、Rory Hewitt、Joe Hildebrand、David Lawrence、Eliot Lear、John Mattsson、Alex Mayrhofer、Mark Nottingham、Jim Reid、Adam Roach、Ben Schwartz、Davey Song、Daniel Stenberg、Andrew Sullivan、Martin Thomson 以及 Sam Weiler。

作者地址（Authors' Addresses）

Paul Hoffman
ICANN

Email: paul.hoffman@icann.org

Patrick McManus
Mozilla

Email: mcmanus@ducksong.com