DNS over HTTPS (DoH) Explained: How It Works, the DoH Template, DoH vs DNSCrypt and How to Enable It

How DNS over HTTPS works under RFC 8484

The protocol is defined in RFC 8484, published in October 2018 by Paul Hoffman of ICANN and Patrick McManus of Mozilla. Each DNS query and response pair maps to one HTTP exchange. The body is the normal binary DNS message, with the media type application/dns-message, so the DNS part is unchanged and only the transport around it is new.

Servers must implement two request methods. With POST, the raw DNS message is the request body. With GET, the message is base64url-encoded, without padding, and passed in a URL variable called dns. GET has one practical benefit: HTTP caches can store the answer, and the RFC ties the HTTP freshness lifetime to the smallest TTL in the answer.

Two smaller rules show how carefully the design leans on HTTP. Clients should set the DNS message ID to 0, because a changing ID would make identical queries cache separately. And HTTP/2 is the minimum recommended version of HTTP, which lets many queries share one connection instead of each paying for its own TLS handshake.

The DoH template and where to find one

A client does not guess where to send queries. RFC 8484 says it is configured with a URI Template that describes how to build the request URL. In practice almost every public resolver publishes one plain address, and that address is the DoH template you paste into Windows, a browser or dnscrypt-proxy.

Google and Cloudflare also run JSON interfaces next to the RFC endpoint, https://dns.google/resolve? and the same /dns-query path with an accept: application/dns-json header on Cloudflare. These are handy for a quick look with curl but are not part of the standard. A client asking for a DoH template expects the wire-format /dns-query address, nothing else.

Turning on DNS over HTTPS in Chrome, Edge and Firefox

Chrome began rolling out Secure DNS with Chrome 83 in May 2020, the Chromium Blog announced. By default it uses a same-provider upgrade: Chrome keeps a list of resolvers known to offer DoH and, if your current DNS provider is on it, switches to that provider’s encrypted service. If the encrypted connection fails, Chrome falls back to regular DNS.

To choose a resolver yourself, open Chrome’s settings and search for Secure DNS. Picking a provider from the list, or entering a custom DoH template, puts Chrome in a mode without fallback. The feature is off when Chrome detects enterprise policies, and on Windows when parental controls are enabled, so a greyed-out option usually has one of those causes.

Microsoft Edge exposes the same modes to administrators through the DnsOverHttpsMode policy, supported from version 83 on Windows and macOS: off, automatic (DoH with insecure fallback) and secure (DoH only, failing on error). Firefox keeps its behaviour in the network.trr.mode preference in about:config: 2 tries DoH first and falls back, 3 uses DoH only, 5 turns it off.

Operating system support: Windows 11, macOS and iPhone

Windows 11 handles DNS over HTTPS for the whole system. In the connection’s Edit IP settings, set Manual, enter a preferred DNS server, then choose Off, On (automatic template) or On (manual template). A Fallback to plaintext switch decides whether queries go out unencrypted when HTTPS fails. Microsoft notes the option does not exist in Windows 10.

Windows only offers automatic encryption for servers on its list of known DoH servers, which ships with Cloudflare, Google and Quad9. Windows Server 2022 documents the PowerShell side: Get-DnsClientDohServerAddress shows the list, and Add-DnsClientDohServerAddress with a -DohTemplate value adds another resolver. On Apple devices, a DNS Settings configuration profile with the protocol set to HTTPS does the same job.

What DoH fixes, and what it leaves alone

The Chromium team named three gains: authenticity, integrity and confidentiality. The browser can check that it talks to the intended resolver, that the answer was not altered on the way, and that nobody on a shared network, a library Wi-Fi in their example, can read the lookups. The encrypted DNS overview covers the attacks this stops.

The DNSCrypt FAQ lists the costs. DoH has an insecure bootstrap, its TLS handshake exposes the resolver hostname through SNI, and resolution has concentrated on a few large CDN operators. The resolver also sees every query. None of this makes DNS over HTTPS worse than plain DNS; it shows where the remaining trust sits.

DoH vs DNSCrypt

The two protocols solve one problem with different tools. DoH borrows the web stack: TLS certificates, HTTP/2 or HTTP/3, port 443. DNSCrypt uses its own lightweight format with signed certificates and no HTTP layer. The DNSCrypt FAQ argues that DNSCrypt has no SNI, no HTTP signature and no fixed port, and that DoH has higher latency even over HTTP/3.

For most readers the DoH vs DNSCrypt question is less either-or than it looks, because dnscrypt-proxy speaks both. The doh_servers and dnscrypt_servers options in its configuration decide which servers it will use, and the example file recommends bootstrap resolvers run by a different operator than your DoH servers. The DNSCrypt vs DoH comparison goes through the details.

Picking a setup that fits

For encryption only in the browser, set a provider in Chrome’s Secure DNS or Firefox’s TRR preference and stop there. For every application on Windows 11, use the system setting with a manual DoH template and Fallback to plaintext off. For filtering, logging or a mix of DNSCrypt and DoH servers, run dnscrypt-proxy and point the system at it.

Whichever way you settle DoH vs DNSCrypt, measure before picking a resolver, because response times depend on where you are and how traffic is routed to each operator. The DoH speed test runs a cold query and several warm ones against public resolvers from your own browser, and the DNS over TLS page covers the protocol Android uses instead.