The short version: classical DNS sends your queries — every "what's the IP for example.com?" — in plaintext UDP that anyone on the network path can read or modify. DoH wraps those queries in HTTPS, so the on-network observer no longer sees domain names and can't inject false answers. That fixes three legitimate problems (ISP DNS snooping, coffee-shop DNS injection, some forms of state-level DNS censorship) and creates two new ones (parental controls and enterprise security stop working, and you've just told your chosen DoH provider every domain you visit). DoH is neither "more private" nor "less private" — it's differently private, and the question is which trade-off matches your threat model.
What DoH actually is (and what it replaces)
Classical DNS is one of the oldest protocols still in production. It dates to 1983, predates ubiquitous HTTPS, and was designed when "everyone on the network is roughly trusted" was a reasonable assumption. The mechanics: your device sends a UDP packet to port 53 of your configured DNS resolver (usually your ISP's, or 8.8.8.8 / 1.1.1.1 if you've changed it). The packet body, in cleartext, says "give me the A record for example.com." The resolver responds, in cleartext, with the IP. Three properties are worth noting:
- Anyone on the network path can read the query. Your ISP, the coffee-shop WiFi, anyone running tcpdump on the local network — every domain name you look up is in the clear.
- Anyone on the network path can forge a response. If they get a fake answer back to your device before the legitimate resolver does, you've been redirected. This is how some captive portals and some censorship regimes work.
- Your configured resolver sees every query. Whoever runs your DNS knows every domain you visit, in order, with timing.
DoH (RFC 8484, 2018) changes #1 and #2: queries travel inside a TLS-encrypted HTTPS connection to the resolver. On-path observers see HTTPS bytes, not domain names. Forgery becomes the same difficulty as forging any HTTPS response (i.e., effectively impossible without the resolver's TLS cert). #3 doesn't change — the resolver still sees the queries, because they're addressed to the resolver. DoH moves the trust boundary; it doesn't remove it.
DoT (DNS-over-TLS, RFC 7858) does the same thing on a dedicated port (853) instead of riding HTTPS on port 443. Functionally equivalent privacy properties; operationally different. DoH is harder to block at the network level because blocking it requires blocking arbitrary HTTPS, which breaks the whole internet. DoT is easier for network operators to enforce-or-block selectively. DoH won the deployment race largely because Mozilla and Google shipped it inside browsers by default.
Three things DoH genuinely fixes
1. ISP DNS snooping
In the United States since 2017, ISPs have been legally permitted to sell browsing data without explicit opt-in, and DNS query logs are part of what they collect. In other countries the legal regimes vary; in some, mandatory data retention covers DNS by name. Either way: if you're using your ISP's resolver, your ISP has a complete log of which sites you visit, by timestamp.
DoH to a non-ISP resolver (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9, NextDNS, AdGuard DNS, Mullvad's DNS, the resolver inside your VPN) closes this completely from your ISP's perspective. The ISP still sees TLS connections to specific IP addresses, and from those IPs (plus SNI in the TLS handshake, see below) can often infer the hostname — but they no longer have a clean, queryable DNS log. The trust shifts from the ISP to whoever runs your DoH resolver.
2. Coffee-shop DNS injection
Captive portals on public WiFi work by intercepting DNS queries (and HTTP requests) and redirecting them to a portal page until you accept the network's terms. That mechanism — intercepting your DNS — has the same shape as malicious DNS injection. A hostile network can rewrite your DNS responses to redirect you to phishing pages or ad-injection proxies. Plain DNS gives them an easy attack surface; DoH closes it.
This is one of the cases where DoH and a VPN tunnel overlap. A VPN tunnels everything including DNS through encrypted bytes; DoH alone tunnels just the DNS queries. On a hostile network, either intervention defeats the DNS-injection class of attacks, but they handle different layers. We covered the threat landscape in Public WiFi attacks in 2026.
3. Some forms of state-level DNS censorship
Several censorship regimes implement DNS-level blocking: when you ask "what's the IP for blocked-site.com?", the state-mandated resolver returns NXDOMAIN or redirects to a "this site is blocked" page. DoH to a resolver outside the censoring jurisdiction defeats this specific mechanism, because the censoring network sees only HTTPS to the DoH resolver, not the queries inside.
The caveat: this only works until the censor escalates. Sophisticated censorship regimes (China, Iran) block DoH resolvers directly by IP, force HTTPS interception via state-issued root CAs, or use SNI-based blocking (see next section). DoH defeats naive DNS censorship; it doesn't defeat determined nation-state censorship.
Three things DoH doesn't help with
1. SNI leak in the TLS handshake
This is the gotcha most articles skip. When you connect to "example.com" over HTTPS, your browser sends the hostname in the clear during the TLS handshake — specifically in the SNI (Server Name Indication) extension. The reason: a single IP often serves many domains via TLS termination, and the server needs to know which cert to present before the encrypted session begins. SNI is, by design, plaintext.
Net effect: even with DoH, an on-network observer sees which hostnames you connect to via SNI. The DNS-snooping fix is partial. The mitigation is ECH (Encrypted Client Hello) — a relatively new TLS extension that encrypts the SNI. Cloudflare turned on ECH for sites behind their network in 2023, and Firefox + Chrome added support, but adoption outside Cloudflare is still spotty. Until ECH is universal, DoH closes only half of the "who can see which sites you visit" question.
2. IP-based identification of destinations
Even with DoH and ECH, your TLS connections still go to specific destination IPs. For sites with dedicated infrastructure (banks, niche services), the destination IP is a near-perfect identifier of the site even without DNS or SNI. For sites behind major CDNs (Cloudflare, Fastly, AWS CloudFront), IP-based identification is muddier — millions of sites share a few IPs — but the largest sites still get unique infrastructure or distinctive traffic patterns.
DoH doesn't fix this; it can't. A network observer who really wants to know which sites you're visiting can build an IP-to-domain mapping table and look up your traffic destinations. The mitigation is a VPN tunnel, which moves the destination-IP visibility from the local network to the VPN provider. The trust still has to go somewhere; DoH alone leaves it with the network owner.
3. Your DoH provider sees everything you used to leak to your ISP
This is the trade-off DoH marketing usually elides: DoH doesn't make your DNS queries private; it moves visibility from your ISP to your chosen DoH resolver. Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9, NextDNS, AdGuard, and any other DoH provider see every query you make in exactly the way your ISP used to. Some publish strict no-log policies; some publish aggregate-only logging; some sell aggregated data to "research partners." The legal regime around your DoH provider matters as much as the one around your ISP.
Cloudflare's 1.1.1.1 publishes audit reports indicating they discard logs after 24 hours and don't sell DNS data. Google's 8.8.8.8 logs queries (with anonymization) for indefinite periods per their stated retention policy. NextDNS lets you configure your own log retention from "none" to "your account, your choice." The DoH-provider choice matters; the question is which trust relationship you're more comfortable with — your ISP under your country's laws, or your DoH provider under its country's laws.
Two things DoH legitimately breaks
1. Parental controls and family-network filtering
Most consumer parental-control systems work by inspecting DNS at the router or via a configured family-filter DNS resolver (OpenDNS Family Shield, Cleanbrowsing Family, NextDNS family profile). When your kid's device uses these resolvers, lookups for adult content, gambling, etc., return NXDOMAIN. The system depends on the device asking the parental-control DNS resolver in the first place.
Browser-level DoH (Firefox enabled DoH by default in 2019 for US users; Chrome and Edge use the OS resolver but with DoH if configured) silently bypasses these systems. The browser asks Cloudflare or Google directly, the family-filter resolver never sees the query, and the kid gets to whatever site they wanted to visit. This is by design from Mozilla's perspective ("we shouldn't let networks censor"); by accident from a parent's perspective ("the filter we paid for just stopped working").
Mitigations exist but are clunky: configure DoH at the OS level (not browser) to a family-aware resolver like NextDNS family-profile or OpenDNS Family Shield, then disable browser-level DoH so it falls through to the OS choice. Both Apple's Configuration Profiles and Windows Group Policy support this. For most households it's complicated enough to be a real friction.
2. Enterprise security and network-level malware blocking
Most corporate networks implement DNS-based security: a sinkhole DNS server resolves known-malicious domains to nothing (or to an internal alert page), blocking malware command-and-control, phishing redirects, and data-exfiltration to known endpoints. This works because every device on the corporate network uses the corporate DNS, so every lookup gets filtered.
Browser-level DoH silently bypasses this. A compromised browser that should be blocked from reaching its C2 server can simply DoH-resolve the C2 hostname via Cloudflare, get the real IP, and connect directly. Enterprise IT teams responded by either: (a) configuring browser policy to disable DoH, (b) deploying full TLS inspection so the security stack can see inside HTTPS including DoH traffic, or (c) blocking known DoH resolver IPs at the firewall. None of those are pleasant — option (a) leaves users on plain DNS at home as well, option (b) requires installing a root CA on every device, option (c) breaks as new DoH endpoints appear.
DoH on each platform — what's the actual config?
iOS 14+ / iPadOS 14+: Settings → General → VPN & Device Management → DNS — but only via an installed configuration profile. iOS doesn't expose DoH in the standard Settings UI; you install a .mobileconfig file (Cloudflare, Quad9, NextDNS, AdGuard, Mullvad all publish them). Once installed, every app on the device uses DoH to that resolver. This is by design — iOS treats DoH as an OS-level setting, not per-app.
Android 9+: Settings → Network & internet → Advanced → Private DNS — but this is actually DoT, not DoH. Android implemented "Private DNS" using DoT (port 853) rather than DoH (HTTPS). Functionally equivalent privacy properties; the protocol is different. Enter the hostname of a DoT resolver (one.one.one.one for Cloudflare, dns.google for Google, dns.adguard.com for AdGuard) and Android encrypts every DNS query system-wide.
macOS 11+: same configuration-profile mechanism as iOS. Apple ships its own DoH support but doesn't expose it via System Settings; you install a profile.
Windows 11: Settings → Network & Internet → adapter properties → DNS server assignment → "Encrypted only (DNS over HTTPS)" — Windows knows about Cloudflare, Google, and Quad9 by default and will auto-configure DoH if you set those IPs. Windows 10 has DoH support but it's harder to find.
Browser-level DoH: Firefox enables DoH by default for US users (Settings → Privacy & Security → DNS over HTTPS). Chrome calls it "Secure DNS" (Settings → Privacy and security → Security). Safari uses macOS-level config rather than browser-specific config. Edge uses Windows-level. Browser DoH is fast to enable but creates the parental-control / enterprise bypass problem above; OS-level DoH puts the decision in one place where it can be governed.
Picking a DoH resolver — the honest comparison
Picking your DoH resolver is the actual privacy decision DoH lets you make. The major options:
- Cloudflare 1.1.1.1: fast (anycast, sub-15ms in most metros), 24-hour log retention, audited annually. Has a "family" variant (1.1.1.3) that blocks adult content. Cloudflare also offers WARP, a VPN-lite that combines DoH with a tunnel to Cloudflare's network.
- Google 8.8.8.8: fast, ubiquitous, indefinite log retention per Google's stated policy. Privacy reasonable enough by Google standards, but if "trust Google with another data stream" is a sticking point, look elsewhere.
- Quad9 9.9.9.9: nonprofit Swiss foundation, blocks known-malicious domains as a default behavior, stated no-log policy, more conservative on data than most.
- NextDNS: configurable per-profile (blocklists, family filter, log retention) — the power-user choice. See our comparison for depth.
- AdGuard DNS: blocks ads/trackers at the DNS layer aggressively, supports both DoH and DoT.
- Mullvad DNS: available standalone (no VPN subscription required), Swedish, configurable content blocking, accessible via DoH and DoT.
- Your VPN provider's resolver: Casper's Cloak, ProtonVPN (NetShield), Mullvad — DNS handled inside the VPN tunnel, no separate config required. Convenient; means trusting the VPN provider for both layers, which is unavoidable if you use a VPN anyway.
The honest framing: there is no "best" DoH resolver; there's a best one for your threat model. Speed matters for some, blocklists for others, no-log policy for others, jurisdiction for others. Pick one, configure it OS-level (not just browser-level) so the choice covers every app, and revisit when your priorities or any resolver's transparency reports change.
Where DoH fits with VPNs and ad-blocking — the unified picture
Three independent privacy layers, each closing a different attack surface:
- VPN tunnel: encrypts the destination-IP visibility from the local network, moves it to the VPN provider. Closes "the coffee shop / ISP can see which IPs you connect to."
- DoH / DoT: encrypts the DNS queries from the local network and from the ISP, moves DNS visibility to the DoH resolver. Closes "DNS log on file with the ISP" and "DNS injection at the network level."
- DNS-level content filtering (Pi-hole, NextDNS, AdGuard DNS): blocks lookups for ads, trackers, malware, phishing — at the resolver. Closes "every app on your device is loading tracker SDKs whose endpoints could be blocked at the DNS layer."
DoH alone is one layer. A real privacy posture stacks all three. Casper's Cloak is built to deliver this stack as a single app: VPN tunnel + Pi-hole DNS filtering (we run a Pi-hole instance per user as the resolver) + ML-based zero-day phishing detection on top of the static blocklists. DoH is implicit in how that's wired — DNS queries between the device and our resolver are encrypted. The honest framing is that this is one valid architecture; another is "configure DoH OS-level to NextDNS, layer your-own-VPN of choice, get the same end state with more knobs." Both work; the trade-off is convenience vs configurability. We covered the same point from the DNS-filtering angle in How DNS-level filtering actually works.
Bottom line
DoH is a real and useful privacy improvement, with caveats that aren't in the marketing copy. It closes ISP DNS snooping, coffee-shop DNS injection, and naive censorship — three real problems for real users. It doesn't close SNI leakage, IP-based destination identification, or trust in your chosen resolver. And it breaks parental controls + enterprise security in legitimate use cases unless you configure carefully.
The single most important DoH decision is which resolver you pick, configured at the OS level so every app gets it consistently. The second most important decision is whether to layer DoH with a VPN tunnel (closes destination-IP visibility) and DNS-level content filtering (blocks ads/trackers/malicious-domain lookups). DoH alone solves one layer; the unified stack solves the surface area.
Related: How DNS-level filtering actually works covers the filtering layer DoH alone doesn't include; Public WiFi attacks in 2026 covers the network-hostility threat model DoH helps with; Free VPN vs paid VPN in 2026 covers the VPN-tunnel layer. The NextDNS comparison and Pi-hole comparison go into the configurable-DNS-resolver choices.