How DNS over HTTPS keeps your browsing private
· 9 min read
DNS over HTTPS encrypts DNS lookups, hiding what 84% of Android VPN apps leaked in 2016. Enable it in Chrome, Firefox, Edge, Windows, or Android.
DNS over HTTPS, usually shortened to DoH, is a protocol that encrypts your domain lookups inside ordinary HTTPS traffic. If you have asked what is DNS over HTTPS, the working answer is this: DoH wraps the queries your browser makes to translate domain names into IP addresses in the same encrypted channel it already uses for web pages, so nobody between you and your resolver can read them. The topic is timely because plaintext DNS is one of the last unencrypted streams on the modern internet, and the August 2026 WebKit leak disclosures, which showed lookups escaping proxies on iOS and macOS, pushed encrypted DNS back into the headlines.
The unglamorous truth is that encrypted DNS fixes a real, measurable exposure. Resolving example.com sends a small question about your browsing habits to whoever runs your resolver, and on most home networks that is your ISP. This guide explains what DoH does, why it matters, how to switch it on in the five places people actually configure it, and the trade-off most explainers skip: DoH moves trust, it does not remove the need for it.
Key Takeaways
- DNS over HTTPS encrypts name lookups inside HTTPS traffic per RFC 8484, so your ISP stops reading which domains you resolve.
- Plaintext DNS is a real exposure: a 2016 study of 283 Android VPN apps found that 84% leaked DNS requests.
- DoH moves trust to your chosen resolver, hides lookups from your ISP, and closes tunnel-level leaks, not browser-level WebKit vectors.
- Pair DoH with a full leak-test routine, and re-test after every OS update.
What Is DNS over HTTPS?
DNS over HTTPS is exactly what its name says: DNS queries sent over an HTTPS connection instead of plaintext UDP port 53. The specification, RFC 8484, was published in October 2018, and it defines how to encode DNS messages inside HTTPS requests and responses (RFC 8484). Each lookup rides the same encrypted channel a web page uses, which means it inherits TLS encryption, certificate validation, and the familiar port 443.
The format matters as much as the transport. RFC 8484 maps the standard DNS wire format onto HTTP GET and POST methods, so a DoH client and server agree on how to carry queries without breaking caching or retries (RFC 8484). Earlier encrypted DNS efforts stayed experimental or proprietary, but DoH arrived with a formal standard and landed in every major browser within a couple of years (Wikipedia's DNS over HTTPS entry).
How it works under the hood is simpler than it sounds. Your browser takes the same DNS question it would have sent in plaintext, wraps it in a normal HTTPS request to a resolver such as Cloudflare 1.1.1.1, and the resolver returns the answer in an HTTPS response. To the network, that traffic is indistinguishable from a request to any other site on port 443. To you, nothing changes except the route the question takes.
DNS is the phone book of the internet. Before you can load any site, your device asks a resolver to translate the domain into an IP address, and in the default setup that question travels unencrypted on port 53. Encrypted DNS does not change what gets asked. It changes who can listen to the asking.
Why DNS over HTTPS Matters
Plaintext DNS has been a reliable surveillance channel for decades, and the numbers explain why the industry moved. In 2016, researchers tested 283 VPN applications from Google Play and found that 84% leaked DNS requests outside the tunnel (the original IMC 2016 study). The failure mode is not ancient history either. Android still leaks DNS outside VPN tunnels in specific configurations, with Mullvad documenting the behavior and Google's issue tracker carrying the reports (Mullvad's Android analysis, Google Issue Tracker).
Every DNS lookup names a site you intend to visit. Collected over time, that stream describes your browsing history, and whoever reads it can build a profile, apply content filters, or serve block pages. Your ISP is the usual observer because it runs the default resolver, but any network operator, public Wi-Fi owner, or attacker with a vantage point on port 53 sees the same plaintext. DoH closes that specific window: the on-path observer sees an HTTPS request to a resolver, not the list of domains you asked for.
Adoption moved quickly once the standard existed. Wikipedia records DoH support arriving in Chrome, Firefox, Edge, and Safari within a couple of years of RFC 8484's publication (Wikipedia's DNS over HTTPS entry). That rollout pattern matters: when a privacy feature becomes a default rather than a toggle, the plaintext alternative has become indefensible.
One nuance: DoH encrypts the lookup, not the connection that follows. Your ISP still sees the IP addresses of the sites you visit, because TCP connections to them are visible by nature. DoH narrows the exposure from a complete browsing log to a list of destination IPs, a meaningful privacy gain but not anonymity.
How to Enable DNS over HTTPS
Encrypted DNS is now a settings toggle in every major browser and operating system, and each change takes under a minute. Cloudflare maintains a plain-language setup guide for its 1.1.1.1 resolver, and the steps below follow the same provider defaults you will find there (Cloudflare's DoH setup guide). Pick one provider per device, then test after every change.
- Chrome and Edge. Open Settings, then Privacy and Security. Enable the secure DNS option and choose a provider such as Cloudflare 1.1.1.1 or Google 8.8.8.8.
- Firefox. Open Settings, then Privacy and Security, and scroll to DNS over HTTPS. Firefox lets you pick a provider or keep its default, and it flags the resolver as unreachable if something blocks it.
- Windows. Open Settings, Network and Internet, and edit your adapter's DNS settings. Windows 11 assigns encrypted DNS providers directly and shows a lock icon when the connection is protected.
- Android. Open Settings, Network and Internet, then Private DNS. Choose the private provider hostname option and enter an encrypted DNS hostname such as one.one.one.one for Cloudflare.
- macOS and iOS. Add a DoH configuration profile for your network connection, or use a browser-level toggle such as Firefox's where it is available.
Two details trip people up. Android's Private DNS setting is DNS over TLS (DoT), not DoH, and it expects a hostname rather than an IP address, so pasting 1.1.1.1 into the box fails; use one.one.one.one instead (per Cloudflare's guide). And the OS-level toggle is the stronger option, because it also encrypts lookups from email clients and background apps, while a browser toggle only covers the browser.
After you flip any of these switches, verify the change actually works. Visit your provider's DoH status page, or run a leak test with your VPN on and off. The status page should report an encrypted connection, and a leak test should show only your chosen provider's servers in the results. If you see your ISP's servers instead, the toggle did not stick, which usually means a network setting or an app overrides it.
The Trust Trade-Off: Your Resolver Becomes the Observer
This is the part most explainers skip: DoH moves your lookups from your ISP to the resolver you choose. Encrypting a query does not delete it, it reroutes it. Where the ISP's DNS server once saw every domain you resolved, now Cloudflare, Google, or whatever provider you picked sees the same list. RFC 8484 standardizes the transport, not the trust, because it defines how queries travel, never who may run the server (RFC 8484).
So the honest question is not whether your lookups are private, but private from whom. DoH defends against on-path observers: your ISP, a public Wi-Fi hotspot, a hotel network, a censor at the border. It does nothing to hide your browsing from the resolver itself, and that resolver now pairs your IP address with every domain you ask for. That is why the privacy community splits on DoH, and why resolver choice matters more than protocol choice.
The practical rule: treat your DoH provider like a weak version of your search engine. You are handing it a record of every site you visit, so pick one you can name, read its privacy policy, and prefer a provider with audits and no data retention. Cloudflare publishes one for 1.1.1.1, and most providers publish theirs, but the exercise is yours to do, because nobody else will do it for you.
There is also the connection-metadata angle. DoH hides your lookups, but the connections that follow still leak meaning: your ISP sees the IP addresses of every site you visit, the timing of each connection, and the amount of data transferred. DNS was never the only source of browsing signal, only the most readable one. DoH upgrades that stream from plaintext to ciphertext, and it is a layer in a defense, not a cloak.
Does DNS over HTTPS Stop DNS Leaks?
Partially, and the qualification is essential. DoH closes the tunnel-level leak: if a VPN fails to route a lookup, the encrypted query still reaches your chosen resolver privately, because the network between you and the resolver cannot read it. That is a genuine win, and encrypted DNS belongs in any leak-fighting toolkit. But DoH only covers the path from your device to the resolver you configured, and it does nothing about lookups that escape your browser or device entirely.
The 2026 WebKit findings are the clearest example. Mysk disclosed that dns-prefetch, WebAuthn, and WebTransport traffic bypasses proxy settings on iOS and macOS, and Apple's iCloud Private Relay (how it works) does not cover them (Mysk's disclosure). A browser feature that resolves a domain outside the browser's network stack bypasses your DoH setting completely, because that setting is simply not in the path. Private Relay is itself a DoH-adjacent design, a dual-hop proxy with Apple ingress and Cloudflare or Fastly egress (Wikipedia: iCloud Private Relay), yet even it leaks through these vectors.
Android shows the same lesson on the OS side. Mullvad documented DNS leaking outside the VPN tunnel on Android, tied the failure to a specific CVE, and advised re-testing after every OS update, because an update can silently change how lookups route (Mullvad's Android report). Encrypted DNS cannot rescue a lookup that was never sent through the tunnel in the first place.
The bottom line: DoH stops the passive, tunnel-level leak and nothing more. It does not stop WebRTC IP leaks, and it does not make a misconfigured VPN trustworthy. For those, you need a full leak-test routine. Our DNS leak test guide walks through the 2026 WebKit vectors, the testing steps, and the fixes that go beyond DoH (DNS leak test guide). A useful first check: record your baseline IP with ToolSura's ip address lookup, enable DoH and your VPN, then compare resolver lists on a leak test site.
DNS over HTTPS Is Not DNS over TLS
DNS over HTTPS and DNS over TLS (DoT) both encrypt DNS, and people conflate them constantly. The difference is the channel. DoT, defined by RFC 7858 in May 2016, wraps DNS in TLS on its own dedicated port 853 (RFC 7858). DoH, per RFC 8484, wraps DNS inside HTTPS on port 443, the same port as every web page (RFC 8484). Same encryption idea, different disguises. The practical differences, in one table:
| DoH | DoT | |
|---|---|---|
| Standard | RFC 8484 (Oct 2018) | RFC 7858 (May 2016) |
| Port | 443, blends with web traffic | 853, dedicated and visible |
| Blockability | Hard to block without breaking HTTPS | Easy to filter at the port level |
| Best for | Circumvention, ISP privacy | Managed networks, enterprise policy |
The port matters more than it looks. A network operator can block DoT by filtering port 853, and many do, because that port carries almost nothing else. DoH on port 443 blends into ordinary web traffic, so an operator who allows HTTPS cannot block DoH without breaking the web itself. That makes DoH the tool of choice for circumvention and DoT the easier option for your own infrastructure, since a dedicated port is simpler to run and to inspect.
DoT also reveals its purpose to observers: they see TLS traffic to a known DNS host on a known port. DoH hides the fact that DNS is happening at all, a privacy win that doubles as a filtering headache for enterprises. For the full comparison, including which protocol wins for censorship resistance versus corporate filtering, see our dedicated breakdown (DNS over HTTPS vs DNS over TLS).
Related Tools & Further Reading
These posts and tools round out the picture. The hub frames every leak vector, the siblings cover the protocol comparison and Apple's proxy, and the tool gives you the baseline every test needs.
- DNS Leak Test: What It Is and How to Check: the cluster hub, with testing steps, the 2026 WebKit disclosure, and the fixes that go beyond DoH.
- DNS over HTTPS vs DNS over TLS: port-level trade-offs and the censorship versus enterprise question.
- iCloud Private Relay Explained: Apple's dual-hop proxy uses Oblivious DNS over HTTPS, which makes it DoH's closest cousin among consumer privacy products.
- IP Address Lookup: record your public IP before and after enabling DoH, the baseline for any leak test.
- SSL Checker — Validate Certificates Before Visitors Do
Written by
Grace Adeyemi
My whole beat is three records answering the same question from different directions: who may send mail as this domain. SPF looks at the DNS record and the connecting host. DKIM signs the message and carries the signature in a header. DMARC ties a visible From address to a policy and tells receiving servers what to do when the two disagree.
Hold that shape and the failures stop being mysterious. SPF has a hard limit of ten DNS lookups, and includes, redirects and MX entries all count against it. People build a record that works in testing and breaks when the tenth mechanism resolves. The qualifier on the all mechanism matters most: fail, softfail, neutral and pass each mean something different, and a default of neutral weakens the record without looking weakened.
DKIM depends on a keypair, with the public half published as a DNSKEY at a chosen selector. Selector rotation exists because a signing key cannot safely be replaced without overlap, and because a leaked key should stop being trusted quickly. Signature canonicalization lets a mail system rewrite headers and lines without breaking the signature. Alignment is what people get wrong: relaxed alignment matches the organisational domain, strict alignment matches the exact domain, and DMARC uses strict alignment for the visible From address.
DMARC carries a policy of none, quarantine or reject, plus a percentage for staged rollout. The rua address collects reports, and those reports are the fastest way to find legitimate senders nobody authorised yet. I keep the boundary in view too. Authoritative nameservers, zone transfers and CAA records decide who can speak for a domain at all, and that sits underneath all three mail records.