Document Shepherd Writeup for “DNS Queries over HTTPS”
1. Summary
Document Shepherd: Benjamin Schwartz
Responsible Area Director: Adam Roach
Revision: 00
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.
Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00279.html
== 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.
Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00526.html
== 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.
Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00407.htmlhttps://www.ietf.org/mail-archive/web/doh/current/msg00268.html
== 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.
Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00244.htmlhttps://www.ietf.org/mail-archive/web/doh/current/msg00208.html
== 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.
Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00393.html
== 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.
Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00371.htmlhttps://www.ietf.org/mail-archive/web/doh/current/msg00472.html
== 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.
Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00650.htmlhttps://www.ietf.org/mail-archive/web/doh/current/msg00619.html
== 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.
Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00657.html
== 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.
Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00835.htmlhttps://www.ietf.org/mail-archive/web/doh/current/msg00803.htmlhttps://www.ietf.org/mail-archive/web/doh/current/msg00777.html
== 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.
Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00492.htmlhttps://www.ietf.org/mail-archive/web/doh/current/msg00590.html
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.