Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 8484 ICANN
Category: Standards Track P. McManus
ISSN: 2070-1721 Mozilla
October 2018
Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 8484 ICANN
Category: Standards Track P. McManus
ISSN: 2070-1721 Mozilla
October 2018
DNS Queries over HTTPS (DoH)
HTTPS上的DNS查询（DoH）
Abstract
摘要
This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.
本文档定义了通过HTTPS发送DNS查询和获取DNS响应的协议。每个DNS查询响应对都映射到HTTP交换。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8484.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8484.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Selection of DoH Server . . . . . . . . . . . . . . . . . . . 4
4. The HTTP Exchange . . . . . . . . . . . . . . . . . . . . . . 4
4.1. The HTTP Request . . . . . . . . . . . . . . . . . . . . 4
4.1.1. HTTP Request Examples . . . . . . . . . . . . . . . . 5
4.2. The HTTP Response . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Handling DNS and HTTP Errors . . . . . . . . . . . . 7
4.2.2. HTTP Response Example . . . . . . . . . . . . . . . . 8
5. HTTP Integration . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Cache Interaction . . . . . . . . . . . . . . . . . . . . 8
5.2. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Server Push . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 10
6. Definition of the "application/dns-message" Media Type . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. Registration of the "application/dns-message" Media Type 11
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. On the Wire . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. In the Server . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Operational Considerations . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Protocol Development . . . . . . . . . . . . . . . . 20
Appendix B. Previous Work on DNS over HTTP or in Other Formats . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Selection of DoH Server . . . . . . . . . . . . . . . . . . . 4
4. The HTTP Exchange . . . . . . . . . . . . . . . . . . . . . . 4
4.1. The HTTP Request . . . . . . . . . . . . . . . . . . . . 4
4.1.1. HTTP Request Examples . . . . . . . . . . . . . . . . 5
4.2. The HTTP Response . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Handling DNS and HTTP Errors . . . . . . . . . . . . 7
4.2.2. HTTP Response Example . . . . . . . . . . . . . . . . 8
5. HTTP Integration . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Cache Interaction . . . . . . . . . . . . . . . . . . . . 8
5.2. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Server Push . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 10
6. Definition of the "application/dns-message" Media Type . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. Registration of the "application/dns-message" Media Type 11
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. On the Wire . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. In the Server . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Operational Considerations . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Protocol Development . . . . . . . . . . . . . . . . 20
Appendix B. Previous Work on DNS over HTTP or in Other Formats . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
This document defines a specific protocol, DNS over HTTPS (DoH), for sending DNS [RFC1035] queries and getting DNS responses over HTTP [RFC7540] using https [RFC2818] URIs (and therefore TLS [RFC8446] security for integrity and confidentiality). Each DNS query-response pair is mapped into an HTTP exchange.
本文档定义了一个特定的协议，即HTTPS上的DNS（DoH），用于发送DNS[RFC1035]查询并使用HTTPS[RFC2818]URI通过HTTP[RFC7540]获取DNS响应（因此TLS[RFC8446]安全性用于完整性和机密性）。每个DNS查询响应对都映射到HTTP交换。
The described approach is more than a tunnel over HTTP. It establishes default media formatting types for requests and responses but uses normal HTTP content negotiation mechanisms for selecting alternatives that endpoints may prefer in anticipation of serving new use cases. In addition to this media type negotiation, it aligns itself with HTTP features such as caching, redirection, proxying, authentication, and compression.
所描述的方法不仅仅是HTTP上的隧道。它为请求和响应建立默认的媒体格式类型，但使用正常的HTTP内容协商机制来选择端点在服务新用例时可能更喜欢的替代方案。除了这种媒体类型协商之外，它还与HTTP功能（如缓存、重定向、代理、身份验证和压缩）保持一致。
The integration with HTTP provides a transport suitable for both existing DNS clients and native web applications seeking access to the DNS.
与HTTP的集成提供了适合于现有DNS客户端和寻求访问DNS的本机web应用程序的传输。
Two primary use cases were considered during this protocol's development. These use cases are preventing on-path devices from interfering with DNS operations, and also allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing (CORS) [FETCH]. No special effort has been taken to enable or prevent application to other use cases. This document focuses on communication between DNS clients (such as operating system stub resolvers) and recursive resolvers.
在本协议的开发过程中考虑了两个主要用例。这些用例防止路径上的设备干扰DNS操作，还允许web应用程序通过现有浏览器API以符合跨源资源共享（CORS）[FETCH]的安全方式访问DNS信息。没有采取特别的措施来启用或阻止应用到其他用例。本文档重点介绍DNS客户端（如操作系统存根解析程序）和递归解析程序之间的通信。
A server that supports this protocol is called a "DoH server" to differentiate it from a "DNS server" (one that only provides DNS service over one or more of the other transport protocols standardized for DNS). Similarly, a client that supports this protocol is called a "DoH client".
支持此协议的服务器称为“DoH服务器”，以区别于“DNS服务器”（仅通过DNS标准化的一个或多个其他传输协议提供DNS服务的服务器）。类似地，支持此协议的客户端称为“DoH客户端”。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The DoH client is configured with a URI Template [RFC6570], which describes how to construct the URL to use for resolution. Configuration, discovery, and updating of the URI Template is done out of band from this protocol. Note that configuration might be manual (such as a user typing URI Templates in a user interface for "options") or automatic (such as URI Templates being supplied in responses from DHCP or similar protocols). DoH servers MAY support more than one URI Template. This allows the different endpoints to have different properties, such as different authentication requirements or service-level guarantees.
DoH客户机配置了一个URI模板[RFC6570]，该模板描述了如何构造用于解析的URL。URI模板的配置、发现和更新在此协议的带外完成。请注意，配置可能是手动的（例如用户在用户界面中键入URI模板以获取“选项”），也可能是自动的（例如在DHCP或类似协议的响应中提供的URI模板）。DoH服务器可能支持多个URI模板。这允许不同的端点具有不同的属性，例如不同的身份验证要求或服务级别保证。
A DoH client uses configuration to select the URI, and thus the DoH server, that is to be used for resolution. [RFC2818] defines how HTTPS verifies the DoH server's identity.
DoH客户端使用配置来选择URI，从而选择用于解析的DoH服务器。[RFC2818]定义HTTPS如何验证DoH服务器的身份。
A DoH client MUST NOT use a different URI simply because it was discovered outside of the client's configuration (such as through HTTP/2 server push) or because a server offers an unsolicited response that appears to be a valid answer to a DNS query. This specification does not extend DNS resolution privileges to URIs that are not recognized by the DoH client as configured URIs. Such scenarios may create additional operational, tracking, and security hazards that require limitations for safe usage. A future specification may support this use case.
DoH客户端不能仅仅因为在客户端配置之外（例如通过HTTP/2服务器推送）发现了其他URI，或者因为服务器提供了似乎是DNS查询有效答案的未经请求的响应而使用其他URI。此规范不会将DNS解析权限扩展到DoH客户端无法识别为已配置URI的URI。这种情况可能会造成额外的操作、跟踪和安全危害，需要限制安全使用。未来的规范可能支持此用例。
A DoH client encodes a single DNS query into an HTTP request using either the HTTP GET or POST method and the other requirements of this section. The DoH server defines the URI used by the request through the use of a URI Template.
DoH客户端使用HTTP GET或POST方法以及本节的其他要求将单个DNS查询编码为HTTP请求。DoH服务器通过使用URI模板定义请求使用的URI。
The URI Template defined in this document is processed without any variables when the HTTP method is POST. When the HTTP method is GET, the single variable "dns" is defined as the content of the DNS request (as described in Section 6), encoded with base64url [RFC4648].
当HTTP方法为POST时，此文档中定义的URI模板将在没有任何变量的情况下进行处理。当HTTP方法是GET时，单个变量“dns”被定义为dns请求的内容（如第6节所述），用base64url[RFC4648]编码。
Future specifications for new media types for DoH MUST define the variables used for URI Template processing with this protocol.
DoH新媒体类型的未来规范必须定义此协议用于URI模板处理的变量。
DoH servers MUST implement both the POST and GET methods.
DoH服务器必须同时实现POST和GET方法。
When using the POST method, the DNS query is included as the message body of the HTTP request, and the Content-Type request header field indicates the media type of the message. POSTed requests are generally smaller than their GET equivalents.
使用POST方法时，DNS查询作为HTTP请求的消息体包含，而Content Type request header字段指示消息的媒体类型。已发布的请求通常小于其GET等价项。
Using the GET method is friendlier to many HTTP cache implementations.
使用GET方法对许多HTTP缓存实现更友好。
The DoH client SHOULD include an HTTP Accept request header field to indicate what type of content can be understood in response. Irrespective of the value of the Accept request header field, the client MUST be prepared to process "application/dns-message" (as described in Section 6) responses but MAY also process other DNS-related media types it receives.
DoH客户端应该包含一个HTTP接受请求头字段，以指示响应中可以理解的内容类型。无论Accept request header字段的值如何，客户端都必须准备好处理“应用程序/dns消息”（如第6节所述）响应，但也可以处理其接收的其他dns相关媒体类型。
In order to maximize HTTP cache friendliness, DoH clients using media formats that include the ID field from the DNS message header, such as "application/dns-message", SHOULD use a DNS ID of 0 in every DNS request. HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as "application/dns-message". The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately.
为了最大化HTTP缓存友好性，使用包含DNS消息头中ID字段的媒体格式（如“应用程序/DNS消息”）的DoH客户端应在每个DNS请求中使用0的DNS ID。HTTP将请求和响应关联起来，从而消除了对媒体类型（如“应用程序/dns消息”）中ID的需要。使用不同的DNS ID可能会导致单独缓存语义等效的DNS查询。
DoH clients can use HTTP/2 padding and compression [RFC7540] in the same way that other HTTP/2 clients use (or don't use) them.
DoH客户端可以使用HTTP/2填充和压缩[RFC7540]，与其他HTTP/2客户端使用（或不使用）它们的方式相同。
These examples use HTTP/2-style formatting from [RFC7540].
这些示例使用[RFC7540]中的HTTP/2样式格式。
These examples use a DoH service with a URI Template of "https://dnsserver.example.net/dns-query{?dns}" to resolve IN A records.
这些示例使用URI模板为“”的DoH服务https://dnsserver.example.net/dns-query{？dns}以在记录中解析。
The requests are represented as bodies with media type "application/ dns-message".
请求表示为媒体类型为“应用程序/dns消息”的实体。
The first example request uses GET to request "www.example.com".
第一个示例请求使用GET请求“www.example.com”。
:method = GET
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
accept = application/dns-message
:method = GET
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
accept = application/dns-message
The same DNS query for "www.example.com", using the POST method would be:
使用POST方法对“www.example.com”进行相同的DNS查询将是：
:method = POST
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query
accept = application/dns-message
content-type = application/dns-message
content-length = 33
: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 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
In this example, the 33 bytes are the DNS message in DNS wire format [RFC1035], starting with the DNS header.
在此示例中，33个字节是DNS wire格式[RFC1035]的DNS消息，从DNS头开始。
Finally, a GET-based query for "a.62characterlabel-makes-base64url-distinct-from-standard-base64.example.com" is shown as an example to emphasize that the encoding alphabet of base64url is different than regular base64 and that padding is omitted.
最后，以基于GET的查询“a.62characterlabel-makes-base64url-distinct-from-standard-base64.example.com”为例，强调base64url的编码字母表不同于常规base64，并且省略了填充。
The DNS query, expressed in DNS wire format, is 94 bytes represented by the following:
DNS查询以DNS wire格式表示，为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
00 00 01 00 01 00 00 00 00 01 61 3e 36 32 63 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 6 E 63 74 2d 66 72 6f 6d 2d 73 74 61 6 E 64 61 72 64 2d 62 73 36 34 07 65 78 61 6d 70 6 C 65 03 63 6 F 6 D 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
: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
The only response type defined in this document is "application/dns-message", but it is possible that other response formats will be defined in the future. A DoH server MUST be able to process "application/dns-message" request messages.
本文档中定义的唯一响应类型是“应用程序/dns消息”，但将来可能会定义其他响应格式。DoH服务器必须能够处理“应用程序/dns消息”请求消息。
Different response media types will provide more or less information from a DNS response. For example, one response type might include information from the DNS header bytes while another might omit it. The amount and type of information that a media type gives are solely up to the format, which is not defined in this protocol.
不同的响应媒体类型将提供来自DNS响应的或多或少的信息。例如，一种响应类型可能包含来自DNS头字节的信息，而另一种可能忽略它。媒体类型提供的信息量和类型完全取决于此协议中未定义的格式。
Each DNS request-response pair is mapped to one HTTP exchange. The responses may be processed and transported in any order using HTTP's multi-streaming functionality (see Section 5 of [RFC7540]).
每个DNS请求-响应对映射到一个HTTP交换。可以使用HTTP的多流功能（见[RFC7540]第5节）以任何顺序处理和传输响应。
Section 5.1 discusses the relationship between DNS and HTTP response caching.
第5.1节讨论DNS和HTTP响应缓存之间的关系。
DNS response codes indicate either success or failure for the DNS query. A successful HTTP response with a 2xx status code (see Section 6.3 of [RFC7231]) is used for any valid DNS response, regardless of the DNS response code. For example, a successful 2xx HTTP status code is used even with a DNS message whose DNS response code indicates failure, such as SERVFAIL or NXDOMAIN.
DNS响应代码表示DNS查询成功或失败。具有2xx状态代码的成功HTTP响应（见[RFC7231]第6.3节）用于任何有效的DNS响应，而不管DNS响应代码如何。例如，即使DNS响应代码指示失败的DNS消息（如SERVFAIL或NXDOMAIN），也会使用成功的2xx HTTP状态代码。
HTTP responses with non-successful HTTP status codes do not contain replies to the original DNS question in the HTTP request. DoH clients need to use the same semantic processing of non-successful HTTP status codes as other HTTP clients. This might mean that the DoH client retries the query with the same DoH server, such as if there are authorization failures (HTTP status code 401; see Section 3.1 of [RFC7235]). It could also mean that the DoH client retries with a different DoH server, such as for unsupported media types (HTTP status code 415; see Section 6.5.13 of [RFC7231]), or where the server cannot generate a representation suitable for the client (HTTP status code 406; see Section 6.5.6 of [RFC7231]), and so on.
具有非成功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节），等等。
This is an example response for a query for the IN AAAA records for "www.example.com" with recursion turned on. The response bears one answer record with an address of 2001:db8:abcd:12:1:2:3:4 and a TTL of 3709 seconds.
这是一个示例响应，用于查询“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
: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
<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
This protocol MUST be used with the https URI scheme [RFC7230].
此协议必须与https URI方案[RFC7230]一起使用。
Sections 8 and 9 discuss additional considerations for the integration with HTTP.
第8节和第9节讨论了与HTTP集成的其他注意事项。
A DoH exchange can pass through a hierarchy of caches that include both HTTP- and DNS-specific caches. These caches may exist between the DoH server and client, or they may exist on the DoH client itself. HTTP caches are generic by design; that is, they do not understand this protocol. Even if a DoH client has modified its cache implementation to be aware of DoH semantics, it does not follow that all upstream caches (for example, inline proxies, server-side gateways, and content delivery networks) will be.
DoH交换可以通过包含HTTP和DNS特定缓存的缓存层次结构。这些缓存可能存在于DoH服务器和客户端之间，也可能存在于DoH客户端本身上。HTTP缓存在设计上是通用的；也就是说，他们不理解这个协议。即使DoH客户机修改了其缓存实现以了解DoH语义，也不意味着所有上游缓存（例如，内联代理、服务器端网关和内容交付网络）都将被删除。
As a result, DoH servers need to carefully consider the HTTP caching metadata they send in response to GET requests (responses to POST requests are not cacheable unless specific response header fields are sent; this is not widely implemented and is not advised for DoH).
因此，DOH服务器需要仔细考虑响应于GET请求发送的HTTP缓存元数据（对POST请求的响应不是可缓存的，除非发送特定的响应头字段；这不是广泛实现的，并且不建议DOH）。
In particular, DoH servers SHOULD assign an explicit HTTP freshness lifetime (see Section 4.2 of [RFC7234]) so that the DoH client is more likely to use fresh DNS data. This requirement is due to HTTP caches being able to assign their own heuristic freshness (such as that described in Section 4.2.2 of [RFC7234]), which would take control of the cache contents out of the hands of the DoH server.
特别是，DoH服务器应该分配一个明确的HTTP刷新生存期（请参见[RFC7234]第4.2节），以便DoH客户端更可能使用新的DNS数据。这一要求是由于HTTP缓存能够分配自己的启发式新鲜度（如[RFC7234]第4.2.2节所述），这将使缓存内容的控制权脱离DoH服务器的控制。
The assigned freshness lifetime of a DoH HTTP response MUST be less than or equal to the smallest TTL in the Answer section of the DNS response. A freshness lifetime equal to the smallest TTL in the Answer section is RECOMMENDED. For example, if a HTTP response carries three RRsets with TTLs of 30, 600, and 300, the HTTP freshness lifetime should be 30 seconds (which could be specified as "Cache-Control: max-age=30"). This requirement helps prevent expired RRsets in messages in an HTTP cache from unintentionally being served.
指定的DoH HTTP响应的新鲜度生存期必须小于或等于DNS响应的应答部分中的最小TTL。建议新鲜度寿命等于答案部分中最小的TTL。例如，如果HTTP响应包含三个RRSET，TTL分别为30、600和300，则HTTP新鲜度生存期应为30秒（可以指定为“缓存控制：max age=30”）。此要求有助于防止HTTP缓存中的消息中过期的RRSET被无意中提供。
If the DNS response has no records in the Answer section, and the DNS response has an SOA record in the Authority section, the response freshness lifetime MUST NOT be greater than the MINIMUM field from that SOA record (see [RFC2308]).
如果DNS响应在应答部分中没有记录，并且DNS响应在授权部分中有SOA记录，则响应新鲜度生存期不得大于该SOA记录中的最小字段（请参见[RFC2308]）。
The stale-while-revalidate and stale-if-error Cache-Control directives [RFC5861] could be well suited to a DoH implementation when allowed by server policy. Those mechanisms allow a client, at the server's discretion, to reuse an HTTP cache entry that is no longer fresh. In such a case, the client reuses either all of a cached entry or none of it.
当服务器策略允许时，stale while revalidate和stale if error Cache Control指令[RFC5861]可能非常适合DoH实现。这些机制允许客户端根据服务器的判断重用不再新鲜的HTTP缓存项。在这种情况下，客户机重用所有缓存项，或者不重用任何缓存项。
DoH servers also need to consider HTTP caching when generating responses that are not globally valid. For instance, if a DoH server customizes a response based on the client's identity, it would not want to allow global reuse of that response. This could be accomplished through a variety of HTTP techniques, such as a Cache-Control max-age of 0, or by using the Vary response header field (see Section 7.1.4 of [RFC7231]) to establish a secondary cache key (see Section 4.1 of [RFC7234]).
当生成不全局有效的响应时，DOH服务器也需要考虑HTTP缓存。例如，如果DoH服务器根据客户机的标识自定义响应，它将不希望全局重用该响应。这可以通过各种HTTP技术来实现，例如缓存控制最大年龄为0，或者通过使用Vary response header字段（参见[RFC7231]第7.1.4节）来建立辅助缓存密钥（参见[RFC7234]第4.1节）。
DoH clients MUST account for the Age response header field's value [RFC7234] when calculating the DNS TTL of a response. For example, if an RRset is received with a DNS TTL of 600, but the Age header field indicates that the response has been cached for 250 seconds, the remaining lifetime of the RRset is 350 seconds. This requirement applies to both DoH client HTTP caches and DoH client DNS caches.
在计算响应的DNS TTL时，DoH客户端必须考虑年龄响应头字段的值[RFC7234]。例如，如果接收到的RRset的DNS TTL为600，但Age头字段指示响应已缓存250秒，则RRset的剩余生存期为350秒。此要求同时适用于DoH客户端HTTP缓存和DoH客户端DNS缓存。
DoH clients can request an uncached copy of a HTTP response by using the "no-cache" request Cache-Control directive (see Section 5.2.1.4 of [RFC7234]) and similar controls. Note that some caches might not honor these directives, either due to configuration or interaction with traditional DNS caches that do not have such a mechanism.
DoH客户端可以通过使用“无缓存”请求缓存控制指令（参见[RFC7234]第5.2.1.4节）和类似控制来请求HTTP响应的未缓存副本。请注意，由于配置或与不具有此类机制的传统DNS缓存的交互，某些缓存可能不遵守这些指令。
HTTP conditional requests [RFC7232] may be of limited value to DoH, as revalidation provides only a bandwidth benefit and DNS transactions are normally latency bound. Furthermore, the HTTP response header fields that enable revalidation (such as "Last-
HTTP条件请求[RFC7232]对DoH的价值可能有限，因为重新验证只提供带宽优势，DNS事务通常受延迟限制。此外，启用重新验证的HTTP响应头字段（例如“Last”）-
Modified" and "Etag") are often fairly large when compared to the overall DNS response size and have a variable nature that creates constant pressure on the HTTP/2 compression dictionary [RFC7541]. Other types of DNS data, such as zone transfers, may be larger and benefit more from revalidation.
与总体DNS响应大小相比，“修改”和“Etag”）通常相当大，并且具有可变性质，对HTTP/2压缩字典[RFC7541]造成恒定压力。其他类型的DNS数据（如区域传输）可能更大，并从重新验证中获益更多。
HTTP/2 [RFC7540] is the minimum RECOMMENDED version of HTTP for use with DoH.
HTTP/2[RFC7540]是用于DoH的HTTP的最低推荐版本。
The messages in classic UDP-based DNS [RFC1035] are inherently unordered and have low overhead. A competitive HTTP transport needs to support reordering, parallelism, priority, and header compression to achieve similar performance. Those features were introduced to HTTP in HTTP/2 [RFC7540]. Earlier versions of HTTP are capable of conveying the semantic requirements of DoH but may result in very poor performance.
经典的基于UDP的DNS[RFC1035]中的消息本质上是无序的，开销很低。有竞争力的HTTP传输需要支持重新排序、并行性、优先级和头压缩，以实现类似的性能。这些特性是在HTTP/2[RFC7540]中引入HTTP的。早期版本的HTTP能够传达DoH的语义需求，但可能会导致非常差的性能。
Before using DoH response data for DNS resolution, the client MUST establish that the HTTP request URI can be used for the DoH query. For HTTP requests initiated by the DoH client, this is implicit in the selection of URI. For HTTP server push (see Section 8.2 of [RFC7540]), extra care must be taken to ensure that the pushed URI is one that the client would have directed the same query to if the client had initiated the request (in addition to the other security checks normally needed for server push).
在使用DoH响应数据进行DNS解析之前，客户端必须确定HTTP请求URI可用于DoH查询。对于DoH客户机发起的HTTP请求，这在URI的选择中是隐含的。对于HTTP服务器推送（请参阅[RFC7540]第8.2节），必须格外小心，以确保推送的URI是客户端启动请求时会将相同查询指向的URI（除了服务器推送通常需要的其他安全检查）。
In order to maximize interoperability, DoH clients and DoH servers MUST support the "application/dns-message" media type. Other media types MAY be used as defined by HTTP Content Negotiation (see Section 3.4 of [RFC7231]). Those media types MUST be flexible enough to express every DNS query that would normally be sent in DNS over UDP (including queries and responses that use DNS extensions, but not those that require multiple responses).
为了最大限度地提高互操作性，DoH客户端和DoH服务器必须支持“应用程序/dns消息”媒体类型。可使用HTTP内容协商定义的其他媒体类型（见[RFC7231]第3.4节）。这些媒体类型必须足够灵活，以表达通常通过UDP在DNS中发送的每个DNS查询（包括使用DNS扩展的查询和响应，但不包括需要多个响应的查询和响应）。
The data payload for the "application/dns-message" media type is a single message of the DNS on-the-wire format defined in Section 4.2.1 of [RFC1035], which in turn refers to the full wire format defined in Section 4.1 of that RFC.
“应用程序/dns消息”媒体类型的数据有效负载是[RFC1035]第4.2.1节中定义的有线格式上的dns的单个消息，这反过来又指该RFC第4.1节中定义的完整有线格式。
Although [RFC1035] says "Messages carried by UDP are restricted to 512 bytes", that was later updated by [RFC6891]. This media type restricts the maximum size of the DNS message to 65535 bytes.
虽然[RFC1035]说“UDP承载的消息限制为512字节”，但后来由[RFC6891]更新。此媒体类型将DNS消息的最大大小限制为65535字节。
Note that the wire format used in this media type is different than the wire format used in [RFC7858] (which uses the format defined in Section 4.2.2 of [RFC1035] that includes two length bytes).
请注意，此媒体类型中使用的有线格式与[RFC7858]中使用的有线格式不同（后者使用[RFC1035]第4.2.2节中定义的格式，包括两个长度字节）。
DoH clients using this media type MAY have one or more Extension Mechanisms for DNS (EDNS) options [RFC6891] in the request. DoH servers using this media type MUST ignore the value given for the EDNS UDP payload size in DNS requests.
使用此媒体类型的DoH客户端在请求中可能有一个或多个DNS（EDNS）选项[RFC6891]扩展机制。使用此媒体类型的DoH服务器必须忽略DNS请求中为EDNS UDP有效负载大小给定的值。
When using the GET method, the data payload for this media type MUST be encoded with base64url [RFC4648] and then provided as a variable named "dns" to the URI Template expansion. Padding characters for base64url MUST NOT be included.
使用GET方法时，必须使用base64url[RFC4648]对该媒体类型的数据有效负载进行编码，然后将其作为名为“dns”的变量提供给URI模板扩展。不得包含base64url的填充字符。
When using the POST method, the data payload for this media type MUST NOT be encoded and is used directly as the HTTP message body.
使用POST方法时，此媒体类型的数据有效负载不得进行编码，而是直接用作HTTP消息体。
Type name: application
类型名称：应用程序
Subtype name: dns-message
子类型名称：dns消息
Required parameters: N/A
所需参数：不适用
Optional parameters: N/A
可选参数：不适用
Encoding considerations: This is a binary format. The contents are a DNS message as defined in RFC 1035. The format used here is for DNS over UDP, which is the format defined in the diagrams in RFC 1035.
编码注意事项：这是一种二进制格式。内容是RFC 1035中定义的DNS消息。此处使用的格式用于UDP上的DNS，这是RFC 1035中图表中定义的格式。
Security considerations: See RFC 8484. The content is a DNS message and thus not executable code.
安全注意事项：参见RFC 8484。内容是DNS消息，因此不是可执行代码。
Interoperability considerations: None.
互操作性考虑：无。
Published specification: RFC 8484.
已发布规范：RFC 8484。
Applications that use this media type: Systems that want to exchange full DNS messages.
使用此媒体类型的应用程序：希望交换完整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
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>
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>
Author: Paul Hoffman <paul.hoffman@icann.org>
Change controller: IESG
更改控制器：IESG
[RFC7626] discusses DNS privacy considerations in both "on the wire" (Section 2.4 of [RFC7626]) and "in the server" (Section 2.5 of [RFC7626]) contexts. This is also a useful framing for DoH's privacy considerations.
[RFC7626]讨论了“在线”（RFC7626的第2.4节）和“服务器”（RFC7626的第2.5节）上下文中的DNS隐私注意事项。这也是DoH隐私考虑的有用框架。
DoH encrypts DNS traffic and requires authentication of the server. This mitigates both passive surveillance [RFC7258] and active attacks that attempt to divert DNS traffic to rogue servers (see Section 2.5.1 of [RFC7626]). DNS over TLS [RFC7858] provides similar protections, while direct UDP- and TCP-based transports are vulnerable to this class of attack. An experimental effort to offer guidance on choosing the padding length can be found in [RFC8467].
DoH加密DNS流量，并要求对服务器进行身份验证。这缓解了被动监视[RFC7258]和主动攻击，这些攻击试图将DNS流量转移到恶意服务器（请参见[RFC7626]第2.5.1节）。TLS上的DNS[RFC7858]提供类似的保护，而基于UDP和TCP的直接传输容易受到此类攻击。可在[RFC8467]中找到为选择填充长度提供指导的实验工作。
Additionally, the use of the HTTPS default port 443 and the ability to mix DoH traffic with other HTTPS traffic on the same connection can deter unprivileged on-path devices from interfering with DNS operations and make DNS traffic analysis more difficult.
此外，HTTPS默认端口443的使用以及在同一连接上将DoH流量与其他HTTPS流量混合的能力可以阻止路径上的非特权设备干扰DNS操作，并使DNS流量分析更加困难。
The DNS wire format [RFC1035] contains no client identifiers; however, various transports of DNS queries and responses do provide data that can be used to correlate requests. HTTPS presents new considerations for correlation, such as explicit HTTP cookies and implicit fingerprinting of the unique set and ordering of HTTP request header fields.
DNS wire格式[RFC1035]不包含客户端标识符；然而，DNS查询和响应的各种传输确实提供了可用于关联请求的数据。HTTPS为相关性提供了新的考虑因素，例如显式HTTP cookie和唯一集的隐式指纹以及HTTP请求头字段的顺序。
A DoH implementation is built on IP, TCP, TLS, and HTTP. Each layer contains one or more common features that can be used to correlate queries to the same identity. DNS transports will generally carry the same privacy properties of the layers used to implement them. For example, the properties of IP, TCP, and TLS apply to implementations of DNS over TLS.
DoH实现构建在IP、TCP、TLS和HTTP上。每个层包含一个或多个公共特征，可用于将查询与同一标识关联起来。DNS传输通常与用于实现它们的层具有相同的隐私属性。例如，IP、TCP和TLS的属性适用于DNS over TLS的实现。
The privacy considerations of using the HTTPS layer in DoH are incremental to those of DNS over TLS. DoH is not known to introduce new concerns beyond those associated with HTTPS.
在DoH中使用HTTPS层的隐私注意事项比DNS over TLS的隐私注意事项要多。除了与HTTPS相关的问题外，DoH还没有引入新的问题。
At the IP level, the client address provides obvious correlation information. This can be mitigated by use of a NAT, proxy, VPN, or simple address rotation over time. It may be aggravated by use of a DNS server that can correlate real-time addressing information with other personal identifiers, such as when a DNS server and DHCP server are operated by the same entity.
在IP级别，客户端地址提供了明显的相关信息。这可以通过使用NAT、代理、VPN或随时间的简单地址轮换来缓解。使用能够将实时寻址信息与其他个人标识符相关联的DNS服务器（例如当DNS服务器和DHCP服务器由同一实体操作时）可能会加剧这种情况。
DNS implementations that use one TCP connection for multiple DNS requests directly group those requests. Long-lived connections have better performance behaviors than short-lived connections; however, they group more requests, which can expose more information to correlation and consolidation. TCP-based solutions may also seek performance through the use of TCP Fast Open [RFC7413]. The cookies used in TCP Fast Open allow servers to correlate TCP sessions.
对多个DNS请求使用一个TCP连接的DNS实现直接对这些请求进行分组。长寿命连接比短命连接具有更好的性能行为；但是，它们对更多的请求进行分组，这可以将更多的信息公开给关联和整合。基于TCP的解决方案也可以通过使用TCP Fast Open[RFC7413]来寻求性能。TCP Fast Open中使用的Cookie允许服务器关联TCP会话。
TLS-based implementations often achieve better handshake performance through the use of some form of session resumption mechanism, such as Section 2.2 of [RFC8446]. Session resumption creates trivial mechanisms for a server to correlate TLS connections together.
基于TLS的实现通常通过使用某种形式的会话恢复机制来实现更好的握手性能，如[RFC8446]的第2.2节。会话恢复为服务器创建了将TLS连接关联在一起的简单机制。
HTTP's feature set can also be used for identification and tracking in a number of different ways. For example, Authentication request header fields explicitly identify profiles in use, and HTTP cookies are designed as an explicit state-tracking mechanism between the client and serving site and often are used as an authentication mechanism.
HTTP的功能集还可以通过多种不同的方式用于识别和跟踪。例如，身份验证请求头字段显式标识正在使用的配置文件，HTTP Cookie被设计为客户端和服务站点之间的显式状态跟踪机制，通常用作身份验证机制。
Additionally, the User-Agent and Accept-Language request header fields often convey specific information about the client version or locale. This facilitates content negotiation and operational work-arounds for implementation bugs. Request header fields that control caching can expose state information about a subset of the client's history. Mixing DoH requests with other HTTP requests on the same connection also provides an opportunity for richer data correlation.
此外，User Agent和Accept Language请求头字段通常传递有关客户端版本或区域设置的特定信息。这有助于内容协商和解决实施缺陷的操作问题。控制缓存的请求头字段可以公开有关客户端历史记录子集的状态信息。将DoH请求与同一连接上的其他HTTP请求混合使用，还提供了更丰富的数据关联的机会。
The DoH protocol design allows applications to fully leverage the HTTP ecosystem, including features that are not enumerated here. Utilizing the full set of HTTP features enables DoH to be more than an HTTP tunnel, but it is at the cost of opening up implementations to the full set of privacy considerations of HTTP.
DoH协议设计允许应用程序充分利用HTTP生态系统，包括此处未列举的功能。利用全套HTTP特性使DoH不仅仅是一个HTTP隧道，但它的代价是向HTTP的全套隐私考虑开放实现。
Implementations of DoH clients and servers need to consider the benefit and privacy impact of these features, and their deployment context, when deciding whether or not to enable them. Implementations are advised to expose the minimal set of data needed to achieve the desired feature set.
DOH客户端和服务器的实现需要考虑这些特征的好处和隐私影响以及它们的部署上下文，当决定是否启用它们时。建议实现公开实现所需功能集所需的最小数据集。
Determining whether or not a DoH implementation requires HTTP cookie [RFC6265] support is particularly important because HTTP cookies are the primary state tracking mechanism in HTTP. HTTP cookies SHOULD NOT be accepted by DOH clients unless they are explicitly required by a use case.
确定DoH实现是否需要HTTP cookie[RFC6265]支持特别重要，因为HTTP cookie是HTTP中的主要状态跟踪机制。除非用例明确要求，否则DOH客户端不应接受HTTP cookie。
Running DNS over HTTPS relies on the security of the underlying HTTP transport. This mitigates classic amplification attacks for UDP-based DNS. Implementations utilizing HTTP/2 benefit from the TLS profile defined in Section 9.2 of [RFC7540].
通过HTTPS运行DNS依赖于底层HTTP传输的安全性。这缓解了基于UDP的DNS的经典放大攻击。使用HTTP/2的实现受益于[RFC7540]第9.2节中定义的TLS配置文件。
Session-level encryption has well-known weaknesses with respect to traffic analysis, which might be particularly acute when dealing with DNS queries. HTTP/2 provides further advice about the use of compression (see Section 10.6 of [RFC7540]) and padding (see Section 10.7 of [RFC7540]). DoH servers can also add DNS padding [RFC7830] if the DoH client requests it in the DNS query. An experimental effort to offer guidance on choosing the padding length can be found in [RFC8467].
会话级加密在流量分析方面存在众所周知的弱点，这在处理DNS查询时可能特别严重。HTTP/2提供了有关压缩（见[RFC7540]第10.6节）和填充（见[RFC7540]第10.7节）使用的进一步建议。如果DoH客户端在DNS查询中请求，DoH服务器还可以添加DNS填充[RFC7830]。可在[RFC8467]中找到为选择填充长度提供指导的实验工作。
The HTTPS connection provides transport security for the interaction between the DoH server and client, but it does not provide the response integrity of DNS data provided by DNSSEC. DNSSEC and DoH are independent and fully compatible protocols, each solving different problems. The use of one does not diminish the need nor the usefulness of the other. It is the choice of a client to either perform full DNSSEC validation of answers or to trust the DoH server to do DNSSEC validation and inspect the AD (Authentic Data) bit in the returned message to determine whether an answer was authentic or not. As noted in Section 4.2, different response media types will provide more or less information from a DNS response, so this choice may be affected by the response media type.
HTTPS连接为DoH服务器和客户端之间的交互提供传输安全性，但不提供DNSSEC提供的DNS数据的响应完整性。DNSSEC和DoH是独立且完全兼容的协议，各自解决不同的问题。使用其中一个并不会减少对另一个的需求或效用。客户端可以选择对答案执行完整的DNSSEC验证，或者信任DoH服务器进行DNSSEC验证，并检查返回消息中的AD（真实数据）位，以确定答案是否真实。如第4.2节所述，不同的响应介质类型将提供来自DNS响应的或多或少的信息，因此此选择可能会受到响应介质类型的影响。
Section 5.1 describes the interaction of this protocol with HTTP caching. An adversary that can control the cache used by the client can affect that client's view of the DNS. This is no different than the security implications of HTTP caching for other protocols that use HTTP.
第5.1节描述了此协议与HTTP缓存的交互。可以控制客户端使用的缓存的对手可以影响该客户端对DNS的查看。这与HTTP缓存对使用HTTP的其他协议的安全影响没有什么不同。
In the absence of DNSSEC information, a DoH server can give a client invalid data in response to a DNS query. Section 3 disallows the use of DoH DNS responses that do not originate from configured servers. This prohibition does not guarantee protection against invalid data, but it does reduce the risk.
在缺少DNSSEC信息的情况下，DoH服务器可以向客户端提供无效数据以响应DNS查询。第3节禁止使用非源于已配置服务器的DoH DNS响应。这项禁令并不能保证对无效数据的保护，但它确实降低了风险。
Local policy considerations and similar factors mean different DNS servers may provide different results to the same query, for instance, in split DNS configurations [RFC6950]. It logically follows that the server that is queried can influence the end result. Therefore, a client's choice of DNS server may affect the responses it gets to its queries. For example, in the case of DNS64 [RFC6147], the choice could affect whether IPv6/IPv4 translation will work at all.
本地策略考虑因素和类似因素意味着不同的DNS服务器可能会为同一查询提供不同的结果，例如，在拆分DNS配置中[RFC6950]。从逻辑上讲，被查询的服务器可以影响最终结果。因此，客户端对DNS服务器的选择可能会影响其对查询的响应。例如，在DNS64[RFC6147]的情况下，该选择可能会影响IPv6/IPv4转换是否能够工作。
The HTTPS channel used by this specification establishes secure two-party communication between the DoH client and the DoH server. Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment due to the confidentiality and integrity protection provided by TLS.
本规范使用的HTTPS通道在DoH客户端和DoH服务器之间建立安全的第二方通信。由于TLS提供的机密性和完整性保护，依赖DNS不安全传输的过滤或检查系统将无法在DNS over HTTPS环境中运行。
Some HTTPS client implementations perform real time third-party checks of the revocation status of the certificates being used by TLS. If this check is done as part of the DoH server connection procedure and the check itself requires DNS resolution to connect to the third party, a deadlock can occur. The use of Online Certificate Status Protocol (OCSP) [RFC6960] servers or Authority Information Access (AIA) for Certificate Revocation List (CRL) fetching (see Section 4.2.2.1 of [RFC5280]) are examples of how this deadlock can happen. To mitigate the possibility of deadlock, the authentication given DoH servers SHOULD NOT rely on DNS-based references to external resources in the TLS handshake. For OCSP, the server can bundle the certificate status as part of the handshake using a mechanism appropriate to the version of TLS, such as using Section 4.4.2.1 of [RFC8446] for TLS version 1.3. AIA deadlocks can be avoided by providing intermediate certificates that might otherwise be obtained through additional requests. Note that these deadlocks also need to be considered for servers that a DoH server might redirect to.
一些HTTPS客户端实现对TLS使用的证书的吊销状态执行实时第三方检查。如果此检查作为DoH服务器连接过程的一部分进行，并且检查本身需要DNS解析才能连接到第三方，则可能发生死锁。使用在线证书状态协议（OCSP）[RFC6960]服务器或授权信息访问（AIA）获取证书吊销列表（CRL）（见[RFC5280]第4.2.2.1节）就是此类死锁发生的示例。为了减少死锁的可能性，给定的DoH服务器的身份验证不应依赖于TLS握手中对外部资源的基于DNS的引用。对于OCSP，服务器可以使用适用于TLS版本的机制将证书状态捆绑为握手的一部分，例如使用[RFC8446]第4.4.2.1节（适用于TLS版本1.3）。AIA可以通过提供中间证书来避免死锁，而中间证书可以通过其他请求获得。注意，DoH服务器可能重定向到的服务器也需要考虑这些死锁。
A DoH client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI. Just as the address of a traditional DNS nameserver cannot be originally determined from that same server, a DoH client cannot use its DoH server to initially resolve the server's host name into an address. Alternative strategies a client might employ include 1) making the initial resolution part of the configuration, 2) IP-based URIs and corresponding IP-based certificates for HTTPS, or 3) resolving the DNS API server's hostname via traditional DNS or another DoH server while still authenticating the resulting connection via HTTPS.
当HTTP请求需要解析DNS URI的主机名部分时，DoH客户端可能会面临类似的引导问题。正如传统DNS名称服务器的地址最初无法从同一服务器确定一样，DoH客户端也无法使用其DoH服务器将服务器的主机名最初解析为地址。客户端可能采用的替代策略包括1）使初始解析成为配置的一部分，2）基于IP的URI和对应的基于IP的HTTPS证书，或3）通过传统DNS或另一个DoH服务器解析DNS API服务器的主机名，同时仍然通过HTTPS验证生成的连接。
HTTP [RFC7230] is a stateless application-level protocol, and therefore DoH implementations do not provide stateful ordering guarantees between different requests. DoH cannot be used as a transport for other protocols that require strict ordering.
HTTP[RFC7230]是一种无状态应用程序级协议，因此DoH实现不提供不同请求之间的有状态排序保证。DoH不能用作需要严格排序的其他协议的传输。
A DoH server is allowed to answer queries with any valid DNS response. For example, a valid DNS response might have the TC (truncation) bit set in the DNS header to indicate that the server was not able to retrieve a full answer for the query but is providing the best answer it could get. A DoH server can reply to queries with an HTTP error for queries that it cannot fulfill. In this same example, a DoH server could use an HTTP error instead of a non-error response that has the TC bit set.
允许DoH服务器使用任何有效的DNS响应回答查询。例如，有效的DNS响应可能在DNS标头中设置了TC（截断）位，以指示服务器无法检索查询的完整答案，但提供了它可以获得的最佳答案。对于无法完成的查询，DoH服务器可以答复带有HTTP错误的查询。在同一示例中，DoH服务器可以使用HTTP错误而不是设置了TC位的非错误响应。
Many extensions to DNS, using [RFC6891], have been defined over the years. Extensions that are specific to the choice of transport, such as [RFC7828], are not applicable to DoH.
多年来，已经使用[RFC6891]定义了许多DNS扩展。特定于传输选择的扩展，如[RFC7828]，不适用于DoH。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, <https://www.rfc-editor.org/info/rfc2308>.
[RFC2308]Andrews，M.“DNS查询的反向缓存（DNS NCACHE）”，RFC 2308，DOI 10.17487/RFC2308，1998年3月<https://www.rfc-editor.org/info/rfc2308>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<https://www.rfc-editor.org/info/rfc4648>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.
[RFC6265]Barth，A.，“HTTP状态管理机制”，RFC 6265，DOI 10.17487/RFC6265，2011年4月<https://www.rfc-editor.org/info/rfc6265>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <https://www.rfc-editor.org/info/rfc6570>.
[RFC6570]Gregorio，J.，Fielding，R.，Hadley，M.，Nottingham，M.，和D.Orchard，“URI模板”，RFC 6570，DOI 10.17487/RFC657012年3月<https://www.rfc-editor.org/info/rfc6570>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<https://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <https://www.rfc-editor.org/info/rfc7232>.
[RFC7232]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：有条件请求”，RFC 7232，DOI 10.17487/RFC72322014年6月<https://www.rfc-editor.org/info/rfc7232>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC7234]Fielding，R.，Ed.，Nottingham，M.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：缓存”，RFC 7234，DOI 10.17487/RFC72342014年6月<https://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <https://www.rfc-editor.org/info/rfc7235>.
[RFC7235]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：认证”，RFC 7235，DOI 10.17487/RFC7235，2014年6月<https://www.rfc-editor.org/info/rfc7235>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[RFC7540]Belshe，M.，Paon，R.，和M.Thomson，编辑，“超文本传输协议版本2（HTTP/2）”，RFC 7540，DOI 10.17487/RFC7540，2015年5月<https://www.rfc-editor.org/info/rfc7540>.
[RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, <https://www.rfc-editor.org/info/rfc7541>.
[RFC7541]Paun，R.和H.Ruellan，“HPACK：HTTP/2的报头压缩”，RFC 7541，DOI 10.17487/RFC7541，2015年5月<https://www.rfc-editor.org/info/rfc7541>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, <https://www.rfc-editor.org/info/rfc7626>.
[RFC7626]Bortzmeyer，S.，“DNS隐私注意事项”，RFC 7626，DOI 10.17487/RFC7626，2015年8月<https://www.rfc-editor.org/info/rfc7626>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
[FETCH] "Fetch Living Standard", August 2018, <https://fetch.spec.whatwg.org/>.
[FETCH]“FETCH Living Standard”，2018年8月<https://fetch.spec.whatwg.org/>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<https://www.rfc-editor.org/info/rfc2818>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, <https://www.rfc-editor.org/info/rfc5861>.
[RFC5861]诺丁汉，M.，“过时内容的HTTP缓存控制扩展”，RFC 5861，DOI 10.17487/RFC5861，2010年5月<https://www.rfc-editor.org/info/rfc5861>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011, <https://www.rfc-editor.org/info/rfc6147>.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.van Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 6147，DOI 10.17487/RFC6147，2011年4月<https://www.rfc-editor.org/info/rfc6147>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>.
[RFC6891]Damas，J.，Graff，M.，和P.Vixie，“DNS的扩展机制（EDNS（0）），STD 75，RFC 6891，DOI 10.17487/RFC68911913年4月<https://www.rfc-editor.org/info/rfc6891>.
[RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, "Architectural Considerations on Application Features in the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, <https://www.rfc-editor.org/info/rfc6950>.
[RFC6950]Peterson，J.，Kolkman，O.，Tschofenig，H.，和B.Aboba，“DNS中应用程序功能的架构考虑”，RFC 6950，DOI 10.17487/RFC6950，2013年10月<https://www.rfc-editor.org/info/rfc6950>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[RFC6960]Santesson，S.，Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 6960，DOI 10.17487/RFC6960，2013年6月<https://www.rfc-editor.org/info/rfc6960>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，DOI 10.17487/RFC7258，2014年5月<https://www.rfc-editor.org/info/rfc7258>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.
[RFC7413]Cheng，Y.，Chu，J.，Radhakrishnan，S.，和A.Jain，“TCP快速开放”，RFC 7413，DOI 10.17487/RFC74132014年12月<https://www.rfc-editor.org/info/rfc7413>.
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/RFC7828, April 2016, <https://www.rfc-editor.org/info/rfc7828>.
[RFC7828]Wouters，P.，Abley，J.，Dickinson，S.，和R.Bellis，“edns tcp keepalive EDNS0选项”，RFC 7828，DOI 10.17487/RFC78282016年4月<https://www.rfc-editor.org/info/rfc7828>.
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, DOI 10.17487/RFC7830, May 2016, <https://www.rfc-editor.org/info/rfc7830>.
[RFC7830]Mayrhofer，A.，“EDNS（0）填充选项”，RFC 7830，DOI 10.17487/RFC7830，2016年5月<https://www.rfc-editor.org/info/rfc7830>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7858]Hu，Z.，Zhu，L.，Heidemann，J.，Mankin，A.，Wessels，D.，和P.Hoffman，“DNS传输层安全规范（TLS）”，RFC 7858，DOI 10.17487/RFC7858，2016年5月<https://www.rfc-editor.org/info/rfc7858>.
[RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, October 2018, <https://www.rfc-editor.org/info/rfc8467>.
[RFC8467]Mayrhofer，A.“DNS（EDNS（0））扩展机制的填充策略”，RFC 8467，DOI 10.17487/RFC8467，2018年10月<https://www.rfc-editor.org/info/rfc8467>.
This appendix describes the requirements used to design DoH. These requirements are listed here to help readers understand the current protocol, not to limit how the protocol might be developed in the future. This appendix is non-normative.
本附录描述了用于设计DoH的要求。这里列出这些要求是为了帮助读者理解当前的协议，而不是限制将来如何开发协议。本附录为非规范性附录。
The protocol described in this document based its design on the following protocol requirements:
本文件中描述的协议基于以下协议要求进行设计：
o The protocol must use normal HTTP semantics.
o 协议必须使用正常的HTTP语义。
o The queries and responses must be able to be flexible enough to express every DNS query that would normally be sent in DNS over UDP (including queries and responses that use DNS extensions, but not those that require multiple responses).
o 查询和响应必须足够灵活，以表达通常通过UDP在DNS中发送的每个DNS查询（包括使用DNS扩展的查询和响应，但不包括需要多个响应的查询和响应）。
o The protocol must permit the addition of new formats for DNS queries and responses.
o 协议必须允许为DNS查询和响应添加新格式。
o The protocol must ensure interoperability by specifying a single format for requests and responses that is mandatory to implement. That format must be able to support future modifications to the DNS protocol including the inclusion of one or more EDNS options (including those not yet defined).
o 协议必须通过为强制实现的请求和响应指定单一格式来确保互操作性。该格式必须能够支持将来对DNS协议的修改，包括包含一个或多个EDN选项（包括尚未定义的选项）。
o The protocol must use a secure transport that meets the requirements for HTTPS.
o 协议必须使用满足HTTPS要求的安全传输。
The following were considered non-requirements:
下列被视为非所需资源：
o Supporting network-specific DNS64 [RFC6147]
o 支持特定于网络的DNS64[RFC6147]
o Supporting other network-specific inferences from plaintext DNS queries
o 支持来自明文DNS查询的其他特定于网络的推断
o Supporting insecure HTTP
o 支持不安全的HTTP
The following is an incomplete list of earlier work that related to DNS over HTTP/1 or representing DNS data in other formats.
以下是与HTTP/1上的DNS相关或以其他格式表示DNS数据的早期工作的不完整列表。
The list includes links to the tools.ietf.org site (because these documents are all expired) and web sites of software.
该列表包括指向tools.ietf.org网站（因为这些文档都已过期）和软件网站的链接。
o <https://tools.ietf.org/html/draft-mohan-dns-query-xml>
o <https://tools.ietf.org/html/draft-mohan-dns-query-xml>
o <https://tools.ietf.org/html/draft-daley-dnsxml>
o <https://tools.ietf.org/html/draft-daley-dnsxml>
o <https://tools.ietf.org/html/draft-dulaunoy-dnsop-passive-dns-cof>
o <https://tools.ietf.org/html/draft-dulaunoy-dnsop-passive-dns-cof>
o <https://tools.ietf.org/html/draft-bortzmeyer-dns-json>
o <https://tools.ietf.org/html/draft-bortzmeyer-dns-json>
o <https://www.nlnetlabs.nl/projects/dnssec-trigger/>
o <https://www.nlnetlabs.nl/projects/dnssec-trigger/>
Acknowledgments
致谢
This work required a high level of cooperation between experts in different technologies. Thank you 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, and Sam Weiler.
这项工作需要不同技术领域的专家进行高水平的合作。谢谢雷·贝利斯、斯蒂芬·波茨迈耶、马努·布雷特尔、萨拉·迪金森、马西米利亚诺·范图齐、托尼·芬奇、丹尼尔·卡恩·吉尔莫、奥拉弗·古德蒙德森、韦斯·哈达克、罗里·休伊特、乔·希尔德布兰德、大卫·劳伦斯、艾略特·李尔、约翰·马特森、亚历克斯·梅尔霍夫、马克·诺丁汉、吉姆·里德、亚当·罗奇、本·施瓦茨、戴维·宋、丹尼尔·斯坦伯格、安德鲁·沙利文、，马丁·汤姆森和萨姆·韦勒。
Authors' Addresses
作者地址
Paul Hoffman ICANN
保罗·霍夫曼·伊坎
Email: paul.hoffman@icann.org
Email: paul.hoffman@icann.org
Patrick McManus Mozilla
帕特里克·麦克马纳斯·莫齐拉
Email: mcmanus@ducksong.com
Email: mcmanus@ducksong.com