DNS over HTTPS (DoH) doesn’t replace the DNS message with a web API. It takes an ordinary DNS query or response and carries it over HTTPS. The DNS question, record types, response codes, TTLs, and caching behavior are still DNS, while HTTPS provides the encrypted transport and authenticates the server.
The DNS message rides inside HTTPS
RFC 8484 maps each DNS query-response pair to one HTTP exchange. The payload every DoH client and server must support is a single DNS wire-format message, the same format as ordinary DNS but without the two-byte length prefix that DNS over TCP and DoT use, carried under the application/dns-message media type, though endpoints can negotiate others. A POST request places the binary message in the request body, and a GET request encodes it with unpadded base64url into the dns variable of the resolver’s URI template. Either way the resolver decodes the same DNS message and returns a DNS response in the HTTP response body:
POST /dns-query HTTP/1.1
Host: resolver.example
Accept: application/dns-message
Content-Type: application/dns-message
<binary DNS query>HTTP/2 200
Content-Type: application/dns-message
<binary DNS response>The message inside that body still contains the DNS header, Question section, and any Answer, Authority, or Additional records the resolver returns.
application/dns-message for DNS wire-format messages.
Creating a new encrypted connection per question would add avoidable latency, so one HTTPS connection carries many DNS exchanges, and on an HTTP version with multiple streams the responses can complete in any order. HTTP associates each response with its request at the stream level, which is why RFC 8484 recommends sending DNS message ID zero to improve HTTP cache reuse.
HTTP success and DNS success are separate results
DoH has two layers that report independently. HTTP status codes describe the HTTP exchange, and DNS response codes (RCODEs) describe the DNS operation inside a valid DNS response. A query for a nonexistent name can produce:
HTTP status: 200
DNS RCODE: NXDOMAINThe HTTP request succeeded because the server returned a DNS response, and that response says the name doesn’t exist. The same holds for SERVFAIL, which travels fine inside a 2xx HTTP response. An HTTP error means something different, such as a malformed request or an unavailable endpoint, and a non-2xx response simply doesn’t convey a DNS reply to the original question. Keeping the two error layers separate keeps a failed HTTP exchange from being misread as an answer about the name.
DNS TTLs cap HTTP caching
DoH combines two systems that both cache. RFC 8484 ties them together by requiring that a DoH response’s HTTP freshness lifetime not exceed the smallest TTL in the DNS Answer section, so the HTTP cache can never keep a message fresh longer than the records inside it are allowed to live. A client also subtracts the HTTP Age header when working out the remaining TTL, so a record that sat in an intermediary cache isn’t treated as brand new, though explicitly authorized stale reuse like stale-while-revalidate can extend serving past freshness.
Negative answers keep their DNS caching behavior too. When a response has no Answer records and carries an SOA in the Authority section, RFC 8484 caps the HTTP freshness at that SOA’s MINIMUM field, while RFC 2308 computes the DNS negative-cache TTL. DoH adds an HTTP cache layer on top of the DNS cache rules.
What DoH changes
Classic application DNS usually runs through the OS resolver to a configured recursive resolver. DoH makes another shape mainstream, where an application ships its own DoH client and sends lookups straight to a resolver over HTTPS instead of through the operating system’s path. A system resolver, a local forwarder, a browser, or a security agent can all be the DoH client, and once some applications choose a resolver on their own, stub resolver behavior no longer describes every lookup. One device can end up with different DNS views, one application using the network-designated resolver and another using a separately configured DoH service.
Choosing the resolver is a separate question. RFC 8484 defines how to send DNS through HTTPS once the client knows the service URI and leaves the choice of service to configuration, application defaults, enterprise policy, and newer discovery standards. Those decide where the encrypted connection goes, while DoH defines how DNS is exchanged once it gets there. “Uses DoH” names a transport, and by itself it says nothing about which resolver is in use or why.
The network’s view changes too. Classic DNS uses recognizable patterns like UDP or TCP port 53, while DoH normally uses HTTPS on port 443 and blends into ordinary web traffic, which makes it hard to block by port without disrupting the web at large. An observer that doesn’t terminate the connection can’t read the QNAME, but the queries aren’t unobservable. Without Encrypted Client Hello the TLS SNI can reveal the resolver’s hostname, destination addresses, packet sizes, and timing stay visible, and the DoH service itself sees the plaintext query. That affects systems that relied on plaintext DNS for troubleshooting, monitoring, or policy, since confidentiality removes visibility from trusted observers just as it does from untrusted ones.
What DoH doesn’t change
HTTPS authenticates the transport endpoint, not the DNS data. A resolver with a valid certificate can still return a forged answer over a perfectly authenticated connection, which is why DNSSEC validation stays a separate matter, and any CDN, gateway, or enterprise TLS interceptor that terminates the connection sits inside the trust boundary.
Past the resolver, it’s ordinary DNS. If the answer is cached the endpoint responds from cache. Otherwise it obtains one by walking the hierarchy itself, forwarding to another resolver, or applying local policy, and its upstream transport may be classic DNS, DoT, DoH, or DoQ. DoH doesn’t change the authority of root, TLD, or authoritative servers, doesn’t change record types or delegation, and doesn’t bypass TTLs. Which resolver is chosen, how upstream resolution is performed, what gets logged, and how policy is applied are all decisions that sit outside the protocol.
Summary
DNS over HTTPS carries ordinary DNS messages through HTTPS, so a successful HTTP response can still carry an NXDOMAIN, and HTTP cache freshness stays capped by the DNS TTLs inside it.
DoH changes the transport between a client and resolver, the way DoT does with a dedicated TLS port instead. Everything inside and beyond the resolver remains DNS.