DNS over HTTPS (DoH, RFC 8484) routes DNS queries over HTTPS connections to a resolver, hiding query content from network observers. It shipped in Firefox in 2019, Chrome in 2020, and is now available natively in Windows, macOS, iOS, and Android. The deployment is broad. The privacy improvement is real — and more limited than most coverage suggests.
What Plaintext DNS Leaks
Traditional DNS operates over UDP port 53, unencrypted and unauthenticated. Every DNS query is visible to:
- Your ISP
- Any network operator between you and the resolver
- Anyone with passive access to the network path (coffee shop router, ISP middlebox, national-level passive taps)
The query content reveals which domains you’re looking up, which correlates strongly with which services you’re using even without seeing any HTTP traffic. DNS responses can also be spoofed — there’s no integrity protection without DNSSEC.
A packet capture on a plaintext DNS connection is blunt and immediate:
13:04:22.341 UDP 53 → 8.8.8.8 query: example.com A
13:04:22.389 UDP 8.8.8.8 → 53 response: 93.184.216.34Anyone with network access sees the full query and response.
What DoH Changes
DoH wraps DNS queries in HTTPS. The query is a POST or GET request to a resolver endpoint:
POST /dns-query HTTP/2
Host: cloudflare-dns.com
Content-Type: application/dns-message
Accept: application/dns-message
<binary DNS wire format>From the network’s perspective, this is indistinguishable from any other HTTPS traffic to cloudflare-dns.com. The query content is encrypted. A passive observer on the wire sees:
- That you connected to an IP address hosting a DoH resolver
- The TLS SNI in the ClientHello (unless ECH is active — more on that below)
- Roughly when and how much data was exchanged
They do not see which domain you queried.
DNSSEC provides integrity for the DNS record itself — the response is cryptographically signed by the zone owner. DoH adds confidentiality of the query in transit. They’re complementary.
What DoH Doesn’t Fix
The Resolver Sees Everything
DoH hides queries from your ISP and network path. It does not hide queries from the DoH resolver. Cloudflare, Google, NextDNS — whoever operates your DoH resolver receives every query in plaintext. You’ve shifted trust, not eliminated it.
For most users, shifting from their ISP (who historically sells metadata and complies with broad surveillance demands) to a privacy-focused resolver is a net improvement. But it’s a trust delegation, not a privacy guarantee.
IP Address Correlation
Most DNS queries lead to a connection. If you resolve example.com and then open a TCP connection to 93.184.216.34, a network observer who can’t see the DNS query can still see the IP connection. For services on dedicated IPs, the correlation is direct. For CDNs serving thousands of domains on shared infrastructure, it’s weaker.
SNI Leaks the Hostname
During the TLS handshake, the client sends the target hostname in the Server Name Indication extension — unencrypted, before the encrypted tunnel is established:
ClientHello
server_name: "example.com" ← visible to network observersSo even with DoH hiding the DNS query, the SNI reveals the target hostname to anyone who can see the connection. You’ve encrypted the lookup but broadcast the connection.
Encrypted Client Hello (ECH) is the fix. It encrypts the SNI using a public key published by the server in DNS (HTTPS/SVCB records). ECH is in active deployment but not yet ubiquitous — as of 2026, Cloudflare and a handful of large CDNs support it. Browser support is shipping but patchwork.
With ECH active, the ClientHello shows only the name of the ECH-capable proxy (the “outer” SNI, typically something like cloudflare-ech.com), not the actual target.
Application-Level Leaks
Content, URLs, cookies, and tracking IDs are separate concerns. DoH does nothing about fingerprinting, third-party trackers embedded in pages, or metadata leakage at the application layer.
DoH Deployment Models
┌──────────────────────────────────────────────────────────┐
│ Stub resolver (OS / browser) │
│ ↓ HTTPS │
│ DoH resolver (Cloudflare, Google, NextDNS, self-hosted) │
│ ↓ UDP/TLS (Do53 or DoT) │
│ Authoritative nameservers │
└──────────────────────────────────────────────────────────┘Self-hosting a DoH resolver (e.g., dnss, coredns with DoH plugin, AdGuard Home) on a VPS gives you full control over the resolver trust boundary. The resolver still talks to authoritative nameservers over plaintext UDP by default unless you configure it to use upstream DoH/DoT.
For enterprise networks, centralized DoH creates tension with DNS-based security monitoring. Endpoint DoH bypasses DNS-layer controls (sinkholes, malware domain blocking, DLP). Most enterprise security platforms and DoH implementations now support split-horizon configurations or policy enforcement via DNS64/NAT64 or resolver override.
DNS over TLS vs. DNS over HTTPS
DoT (RFC 7858) provides the same confidentiality guarantee as DoH, over TLS on port 853. The differences are operational:
| DoH | DoT | |
|---|---|---|
| Port | 443 | 853 |
| Firewall bypass | Blends with HTTPS traffic | Distinct port, easily blocked |
| Multiplexing | HTTP/2 or HTTP/3 | TLS only |
| Browser integration | Native (browsers control it) | OS resolver or client app |
DoH is harder to block without collateral damage (you’d have to block all HTTPS to the resolver IP). DoT is operationally cleaner for network administrators who want visibility.
Practical Takeaways
DoH is a meaningful improvement over plaintext DNS — it closes a specific, well-understood surveillance vector. Its limitations:
- Resolver trust is not eliminated, just relocated. Choose your resolver based on its logging and retention policy.
- SNI leaks what DoH hides. ECH is the complement; push for ECH support in your stack.
- IP correlation partially closes the gap. Meaningful for dedicated IPs, weak for shared CDN infrastructure.
- DNS-layer security controls need explicit design in environments deploying DoH.
Use DoH. Audit your resolver choice. Deploy ECH where you control the server. Don’t confuse encrypted DNS with comprehensive traffic privacy.