ICANN

paul.hoffman@icann.org

Mozilla

pmcmanus@mozilla.com

Art Internet-Draft DNS queries sometimes experience problems with end to end connectivity at times and places where HTTPS flows freely. HTTPS provides the most practical mechanism for reliable end to end communication. Its use of TLS provides integrity and confidentiality guarantees and its use of HTTP allows it to interoperate with proxies, firewalls, and authentication systems where required for transit. This document describes how to run DNS service over HTTP using https:// URIs. [ This paragraph is to be removed when this document is published as an RFC ] Comments on this draft can be sent to the DNS over HTTP mailing list at https://www.ietf.org/mailman/listinfo/dnsoverhttp.

The Internet does not always provide end to end reachability for native DNS. On-path network devices may spoof DNS responses, block DNS requests, or just redirect DNS queries to different DNS servers that give less-than-honest answers. Over time, there have been many proposals for using HTTP and HTTPS as a substrate for DNS queries and responses. To date, none of those proposals have made it beyond early discussion, partially due to disagreement about what the appropriate formatting should be and partially because they did not follow HTTP best practices. This document defines a specific protocol for sending DNS queries and getting DNS responses over modern versions of HTTP using https:// (and therefore TLS security for integrity and confidentiality). 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, proxying, and compression. The integration with HTTP provides a transport suitable for both traditional DNS clients and native web applications seeking access to the DNS. A server that supports this protocol is called a “DNS API server” to differentiate it from a “DNS server” (one that uses the regular DNS protocol). Similarly, a client that supports this protocol is called a “DNS API client”.

In this document, the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in BCP 14, RFC 2119 .

There are two primary use cases for this protocol. The primary one is to prevent on-path network devices from interfering with native DNS operations. This interference includes, but is not limited to, spoofing DNS responses, blocking DNS requests, and tracking. HTTP authentication and proxy friendliness are expected to make this protocol function in some environments where DNS directly on TLS () would not. A secondary use case is web applications that want to access DNS information. Standardizing an HTTPS mechanism allows this to be done in a way consistent with the cross-origin resource sharing security model of the web and also integrate the caching mechanisms of DNS with those of HTTP. These applications may be interested in using a different media type than traditional clients. [ This paragraph is to be removed when this document is published as an RFC ] Note that these use cases are different than those in a similar protocol described at . The use case for that protocol is proxying DNS queries over HTTP instead of over DNS itself. The use cases in this document all involve query origination instead of proxying.

The protocol described here bases its design on the following protocol requirements: The protocol must use normal HTTP semantics. The query format must be able to be flexible enough to express every normal DNS query. The protocol must allow implementations to use HTTP’s content negotiation mechanism. The protocol must ensure interoperable media formats through a mandatory to implement format wherein a query must be able to contain one or more EDNS extensions, including those not yet defined. The protocol must use a secure transport that meets the requirements for modern https://.

Supporting network-specific DNS64 Supporting other network-specific inferences from plaintext DNS queries Supporting insecure HTTP Supporitng legacy HTTP versions

The URI scheme MUST be https. The path SHOULD be “/.well-known/dns-query” but a different path can be used if the DNS API Client has prior knowledge about a DNS API service on a different path at the origin being used. (See for the registration of this in the well-known URI registry.) Using the well-known path allows automated discovery of a DNS API Service, and also helps contextualize DNS Query requests pushed over an active HTTP/2 connection. Some forms of the request may also include a HTTP query as defined by . A DNS API Client encodes the DNS query into the HTTP request in one of two different methods: Using the on-the-wire representation of a DNS message defined in as the query string portion of the URI, encoded as necessary with , using the GET HTTP method. This is the preferred approach because it is friendlier to HTTP caches. Including the DNS query as the message body of the HTTP request, with the request using the POST method. The body MUST use a media type selected by the DNS API Client, and that media type MUST be indicated by the request’s Content-Type header. The DNS request MAY have one or more EDNS(0) extensions . The DNS API Client SHOULD include an HTTP “Accept:” request header to say what type of content can be understood in response. The client MUST be prepared to process “application/dns-udpwireformat” responses but MAY process any other type it receives. In order to maximize cache friendliness, DNS API Clients SHOULD use the same ID (the first two bytes of the header) for every DNS request. The exact mechanism for doing so is dependent on the media type in use. HTTP semantics correlate the request and response which eliminates the need for the ID in a media type such as application/dns-udpwireformat. Using a constant value greatly increases the opportunity for successful caching. DNS API clients can use HTTP/2 padding and compression in the same way that other HTTP/2 clients use (or don’t use) them.

For example, assume a DNS API server is following this specification on origin https://dnsserver.example.net/ and the well-known path. The example uses HTTP/2 formatting from . A query for the IN A records for “www.example.com” with recursion turned on using the GET approach would be:

The same DNS query, using the second method of HTTP encoding would be:

abcd 0100 0001 0000 0000 0000 0377 7777 0765 7861 6d70 6c65 0363 6f6d 0000 0100 01 ]]>

Different response media types will provide more or less information from a DNS response. For example, one response type might include the information from the DNS header bytes while another might omit it. The amount and type of information that a media type gives is solely up to the format, and not defined in this protocol. At the time this is published, the response types are works in progress. The only known response type is “application/dns-udpwireformat”, but it is likely that at least one JSON-based response format might be defined in the future. The DNS response MAY have one or more EDNS(0) extensions, depending on the extension definition of the extensions given in the DNS request. Native HTTP methods are used to correlate requests and responses. Responses may be returned in a different temporal order than requests were made using the protocols native multistreaming functionality. In the HTTP responses, the HTTP cache headers SHOULD be set to expire at the same time as the shortest DNS TTL in the response. Because DNS provides only caching but not revalidation semantics, DNS over HTTP responses should not carry revalidation response headers (such as Last-Modified: or Etag:) or return 304 responses. A DNS API Server MUST be able to process application/dns-udpwireformat request messages. A DNS API Server SHOULD respond with HTTP status code 415 upon receiving a media type it is unable to process. This document does not change the definition of any HTTP response codes or otherwise proscribe their use.

This is an example response for a query for the IN A records for “www.example.com” with recursion turned on. The response bears one record with an address of 93.184.216.34 and a TTL of 128 seconds.

abcd 8180 0001 0001 0000 0000 0377 7777 0765 7861 6d70 6c65 0363 6f6d 0000 0100 0103 7777 7707 6578 616d 706c 6503 636f 6d00 0001 0001 0000 0080 0004 5Db8 d822 ]]>

In order to satisfy the security requirements of DNS over HTTPS, this protocol MUST use HTTP/2 or its successors. HTTP/2 enforces a modern TLS profile necessary for achieving the security requirements of this protocol. This protocol MUST be used with https scheme URI . The messages in classic UDP based DNS are inherently unordered and have low overhead. A competitive HTTP transport needs to support reordering, priority, parallelism, and header compression. For this additional reason, this protocol MUST use HTTP/2 or its successors.

This specification registers a Well-Known URI : URI Suffix: dns-query Change Controller: IETF Specification Document(s): [this specification] (Note for the -00 draft: a request for the media type application/dns-udpwireformat has already been submitted separately from this draft because it may be useful for other documents as well. That application is pending approval.)

Running DNS over https:// relies on the security of the underlying HTTP connection. By requiring at least levels of support for TLS this protocol expects to use current best practices for secure transport. Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with DNS queries. Sections 10.6 (Compression) and 10.7 (Padding) of provide some further advice on mitigations within an HTTP/2 context.

Joe Hildebrand contributed lots of material for a different iteration of this document. Helpful early comments were given by Ben Schwartz and Mark Nottingham.

This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK] The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This memo introduces a way to tunnel DNS data over HTTP. This may be useful in any situation where DNS is not working properly, such as when there is middlebox misbehavior. DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TRACK] The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. W3C

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. https://tools.ietf.org/html/draft-mohan-dns-query-xml https://tools.ietf.org/html/draft-daley-dnsxml https://tools.ietf.org/html/draft-dulaunoy-dnsop-passive-dns-cof https://tools.ietf.org/html/draft-bortzmeyer-dns-json https://www.nlnetlabs.nl/projects/dnssec-trigger/