RFC 8484

For implications on Internet governance, see DNS over HTTPS.

RFC 8484, DNS Queries over HTTPS (DoH), is an IETF standards-track RFC that specifies how normal DNS queries and responses can be carried over HTTPS. Each DNS query–response pair is mapped to a single HTTP exchange, allowing DNS traffic to use the same encrypted transport as Web applications.

Background

DNS, as specified in RFC 1035, sends most queries in cleartext over UDP or TCP port 53, exposing them to interception, modification, and monitoring. Growing concern about DNS privacy, combined with the ease with which on-path devices can interfere with DNS traffic, led the IETF to define encrypted transports for DNS, starting with DNS over TLS (DoT) in RFC 7858.

RFC 8484 extends this work by defining DNS over HTTPS. The design aims to achieve two primary goals: protect DNS queries from on-path interference, and allow Web applications to access DNS information through existing browser and HTTP APIs in a controlled way, for example using Cross-Origin Resource Sharing (CORS).

Protocol Overview

RFC 8484 defines a “DoH client” and “DoH server” as DNS endpoints that use HTTPS as their transport. The protocol focuses on communication between DNS clients (such as operating system stub resolvers or application resolvers) and recursive resolvers. It does not change the protocol spoken between recursive and authoritative servers.

HTTP success and error handling follow HTTP semantics. A DNS response, even one carrying a DNS-level error such as NXDOMAIN or SERVFAIL, is returned with a 2xx HTTP status code if the HTTP transaction itself succeeded. Non-2xx status codes indicate HTTP-level errors and do not carry usable DNS responses.

RFC 8484 is explicit that DoH is not simply a tunnel; it integrates DNS payloads with HTTP features like caching, content negotiation, authentication, and proxying. DoH clients should send an "HTTP Accept" header, and must be able to process "application/dns-message" responses, while they may support additional media types defined by future specifications. DoH relies on HTTPS server authentication as defined in RFC 2818 and TLS 1.3, so standard Web PKI mechanisms are used to verify the resolver’s identity.

The specification requires that DoH clients only use URIs they have explicitly been configured with. They must not automatically treat other discovered HTTPS endpoints (for example from HTTP/2 server push) as DNS resolvers, to avoid unexpected tracking or redirection of DNS traffic.

Deployment Models

RFC 8484 is transport-agnostic with respect to where the DoH client runs. Implementations fall into a few broad patterns:

• Stub-to-recursive resolution: The most common model has an operating system stub resolver or a standalone DNS client sending queries over HTTPS to a recursive resolver that offers a DoH endpoint.
• Application-level DoH: Web browsers and other applications can implement DoH directly and send DNS queries over HTTPS without relying on the host’s DNS configuration. Large public resolvers such as Google Public DNS and Cloudflare’s 1.1.1.1 expose DoH endpoints documented for API usage.
• Hybrid environments: Some deployments use DoH internally (for example, between applications and a local resolver) while the resolver itself talks to upstream servers using another method.

RFC 8484 does not redefine DNS resolution logic or caching policy; it specifies only the on-the-wire format and HTTP integration. Recursive resolvers receiving DoH queries process them using the same DNS rules that apply to queries received over UDP/TCP.

Security and Privacy Properties

By requiring HTTPS, RFC 8484 ensures that the path between DoH client and DoH server benefits from TLS confidentiality, integrity protection, and server authentication. On-path observers between client and DoH server can no longer read or modify the DNS payload, but they may still see the IP addresses involved and some HTTPS metadata.

The DoH server can see all queries in cleartext, and clients rely on web PKI to authenticate it; traffic analysis remains possible based on packet sizes, timing, and destination IPs, even though query contents are encrypted. Implementations need to consider the interaction of DoH with HTTP proxies, authentication mechanisms, and logging policies, since DNS information becomes part of general HTTPS traffic rather than a separate protocol on port 53.

See Also

• RFC 7858
• RFC 9250

Request For Comments. Archival series dedicated to documenting Internet technical specifications, including general contributions from the Internet research and engineering community as well as standards documents (RFC Editor Model, Version 3).

HTTP over Transport Layer Security (TLS), distinguishing secured traffic from insecure traffic by the use of a different server port (RFC 2818).

DNS over HTTPS

Internet Engineering Task Force

Hypertext Transfer Protocol. Application-level protocol for distributed, collaborative, hypermedia information systems (RFC 2616).

Provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP) (RFC 768).

X.509 Public Key Infrastructure for the Internet (RFC 5280).

Application Programming Interface is a set of rules or protocols that enables software applications to communicate with each other to exchange data, features and functionality (IBM).

Allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery (RFC 8446).