DNS over HTTPS sounds like one of those browser settings you should simply turn on and forget. It has privacy in the pitch, HTTPS in the name, and support from major browsers and DNS providers. That does not make it magic.
DoH fixes a real leak in old DNS. It also moves trust from one place to another. For normal users, that difference matters. For developers, it can explain weird bugs where Chrome reaches a site, but a command-line tool cannot. For companies and schools, it can affect filtering, logging, and internal hostnames.
The short version: DoH encrypts the lookup that turns a name like example.com into an IP address. It does not hide every site you visit. It does not make your browser anonymous. It does not replace a VPN, Tor, good account security, or careful app design.
Why DNS was leaky in the first place
Before your browser connects to most sites, it needs an IP address. DNS is the phone book step. Your device asks a resolver, usually provided by your ISP, router, company, mobile carrier, or a public DNS service.
Traditional DNS is usually sent in clear text. Anyone on the network path can often see the names being requested. On public Wi-Fi, that could be the hotspot operator. At home, it could be the ISP or a compromised router.
The query is not the full page URL. DNS asks for a domain name, not the exact article, search term, or checkout page. Still, domain names say a lot.
Old DNS also makes tampering easier. A network can block a domain by returning a fake answer. HTTPS helps after the connection starts, but the DNS step was still exposed.
What DoH actually does
RFC 8484 defines DNS over HTTPS as DNS queries and responses carried inside normal HTTPS exchanges. The DNS message is still DNS. The transport changes.
Instead of sending a visible DNS packet to port 53, a DoH client sends an HTTPS request to a DoH resolver. Cloudflare describes this as wrapping DNS queries inside regular HTTPS requests. That makes the lookup encrypted and harder to separate from other HTTPS traffic.
This gives DoH two practical benefits.
First, local observers have a harder time reading your DNS questions. Someone on a coffee shop Wi-Fi network should not be able to passively list every domain your browser asks for just by watching DNS packets.
Second, on-path tampering gets harder. If your device is really connected to the chosen DoH resolver over HTTPS, a router in the middle cannot easily forge the DNS answer without breaking the secure connection.
That is a useful privacy and security upgrade. It is similar in spirit to moving websites from HTTP to HTTPS: the network gets less easy visibility and less easy control.
But it is only the lookup step.
What DoH does not hide
DoH does not hide the destination IP address your device connects to after the lookup. Networks can still see that your device opened a connection to an IP. With large hosting providers and content delivery networks, that IP may host many sites. With smaller services, the IP can still be a strong clue.
DoH does not hide data from the DNS resolver you choose. The ISP may see less DNS traffic if you switch away from the ISP resolver, but the new resolver now sees those lookups. A public resolver can see query names, timing, source IP address, and patterns unless its design or policy reduces that data. The question changes from "Can my local network see this?" to "Which resolver am I trusting?"
DoH does not hide the site from the site. If you sign in, accept cookies, load tracking scripts, or use an app tied to your account, DNS privacy is not the main privacy boundary. See also the privacy and security distinction in passkeys explained.
DoH may not hide hostnames exposed during the TLS handshake. Server Name Indication, or SNI, has long allowed a client to say which hostname it wants before the encrypted web session is fully set up. Encrypted Client Hello can reduce that leak when supported, but DoH alone does not solve it.
DoH also does not hide browser history, device malware, app telemetry, account logins, or payment records. If an app sends analytics to its own servers, changing DNS transport will not stop that.
Browser DoH versus operating system DoH
A confusing part of DoH is where it runs.
Google says Chrome encrypts information during lookup when Secure DNS is on, uses automatic mode by default, and can fall back in some failure cases. Users can also pick a custom provider, where Chrome says it will not default to unencrypted mode.
Firefox also exposes DNS over HTTPS in browser settings. Browser-level DoH is attractive because it is easy to ship and easy for a user to change. You can improve privacy in the browser without waiting for the router, ISP, or operating system to support encrypted DNS.
The tradeoff is split behavior.
Your browser might use one resolver while the rest of the device uses another. Chrome may resolve a name through Secure DNS. A terminal command may use the OS resolver. A game, email client, package manager, or native app may do something else. If you are debugging, this can make the same hostname work in one place and fail in another.
Operating system encrypted DNS gives more consistent behavior across apps. When the OS owns the resolver policy, browsers, CLI tools, and native apps are more likely to follow the same path. That is cleaner for users and easier for support teams.
But OS-level setup varies by platform, network, and management policy. Some networks advertise resolvers automatically. Some users pick a public provider. Some companies lock settings. Some apps still bring their own resolver code.
For developers, the safe assumption is boring: DNS behavior is part of the runtime environment. Test browser, server, mobile, and CLI paths separately when DNS matters. Do not assume a lookup failure means the domain is down.
The resolver choice is the privacy choice
Turning on DoH is not the same as choosing a trustworthy resolver.
A resolver can log less or log more. It can block malware domains or avoid filtering. It can be fast in your region or slow. It can support enterprise policies or ignore them.
For normal users, the default browser or OS choice is usually fine if the goal is to reduce casual local snooping. If you choose a custom provider, read its privacy policy. Look for plain answers about query logs, IP address storage, data sharing, filtering, and jurisdiction.
For developers and teams, resolver choice is also an operational dependency. If your app, CI system, or office network relies on internal names, private zones, or DNS-based service discovery, a public DoH resolver may not know those names exist.
This is where privacy tradeoffs look a lot like local-first software. Moving a boundary is not the same as removing trust, a pattern that also appears in local-first apps.
Enterprise, school, and home network caveats
DoH can break assumptions on managed networks.
Companies often use DNS for internal names such as git.internal, split-horizon records, malware blocking, phishing protection, and incident response logs. Schools and families may use DNS for content filters. Hotels and airports may use DNS tricks for captive portals.
This is why browser vendors treat managed devices and parental controls carefully. Chrome's help page says Secure DNS may not be available when the device is managed or parental controls are enabled. That is a policy decision to avoid silently bypassing controls the device owner or administrator expects.
For enterprises, the answer is not to pretend DoH does not exist. It is to manage it directly. Pick approved encrypted resolvers. Publish clear policy. Make internal domains work. Decide whether fallback to unencrypted DNS is allowed. Monitor failures. Tell users what changes.
For home users, the advice is simpler. If turning on DoH makes work VPN, school filtering, or a login portal fail, try automatic mode first, then check the network's instructions. On untrusted Wi-Fi, a trusted DoH resolver helps, but a VPN or Tor may fit a wider threat model.
A practical checklist
Use DoH when you want less DNS visibility on local networks, especially public Wi-Fi, shared housing, travel networks, or ISP connections.
Prefer automatic browser or OS settings if you want fewer support problems. Pick a custom resolver if you know why you trust it more than the default.
Do not treat DoH as anonymity. The resolver, destination IPs, TLS metadata, accounts, cookies, and app traffic still matter.
Developers should test with both browser and system tools. Check nslookup, dig, mobile devices, VPN mode, and corporate networks before blaming a DNS provider.
Admins should treat DoH as part of network policy, not as an enemy. Encrypted DNS can protect users and still respect internal needs if settings are managed clearly.
The best mental model is this: DoH closes one old window. It makes DNS lookups harder to watch and harder to alter between you and your resolver. It does not close every other window in the house.
