summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8484.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8484.txt')
-rw-r--r--doc/rfc/rfc8484.txt1179
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc8484.txt b/doc/rfc/rfc8484.txt
new file mode 100644
index 0000000..00f1cba
--- /dev/null
+++ b/doc/rfc/rfc8484.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+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)
+
+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.
+
+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.
+
+ 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.
+
+Copyright Notice
+
+ Copyright (c) 2018 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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.
+
+
+
+
+
+
+
+
+Hoffman & McManus Standards Track [Page 1]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & McManus Standards Track [Page 2]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+1. Introduction
+
+ 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.
+
+ 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.
+
+ The integration with HTTP provides a transport suitable for both
+ existing DNS clients and native web applications seeking access to
+ the DNS.
+
+ 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.
+
+2. Terminology
+
+ 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".
+
+ 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.
+
+
+
+
+
+
+
+
+Hoffman & McManus Standards Track [Page 3]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+3. Selection of DoH Server
+
+ 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.
+
+ 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.
+
+ 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.
+
+4. The HTTP Exchange
+
+4.1. The HTTP Request
+
+ 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.
+
+ 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].
+
+ Future specifications for new media types for DoH MUST define the
+ variables used for URI Template processing with this protocol.
+
+ DoH servers MUST implement both the POST and GET methods.
+
+
+
+
+
+Hoffman & McManus Standards Track [Page 4]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+ 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.
+
+ Using the GET method is friendlier to many HTTP cache
+ implementations.
+
+ 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.
+
+ 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.
+
+ 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.
+
+4.1.1. HTTP Request Examples
+
+ These examples use HTTP/2-style formatting from [RFC7540].
+
+ These examples use a DoH service with a URI Template of
+ "https://dnsserver.example.net/dns-query{?dns}" to resolve IN A
+ records.
+
+ The requests are represented as bodies with media type "application/
+ dns-message".
+
+ The first example request uses GET to request "www.example.com".
+
+ :method = GET
+ :scheme = https
+ :authority = dnsserver.example.net
+ :path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
+ accept = application/dns-message
+
+
+
+
+
+
+
+Hoffman & McManus Standards Track [Page 5]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+ The same DNS query for "www.example.com", using the POST method would
+ be:
+
+ :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
+
+ In this example, the 33 bytes are the DNS message in DNS wire format
+ [RFC1035], starting with the DNS header.
+
+ 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.
+
+ The DNS query, expressed in DNS wire format, is 94 bytes represented
+ by the following:
+
+ 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
+
+
+
+
+
+
+
+
+
+Hoffman & McManus Standards Track [Page 6]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+4.2. The HTTP Response
+
+ 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.
+
+ 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.
+
+ 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]).
+
+ Section 5.1 discusses the relationship between DNS and HTTP response
+ caching.
+
+4.2.1. Handling DNS and HTTP Errors
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Hoffman & McManus Standards Track [Page 7]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+4.2.2. HTTP Response Example
+
+ 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.
+
+ :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 Integration
+
+ This protocol MUST be used with the https URI scheme [RFC7230].
+
+ Sections 8 and 9 discuss additional considerations for the
+ integration with HTTP.
+
+5.1. Cache Interaction
+
+ 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.
+
+ 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).
+
+ 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.
+
+
+
+
+Hoffman & McManus Standards Track [Page 8]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+ 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.
+
+ 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]).
+
+ 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.
+
+ 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 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.
+
+ 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.
+
+ 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-
+
+
+
+Hoffman & McManus Standards Track [Page 9]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+ 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.
+
+5.2. HTTP/2
+
+ HTTP/2 [RFC7540] is the minimum RECOMMENDED version of HTTP for use
+ with DoH.
+
+ 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.
+
+5.3. Server Push
+
+ 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).
+
+5.4. Content Negotiation
+
+ 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).
+
+6. Definition of the "application/dns-message" Media Type
+
+ 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.
+
+
+
+
+
+Hoffman & McManus Standards Track [Page 10]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+ 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.
+
+ 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).
+
+ 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.
+
+ 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.
+
+ 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.
+
+7. IANA Considerations
+
+7.1. Registration of the "application/dns-message" Media Type
+
+ Type name: application
+
+ Subtype name: dns-message
+
+ 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.
+
+ Security considerations: See RFC 8484. The content is a DNS message
+ and thus not executable code.
+
+ Interoperability considerations: None.
+
+ Published specification: RFC 8484.
+
+ Applications that use this media type:
+ Systems that want to exchange full DNS messages.
+
+
+
+
+Hoffman & McManus Standards Track [Page 11]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+ 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. Privacy Considerations
+
+ [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.
+
+8.1. On the Wire
+
+ 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].
+
+ 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.
+
+8.2. In the Server
+
+ 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.
+
+
+
+Hoffman & McManus Standards Track [Page 12]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Hoffman & McManus Standards Track [Page 13]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+9. Security Considerations
+
+ 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].
+
+ 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].
+
+ 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.
+
+
+
+
+
+Hoffman & McManus Standards Track [Page 14]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+ 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.
+
+ 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.
+
+10. Operational Considerations
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+Hoffman & McManus Standards Track [Page 15]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+ 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 [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.
+
+ 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.
+
+ 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.
+
+11. References
+
+11.1. Normative References
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+
+
+
+
+
+Hoffman & McManus Standards Track [Page 16]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+ [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>.
+
+ [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
+ DOI 10.17487/RFC6265, April 2011,
+ <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>.
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+
+
+
+
+Hoffman & McManus Standards Track [Page 17]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+ [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
+ DOI 10.17487/RFC7626, August 2015,
+ <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>.
+
+ [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>.
+
+11.2. Informative References
+
+ [FETCH] "Fetch Living Standard", August 2018,
+ <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>.
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+
+
+
+
+Hoffman & McManus Standards Track [Page 18]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+ [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>.
+
+ [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
+ DOI 10.17487/RFC7830, May 2016,
+ <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>.
+
+ [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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & McManus Standards Track [Page 19]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+Appendix A. Protocol Development
+
+ 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.
+
+ The protocol described in this document based its design on the
+ following protocol requirements:
+
+ o The protocol must use normal HTTP semantics.
+
+ 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 The protocol must permit the addition of new formats for DNS
+ queries and responses.
+
+ 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 The protocol must use a secure transport that meets the
+ requirements for HTTPS.
+
+ The following were considered non-requirements:
+
+ o Supporting network-specific DNS64 [RFC6147]
+
+ o Supporting other network-specific inferences from plaintext DNS
+ queries
+
+ o Supporting insecure HTTP
+
+Appendix B. Previous Work on DNS over HTTP or in Other Formats
+
+ The following is an incomplete list of earlier work that related to
+ DNS over HTTP/1 or representing DNS data in other formats.
+
+ The list includes links to the tools.ietf.org site (because these
+ documents are all expired) and web sites of software.
+
+ o <https://tools.ietf.org/html/draft-mohan-dns-query-xml>
+
+
+
+
+Hoffman & McManus Standards Track [Page 20]
+
+RFC 8484 DNS Queries over HTTPS (DoH) October 2018
+
+
+ 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-bortzmeyer-dns-json>
+
+ 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
+
+
+ Patrick McManus
+ Mozilla
+
+ Email: mcmanus@ducksong.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & McManus Standards Track [Page 21]
+