DNS over HTTPS (DoH) Explained — Encrypted DNS for Resolver-Client Privacy

DNS over HTTPS — DoH, standardised in RFC 8484 — is one of the most consequential DNS protocol changes of the last decade. It changes who can see your DNS queries, who can interfere with them, and how the politics of DNS resolution play out. This guide is a focused explainer of what DoH actually is, who runs it, and where it ends.

For the integrity-vs-privacy comparison with DNSSEC, see DNSSEC vs DNS over HTTPS. For the closely-related DoT, see DNS over TLS (DoT) explained.

What DoH Actually Is

DoH wraps a DNS query in an HTTPS request. Instead of sending a UDP packet to port 53 of a resolver, the client makes an HTTPS POST or GET request to a resolver's DoH endpoint (a URL like https://cloudflare-dns.com/dns-query).

The request body is the same DNS wire-format query that would go over UDP/53 — DoH doesn't change DNS semantics, just transport. The HTTPS layer adds:

• TLS encryption of the entire conversation
• Authentication of the resolver via its TLS certificate
• Indistinguishability from normal HTTPS traffic on TCP/443

A simplified DoH request:

POST /dns-query HTTP/2
Host: cloudflare-dns.com
Accept: application/dns-message
Content-Type: application/dns-message
Content-Length: 33
 
[binary DNS query payload]

The response is the binary DNS wire-format answer in the HTTPS response body.

What DoH Protects Against

The threat model is network observers between client and resolver:

• Your ISP seeing every domain you visit
• A Wi-Fi operator (coffee shop, hotel, airport) intercepting DNS
• An on-path attacker with a network tap or rogue access point
• A government doing passive DNS surveillance at the network layer

In all of these cases, plain DNS exposes the queries; DoH hides them inside HTTPS to the resolver. The observer can see "this client is talking to cloudflare-dns.com over HTTPS" but not "this client is looking up example.com".

What DoH Does NOT Protect

DoH does not change the relationship between client and resolver. The resolver still sees every query you make and can log it, sell it, or be subpoena'd for it. If your resolver is your ISP's DoH endpoint, your ISP still sees everything — DoH just stops anyone else from seeing it.

If privacy from the resolver itself matters, the answer is Oblivious DNS over HTTPS (ODoH, RFC 9230), which adds a relay between client and resolver:

Client ──── encrypted query ────▶ Relay ──── encrypted query ────▶ Resolver
       ◀────── encrypted answer ───────  ◀────── encrypted answer ───────

The relay can see the client's IP but not the query content. The resolver can see the query content but not the client's IP. Neither alone can correlate client to query. ODoH is supported by Cloudflare, but client adoption is much narrower than DoH itself.

DoH Is Not DNSSEC

This is the most common misunderstanding. Plain English:

A DoH conversation can deliver completely tampered DNS data — DoH itself doesn't care what's in the payload, just that the channel is encrypted. DNSSEC validation at the resolver (or the client) is what catches tampered data. The two layers solve different problems and modern stacks deploy both.

See DNSSEC vs DNS over HTTPS for the deeper comparison.

DoH vs DoT

DoT (DNS over TLS, RFC 7858) solves the same problem with a slightly different shape:

The political consequence: DoH is harder for network operators to identify or filter, which is the design goal from a user-privacy perspective and a frustration from a corporate-DNS-filtering / parental-controls perspective. Some networks block DoH outright; some block specific public DoH resolvers.

Public DoH Resolvers

Major public resolvers all support DoH:

Choose based on your trust model — these resolvers see every query you make.

Browser and OS Support

By 2026, DoH is broadly deployed:

• Firefox — DoH on by default in many regions, often via Cloudflare or NextDNS, with user-configurable resolver
• Chrome / Chromium / Edge — automatic DoH upgrade if the configured DNS resolver advertises DoH support
• Safari (iOS / macOS) — supports DoH and DoT via configuration profiles or app-level settings
• iOS / iPadOS — Encrypted DNS profiles supported since iOS 14
• Android — Private DNS supports DoT since Android 9; DoH support added in later versions
• Windows 11 — Native DoH support for configured resolvers
• Linux — systemd-resolved and standalone resolvers (stubby, dnscrypt-proxy) support DoH/DoT

Why Authoritative DNS Doesn't Use DoH

DoH is a recursive-resolver-side protocol. It encrypts the query path from a client to a resolver. The path from a resolver to an authoritative server (where DNScale lives) is a different segment with a different threat model:

• Recursive-to-authoritative queries are public-resolver-to-public-server, often crossing dozens of networks.
• The attack surface is different: the threat is mostly cache poisoning / forged answers, which DNSSEC addresses.
• Encrypting recursive-to-authoritative is an emerging area: ADoT (Authoritative DNS over TLS) and proposals for DoH on authoritative servers exist but are not widely deployed. The IETF Working Group dprive is actively discussing the standards.

In practice, in 2026, authoritative DNS is mostly unencrypted (with DNSSEC for integrity), and resolver-to-client is increasingly encrypted (DoH/DoT) for privacy. ADoT is being trialled at large operators (Cloudflare, Google) but isn't yet a default expectation.

Deployment Patterns

Client-only

Just turn on DoH in your browser or OS. Done. Your queries to your configured resolver are now encrypted; everything else is unchanged.

Stub resolver

Run a local DoH/DoT client (dnscrypt-proxy, stubby, cloudflared, dnsproxy) that listens on 127.0.0.1:53 and forwards everything via DoH/DoT to your chosen public resolver. Your applications don't need to know — they query localhost as plain DNS, the proxy handles the encryption.

Network-level

Deploy a DoH-aware recursive resolver on your network (unbound, knot-resolver, pdns-recursor) that forwards upstream queries via DoH/DoT to a public resolver, and serve plain DNS to your local clients. Centralises the trust decision and lets you enforce DNS filtering, logging, or split-horizon at one point.

Application-level

Some applications (modern browsers, mobile apps with their own networking) bypass system DNS and make direct DoH queries. This means your network-level DNS controls (filtering, logging, internal-DNS resolution) can be circumvented. Corporate networks often respond by blocking known DoH endpoints — but this becomes an arms race.

Operational Trade-offs

DoH is genuinely good for users. It's also a real challenge for some operational scenarios:

Pros:

• Privacy from network observers
• Bypass of network-level DNS censorship
• Authentication of the resolver (you know you're talking to the right one)

Cons:

• Bypass of network-level DNS controls (filtering, logging, internal DNS for split-horizon)
• Enterprise security tools that depend on DNS visibility (DNS-based malware blocking, exfiltration detection)
• Diagnosis is slightly more involved when DoH-using applications bypass the OS resolver

For corporate networks, the typical resolution is to block public DoH endpoints at the firewall and force clients to use the corporate resolver (which itself may speak DoH to upstream). This is a moving target as new resolvers and endpoints emerge.

Testing DoH

Verify DoH is working from a Linux/macOS terminal:

# Using curl with DoH wire format
curl -H 'accept: application/dns-message' \
  'https://cloudflare-dns.com/dns-query?dns=AAABAAABAAAAAAAABmdvb2dsZQNjb20AAAEAAQ' \
  --output - | xxd
 
# Using kdig (Knot's dig variant) which supports DoH natively
kdig @1.1.1.1 +https example.com
 
# Using dig with --doh on dig 9.18+
dig @https://cloudflare-dns.com/dns-query example.com

For browsers: https://1.1.1.1/help shows whether your current connection is using DoH and via which resolver.

Related Reading

• DNS over TLS (DoT) explained — the close cousin of DoH
• DNSSEC vs DNS over HTTPS — integrity vs privacy
• What is DNSSEC? — the integrity layer
• How DNSSEC works — KSK/ZSK/DS mechanics
• DNS cache poisoning — the attack DNSSEC and DoH together help mitigate
• DNS attacks and threats — the broader threat landscape

References

• RFC 8484 — DNS Queries over HTTPS (DoH)
• RFC 7858 — Specification for DNS over Transport Layer Security (TLS)
• RFC 9230 — Oblivious DNS over HTTPS (ODoH)
• RFC 8094 — DNS over Datagram Transport Layer Security (DTLS)
• IETF DPRIVE Working Group — DNS PRIVate Exchange
• Mozilla: Firefox DNS over HTTPS deployment notes
• Cloudflare: 1.1.1.1 DoH documentation