DNS Queries over HTTPS (DoH)
Extracted elements (32)
Authentication of DoH servers SHOULD NOT rely on DNS-based references to external resources (e.g., OCSP servers, CRL distribution points) in the TLS handshake, to avoid a bootstrapping deadlock where resolving the server's hostname requires the DoH server itself.
DoH avoids extending DNS resolution privileges to URIs discovered outside client configuration (e.g., via server push) because such scenarios create additional operational, tracking, and security hazards that have not yet been specified safely.
The use of a DNS ID of 0 in GET requests is recommended because HTTP correlates request and response, eliminating the need for the DNS ID field. Using varying IDs causes semantically equivalent queries to be cached separately, harming cache efficiency.
Transport-specific DNS extensions such as the edns-tcp-keepalive EDNS0 option (RFC 7828) are not applicable to DoH. Media types used with DoH must be flexible enough to express every DNS query normally sent over UDP, except those requiring multiple responses.
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.
Before using DoH response data for DNS resolution from server push, the client MUST establish that the HTTP request URI can be used for the DoH query.
DoH clients and DoH servers MUST support the 'application/dns-message' media type to maximize interoperability.
DoH clients MUST account for the Age response header field's value when calculating the DNS TTL of a response, applying to both HTTP and DNS client caches.
DoH clients SHOULD use a DNS ID of 0 in every DNS request when using media formats that include the ID field, to maximize HTTP cache friendliness and avoid separate caching of semantically equivalent queries.
DoH servers MUST implement both the POST and GET methods for receiving DNS queries.
DoH servers SHOULD assign an explicit HTTP freshness lifetime so that the DoH client is more likely to use fresh DNS data, preventing HTTP caches from assigning their own heuristic freshness.
HTTP/2 is the minimum RECOMMENDED version of HTTP for use with DoH, due to its support for reordering, parallelism, priority, and header compression.
HTTP cookies SHOULD NOT be accepted by DoH clients unless they are explicitly required by a use case, because cookies are the primary state tracking mechanism in HTTP.
If the DNS response has no records in the Answer section and has an SOA record in the Authority section, the response freshness lifetime MUST NOT be greater than the MINIMUM field from that SOA record.
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.
The DoH client MUST be prepared to process 'application/dns-message' responses irrespective of the value of the Accept request header field.
This protocol MUST be used with the https URI scheme; plain HTTP is not permitted.
When using the GET method, the data payload MUST be encoded with base64url (RFC 4648) and provided as a variable named 'dns' in the URI Template; padding characters for base64url MUST NOT be included.
When using the POST method, the data payload for 'application/dns-message' MUST NOT be encoded and is used directly as the HTTP message body.
DoH's use of HTTPS port 443 and the ability to mix DoH traffic with other HTTPS traffic on the same connection deters unprivileged on-path devices from interfering with DNS operations and makes DNS traffic analysis more difficult.
HTTPS introduces additional correlation vectors beyond DNS-over-TLS, including HTTP cookies, User-Agent and Accept-Language headers, caching state, TLS session resumption tokens, and the mixing of DoH with other HTTP requests on the same connection.
Long-lived TCP/TLS connections improve performance but group more requests, exposing more information to correlation. TLS session resumption mechanisms and TCP Fast Open cookies create trivial server-side correlation of connections.
A successful HTTP response with a 2xx status code is used for any valid DNS response, regardless of the DNS response code. This includes DNS failures such as SERVFAIL or NXDOMAIN. Non-2xx HTTP status codes indicate transport-level errors, not DNS errors.
Each DNS query-response pair is mapped to one HTTP exchange. For GET requests, the DNS query is encoded as a base64url 'dns' query parameter. For POST requests, the DNS query is the HTTP message body with Content-Type 'application/dns-message'.
The DoH client is configured with a URI Template (RFC 6570) that describes how to construct the URL for resolution. The DoH server defines the URI used by requests through this template. Configuration and discovery of the URI Template are done out of band.
This document registers the 'application/dns-message' media type. Type: application; Subtype: dns-message; binary format containing a DNS message as defined in RFC 1035; change controller is IESG.
An adversary controlling the HTTP cache used by the client can affect that client's view of the DNS. In the absence of DNSSEC, a DoH server can give a client invalid data; Section 3's prohibition on unconfigured URIs reduces but does not eliminate this risk.
DoH encrypts DNS traffic using HTTPS (TLS) and requires server authentication, mitigating passive surveillance and active attacks that divert DNS traffic to rogue servers. It also mitigates classic UDP-based DNS amplification attacks.
HTTPS provides transport security but not DNSSEC-level response integrity. DNSSEC and DoH are independent and complementary: clients may perform full DNSSEC validation or trust the DoH server to validate and check the AD bit.
Session-level encryption has well-known weaknesses against traffic analysis, which may be acute for DNS queries. Mitigation options include HTTP/2 padding and compression controls, and DNS padding via RFC 7830 if the client requests it.
For GET requests, the DNS wire-format message is encoded as base64url (RFC 4648) without padding and passed as the 'dns' URI Template variable. The example shows a 33-byte DNS query for 'www.example.com' becoming a base64url-encoded path parameter.
The 'application/dns-message' media type carries a single DNS message in the DNS on-the-wire format defined in RFC 1035 Section 4.1, with a maximum message size of 65535 bytes. This differs from DNS-over-TLS (RFC 7858) which uses the two-length-byte framing from RFC 1035 Section 4.2.2.