DNS over HTTPS in Practice

DNS over HTTPS puts DNS queries inside HTTPS requests, using the same certificate validation and the same ports as everything else on the web. The specification is short, and the interesting decisions are all about the deployment model rather than the wire format.

Why HTTPS and not a new protocol

The design decision that mattered was choosing to reuse HTTP infrastructure. The alternative, a new protocol on a new port, faces the deployment problem described in RFC 7626: anything on a new port is identifiable and can be blocked or throttled as a class. Running inside ordinary HTTPS means the traffic looks like web traffic, which is the entire point.

That is also the trade-off. A resolver that is a web endpoint inherits web’s centralisation, its caching, and its intermediaries.

Query format

A DoH server accepts a GET or POST carrying a wire-format DNS message, and returns a response in the same format with application/dns-message. Because HTTP already provides connection reuse, compression, and transport security, most of the specification is about caching and about which URL templates a client should use.

Deployment modes

Browser-managed. Firefox and Chrome resolve independently of the operating system resolvers. This hides queries from the local network and the ISP, and exposes them to the chosen resolver instead.

Operating-system-managed. The OS resolver wraps queries itself. Useful for devices where the browser is not the main client, and for enforcing policy across applications.

Router-managed. Convenient and weak. The router resolves everything and the network operator can see exactly what it asked for.

What a resolver can still do

• See every query and every client address. This is inherent. It is the party you have chosen to trust instead of your network.
• Return a wrong answer. DoH authenticates the resolver, not the answer. TLS gives no path to verifying that a resolver’s response matches what the authoritative server would have said. DNSSEC is the mechanism that addresses this, and it has its own deployment gaps.
• Correlate with the destination. A resolver that also observes connections can reconstruct a browsing profile more easily than a network operator alone can.

Operational checklist

1. Browser-managed DoH, strict mode, no excluded domains.
2. A resolver whose retention policy you have read.
3. Confirm no fallback: a leak test should show only your resolver.
4. Router DNS pointed at the local network rather than at a public resolver, so devices that are not the browser do not bypass it.
5. DNSSEC validation enabled if your resolver supports it, accepting that some domains will fail.
6. Re-test after every browser or operating-system update, because the defaults change.

Sources

• RFC 8484 — the specification, including the media type and URL template conventions.
• Mozilla: DNS over HTTPS design — why the browser resolves independently rather than using the system resolver.
• RFC 7626 — the network-fingerprinting problem that shaped both DoT and DoH.