Document Shepherd Writeup for “DNS Queries over HTTPS”
Document Shepherd: Benjamin Schwartz
Responsible Area Director: Adam Roach
Date: 2018 June 27
This document defines a protocol for performing DNS Queries over an HTTPS connection. This protocol offers similar security benefits to DNS-over-TLS (RFC 7858), and also allows integration with HTTP-based systems and services. The working group requests publication as a Proposed Standard because there is wide interest and growing implementation of the protocol, and standardization is important to ensure interoperability between clients and servers.
2. Review and Consensus
The document has been reviewed thoroughly within the working group, including extensive commentary by noted standards experts and large-scale implementors in DNS and HTTP.
Implementation has begun, with a large-scale deployment by Cloudflare, experiments by Mozilla and Google, and many independent implementations: doh-proxy (an IETF hackathon output), Go DNS, dnscrypt-proxy, doh-php-client, jDnsProxy, rust-doh, and dns-over-https. The maintainers of Stubby, CURL, and PowerDNS’s dnsdist have developed working prototypes.
The draft has received excellent, thorough review. There has not been any vocal opposition to the draft as whole, and the points of contention largely appear to have been resolved through sound debate on the technical merits, to the satisfaction of most participants.
2a. Notable debates during standard development
== Binary vs. Human-readable ==
Early in the process, there was some debate on whether to use the existing DNS wire format directly or to define a more legible format (e.g. HTTP query syntax, JSON).
Conclusion: The draft defines the existing DNS wire format as Mandatory To Implement, and supports HTTP content-type negotiation to select other formats.
== Use of HTTP errors ==
There was initially some question of whether a DNS error response (e.g. SRVFAIL, NXDOMAIN) should be provided to the user as an HTTP success response (200) or an error response (500, 404).
Conclusion: Any DNS wire format message is an HTTP success response (200), even if the DNS message is intended to communicate an error. HTTP error responses are also allowed, but they are not used to send DNS error responses.
== TTL Interpretation ==
The working group quickly reached consensus that HTTP cache lifetimes should match the DNS expiration time indicated by the TTL. However, finding language to specify this required extensive iteration.
Conclusion: HTTP experts contributed detailed language to a long section on Cache Interaction.
== GET vs. POST ==
DNS queries do not mutate server state, so they have semantics similar to HTTP GET. However, GET does not have a body, so transmitting a wire format DNS query in GET requires encoding it in Base64 in the URL, which seems unnatural. Conversely, using POST allows a more natural encoding, but has a less natural semantic match, because it normally indicates a mutating operation. Using POST is also incompatible with some other design goals, such as good HTTP cache support and HTTP/2 PUSH.
Conclusion: The draft requires servers to support queries over GET and POST.
== Configuration and .well-known ==
The first several versions of the draft proposed a new, optional “.well-known” path for this protocol. This would enable clients to select a server by its domain name, similar to DNS over TLS. It would also open a logical path for potential standards work on opportunistic upgrade (given only an IP address) and for receiving DNS records via HTTP/2 PUSH from unexpected sources. However, HTTP experts strongly advised against attempting to use .well-known for this purpose.
Conclusion: The .well-known proposal was dropped, and configuration is specified to require a full URL. Bootstrapping from a domain is not defined in this document, but could be defined in a future document.
== Forward compatibility and URL structure ==
Early versions of the draft proposed that a DOH endpoint is specified by a URL, with a standardized format for query parameters. This makes clients simple, and also enables forward compatibility by defining new query parameters (which older servers will ignore). However, some group members felt that a fixed URL structure was inflexible, and suggested URI Templates instead. Configuration using URI Templates allows a wide range of URL structures but would require reconfiguration of each client instance to use any parameters that might be added in a future version of DOH.
Conclusion: The draft adopted URI Templates as the sole configuration mechanism.
== Truncation behavior ==
Depending on the transport, DNS servers sometimes truncate their responses based on size limits configured in the server or signalled in the query. There was some discussion of whether clients should be able to request truncation behavior from a DOH server, or whether we should forbid DOH servers from returning truncated answers.
Conclusion: The draft has no normative requirements related to truncation, but there is text indicating that returning a truncated response is similar to returning an HTTP error response.
== Size limits ==
In UDP, DNS messages are limited to 65535 bytes in length. DNS over TCP has an identical limit due to its two-byte length field, and similarly DNS over TLS. However, HTTPS has no such limit, nor does the DNS format itself (as specified in RFC 1035, etc.). Some working group members requested that DOH impose a 65535-byte limit to ensure reliable convertibility of messages, and a few proposed applying a “gateway” requirement to all future media types as well. Others suggested allowing messages of unlimited size, letting implementors choose their own tradeoff between capacity and compatibility.
Conclusion: The mandatory to implement media type is limited to 65535 bytes, but future media types might not impose an equivalent limit. This message size limit was imposed out of an abundance of caution, not technical necessity.
== Zone transfers ==
The DNS protocol is used not only for common queries (AAAA, TXT) by stub and recursive resolvers, but also for zone transfers (AXFR) initiated by authoritative DNS servers. These queries use the DNS protocol, but the response is often larger than 65535 bytes. DNS enables these responses with “continuation messages”, i.e. sequences of DNS response messages that are in response to a single query. Some WG members suggested banning AXFR queries in DOH, while others suggested defining a mechanism for transferring multiple response messages to a single query (e.g. multipart/related).
Conclusion: The draft does not ban AXFR queries, and it does not define a mechanism for receiving multiple or combined responses. Response sizes in future media types or protocol versions are not constrained.
== Privacy language ==
Compared to previous DNS transports, DOH introduces new ways for servers to link queries from a single client over time (e.g. HTTP cookies, locale headers). Some WG members suggested normative requirements not to use some of these features (e.g. User-Agent), while others viewed them as useful features worth preserving. There was also some debate about how strongly to warn implementors about linkability.
Conclusion: An extensive Privacy Considerations section was added, with comparisons to other DNS transports and some advice but no normative requirements.
== Trust language ==
The working group has clear consensus that a client should not send a query to a server unless it trusts that server to receive the query, and should not use an unsigned response unless it trusts the server to answer truthfully. However, finding language to describe this proved challenging.
Conclusion: A section was added on “Selection of a DoH Server” to emphasize that queries must only be sent to a server on purpose.
3. Intellectual Property
The authors have confirmed that they are not aware of any relevant IPR. There have been no disclosures filed and little or no discussion of IPR in the working group beyond the Note Well.
4. Other points
This draft normatively references RFC 7626, which has Informational status and is not in the DOWNREF registry.
This draft has a single IANA consideration (defining the “application/dns-message” media type). There has been extensive review of this media type, including several name changes.