View source for RFC 8484

{{Note|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.<ref name="rfc8484">[https://datatracker.ietf.org/doc/html/rfc8484 P. Hoffman, P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, IETF, October 2018.]</ref> Each DNS query–response pair is mapped to a single HTTP exchange, allowing DNS traffic to use the same encrypted transport as Web applications.<ref name="rfcinfo8484">[https://www.rfc-editor.org/info/rfc8484 RFC Editor, "Information on RFC 8484" (accessed 2025-11-24).]</ref>

== 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|DNS over TLS]] (DoT) in [[RFC 7858]].<ref name="rfc7858">[https://datatracker.ietf.org/doc/html/rfc7858 Z. Hu et al., "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, IETF, May 2016.]</ref>

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).<ref name="rfc8484" />

== Protocol Overview ==
RFC 8484 defines a “DoH client” and “DoH server” as DNS endpoints that use HTTPS as their transport.<ref name="rfc8484" /> 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.<ref name="rfc8484" />

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.<ref name="rfc8484" /> 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.<ref name="rfc8484" />

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.<ref name="rfc8484" />

== 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.<ref name="rfc8484" />
* '''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.<ref name="google-doh">[https://developers.google.com/speed/public-dns/docs/doh Google Public DNS, "DNS-over-HTTPS (DoH)" (accessed 2025-11-24).]</ref><ref name="cloudflare-doh">[https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-https/make-api-requests/ Cloudflare, "Make API requests to 1.1.1.1 over DoH" (accessed 2025-11-24).]</ref>
* '''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.<ref name="rfc8484" /> 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.<ref name="rfc8484" /> 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.<ref name="rfc8484" />

== See Also ==
* [[RFC 7858]]
* [[RFC 9250]]

== References ==
{{reflist}}

[[Category:Standards]]
[[Category:RFC]]