DNS privacy in 2026: DoH vs DoT, and how DNS leaks expose your browsing

June 15, 2026

Before your browser fetches a single byte of a web page, it asks a question out loud: "what is the IP address of this domain?" By default that question is sent in cleartext to whoever runs your network, which means your ISP, your employer's gateway, or the cafe Wi-Fi can log every site you visit even when the sites themselves use HTTPS. This article explains how DNS encryption actually works in 2026, the real differences between DoH, DoT and DNSCrypt, what a DNS leak is and the specific ways it happens even on a VPN, how to test your own setup, and how to choose resolvers without simply handing your history to a new company.

What plain DNS exposes

The Domain Name System translates example.com into an IP address. Classic DNS runs over UDP port 53 in plaintext. Anyone on the path, your ISP first of all, sees the full domain of every site, app, and embedded resource you contact, in real time, mapped to your IP address. HTTPS encrypts the content of your traffic, but the DNS lookup that precedes it, and historically the server name in the TLS handshake, still announce where you are going. For most people DNS is the single largest, most overlooked browsing-history leak on their connection.

The three ways to encrypt DNS

DNS over HTTPS (DoH)

DoH wraps DNS queries inside ordinary HTTPS requests on port 443. Because the traffic looks identical to normal web traffic, a network operator cannot easily distinguish or selectively block your DNS without blocking the web. This is its main strength: censorship and passive logging resistance. Browsers can run DoH themselves, independent of the operating system, which is both convenient and, as we will see, a source of confusion. Resolvers like Cloudflare (1.1.1.1), Google (8.8.8.8), and Quad9 (9.9.9.9) all offer DoH endpoints.

DNS over TLS (DoT)

DoT puts DNS inside a dedicated TLS tunnel on port 853. It encrypts exactly the same way but on its own recognisable port, which makes it cleaner for network administrators to manage and monitor as DNS, and easier for a hostile network to block precisely because it stands out. DoT is the more common choice at the operating-system and router level, especially on Android, where it appears as "Private DNS."

DNSCrypt

DNSCrypt is an older protocol that authenticates and encrypts DNS between client and resolver using public-key cryptography, with strong protection against tampering and spoofing. It is less mainstream than DoH/DoT today but remains popular through tools like dnscrypt-proxy, often combined with Anonymized DNSCrypt relays that separate who you are from what you ask, similar in spirit to Oblivious DoH.

Encrypted SNI and ECH

Encrypting DNS is only half the story. During a TLS handshake the browser historically sent the destination hostname in cleartext in the Server Name Indication (SNI) field, so a network observer could read the site name even with encrypted DNS. Encrypted Client Hello (ECH), the successor to the earlier ESNI proposal, encrypts that hostname inside the handshake. ECH depends on fetching the server's public key via DNS (an HTTPS resource record), so encrypted DNS and ECH reinforce each other: without DoH/DoT the ECH key lookup itself can leak, and without ECH your DoH gains are partly undone by the SNI. In 2026 ECH is supported by major browsers and Cloudflare-fronted sites, though far from universal.

What a DNS leak actually is

A DNS leak happens when your DNS queries travel outside the protected path you think you set up, usually to your ISP's resolver, revealing your browsing even though you believed it was hidden. The dangerous thing is that everything else can appear to work, your VPN shows connected, pages load normally, yet your lookups are quietly going to the wrong resolver. The common causes are specific and worth knowing.

OS resolver bypassing the VPN

When you connect a VPN, it should route DNS through the tunnel to the VPN's own resolver. If the VPN client fails to override the system's DNS settings, the operating system keeps using the resolver it had before, typically your ISP's, and sends those queries outside the tunnel. This was a classic Windows leak where the OS queries multiple configured resolvers in parallel and uses whichever answers first.

Split tunnelling

Split tunnelling routes some apps or destinations outside the VPN by design. If DNS resolution for the excluded traffic, or DNS in general, is handled outside the tunnel, those lookups leak. Misconfigured split tunnels are a frequent source of partial leaks that are easy to miss because most traffic still looks protected.

IPv6 leaks

Many VPNs tunnel only IPv4. If your network and OS also have IPv6 connectivity, IPv6 DNS queries and traffic can escape the IPv4-only tunnel entirely, leaking both your lookups and your real IPv6 address. Either the VPN must tunnel IPv6 too or IPv6 must be disabled while connected.

Browser DoH versus OS DNS fighting each other

A subtle modern leak: your browser runs its own DoH to a resolver you chose, but a different app, or the OS, still uses the system resolver. You can also have the reverse, where you carefully set OS-level encrypted DNS and then a browser silently overrides it with its own default DoH provider. The two layers do not automatically agree, and the gap is where leaks live.

How to test for leaks

Compare resolver to your expectation. A DNS-leak test page issues lookups to unique subdomains and reports which resolver IPs and organisations actually queried them. If your ISP appears while you are on a VPN, you have a leak.
Test with IPv6 enabled. A test that only checks IPv4 can show "no leak" while IPv6 leaks freely. Confirm the test covers both, or temporarily disable IPv6 and compare.
Check the SNI/ECH status. Encrypted DNS with cleartext SNI still leaks the hostname; verify ECH is negotiated for sites that support it.
Re-test after every config change. Browser updates and VPN reconnects can reset DNS behaviour. Our checks on privacyscore.dev flag whether your DNS appears encrypted and whether the resolver answering for you matches a known private resolver or your access network, so a leak shows up as a concrete downgrade in your score rather than a silent failure.

How to configure resolvers

Browser-level DoH

Every major browser can enable DoH on its own. In Firefox it is under Settings, Privacy and Security, DNS over HTTPS, with a Max Protection mode that refuses to fall back to plaintext. In Chromium it is the "Use secure DNS" option. Browser-level DoH is the quickest win and protects browsing immediately, but it only protects that browser; other apps on the device still use the OS resolver.

OS-level encrypted DNS

Setting encrypted DNS at the operating system covers every application, not just the browser. Android offers Private DNS (DoT) in Settings. Windows 11 and recent macOS support encrypted DNS natively, and on Linux tools like systemd-resolved, dnscrypt-proxy, or a local resolver can enforce DoH/DoT/DNSCrypt system-wide. This is the more thorough choice; the trade-off is that you should then disable the browser's own DoH so the two layers do not conflict.

Router-level DNS

Configuring encrypted DNS on the router protects every device on the network, including those that cannot be configured individually, but the hop from each device to the router is still local plaintext, so it is best combined with per-device encryption for untrusted local networks.

The centralisation trade-off

Encrypting DNS does not delete the watcher, it moves it. With plaintext DNS your ISP sees every lookup. With DoH to a single big provider, that one company now sees every lookup instead, and a handful of resolvers (Cloudflare, Google, Quad9) handle an enormous share of the world's encrypted DNS. You have traded a watcher you did not choose for one you did, which is an improvement only if you trust the new one more and they keep their logging promises.

Mitigations exist. Choose a resolver with a clear no-logging, privacy-focused policy and, ideally, independent audits; Quad9 is operated by a non-profit, for example. Use techniques that split identity from query, Anonymized DNSCrypt relays or Oblivious DoH, so the resolver that sees your queries does not see your IP. Or run your own recursive resolver so no third party aggregates your lookups, at the cost of effort and some performance. The point is to make centralisation a deliberate choice rather than an accidental side effect of clicking "enable secure DNS."

Conclusion

DNS is the quiet narrator of your browsing, and by default it tells your ISP everything. Encrypting it with DoH, DoT, or DNSCrypt, and pairing that with ECH so the TLS handshake stops leaking hostnames, closes the largest plaintext gap most people have. But encryption alone is not safety: leaks from the OS resolver, split tunnelling, IPv6, and browser-versus-OS conflicts can route your queries straight back to your ISP while everything looks fine, so testing, and re-testing after changes, is not optional. And once encrypted, the watcher simply relocates to your chosen resolver, which makes picking a trustworthy, ideally non-profit or audited provider, or splitting identity from query, the final step. Configure it deliberately, verify it on privacyscore.dev or a dedicated leak test, and your browsing history stops being broadcast to the network around you.