What Is a DNS Leak

Why DNS is leakable

DNS resolution happens before the TCP connection to a website is established. The browser asks "what's the IP of example.com?" — gets an answer — then opens a TCP connection to that IP. The DNS query itself is a separate UDP or TCP packet sent to whichever resolver the OS thinks it should use. If the OS picks the wrong resolver (your ISP's instead of the VPN's), the query goes to the ISP even though the subsequent connection to example.com goes through the VPN.

The result: the ISP sees the domain name (from the DNS query) but not the page content (which is encrypted and tunneled). For tracking purposes the domain alone is often enough.

The five common leak mechanisms

Many "DNS leak" reports are actually browser DoH — the browser uses its built-in resolver (Cloudflare or NextDNS), which is encrypted but not the VPN's resolver. Technically the ISP can't see the queries, but the test site reports a non-VPN resolver, which looks like a leak.

How DNS leak test sites detect leaks

Leak-test sites use a clever trick. The site generates a unique random subdomain — say, a8f3d2.dnsleaktest.example — and embeds it in a page. When your browser tries to load a resource at that subdomain, the OS makes a DNS query for it. The DNS query travels up the resolver chain: stub resolver → recursive resolver → authoritative nameserver. The authoritative nameserver is run by the test site, so it can see exactly which recursive resolver made the final upstream query. Repeat with many unique subdomains and you have a list of every resolver involved in resolving DNS for your device.

If any of those resolvers belongs to your ISP while you're connected to a VPN, that's a leak. If they all belong to the VPN or your configured encrypted-DNS provider, you're clean.

IPv6: the silent leaker

Many older VPN configurations tunnel IPv4 only. If your ISP provides IPv6, the OS happily routes IPv6-destined traffic — including IPv6 DNS queries to the ISP's IPv6 resolver — outside the tunnel. The user thinks the VPN is fully active; in reality, half the traffic stack is bypassing it.

Fixes, in order of preference:

1. Use a VPN with native IPv6 tunneling.
2. Disable IPv6 system-wide while the VPN is active.
3. Configure a kill-switch firewall rule that blocks all IPv6 traffic when the VPN is on.

Mobile devices and per-app DNS

Mobile operating systems have nuanced DNS behavior. iOS may use different DNS for different apps (private relay, configured DNS profiles, app-controlled DNS). Android similarly. A VPN app may control system-wide DNS, or it may be limited to per-app tunneling. Verify by testing while on mobile with a VPN active — don't assume mobile inherits desktop behavior.

DNS leak vs ISP visibility in general

Even with no DNS leak, your ISP can still see some information about your destinations:

• IP addresses — the actual TCP connections go to specific IPs. Your ISP sees those. Reverse-DNS lookups on the IPs often reveal the destination service.
• SNI in TLS — the TLS handshake currently includes the destination hostname in plaintext as Server Name Indication. Encrypted SNI / ECH closes this; see ECH explained.
• Timing and volume — even encrypted, the pattern and size of traffic can reveal the service. Streaming Netflix looks different from web browsing.

DNS leak prevention closes the most common information channel but not all of them. For more, see what data your ISP collects.

Verifying a fix actually fixed it

After applying any DNS leak fix:

1. Disconnect and reconnect your VPN to apply the new configuration cleanly.
2. Re-run a DNS leak test. Confirm no ISP resolvers appear.
3. Repeat the test over IPv6 explicitly (some test sites have a separate IPv6 path).
4. Repeat after a reboot — some leaks only appear on cold boot before the VPN client has fully taken over DNS.
5. Test in private/incognito mode in case a browser extension is the source.

Why this matters in practice

DNS reveals every domain you visit. With a DNS leak, the entire privacy benefit of the VPN is conditional — the ISP can build a behavioral profile from domain names alone (which streaming services, which news sites, which apps phone home). The connection contents are still encrypted, but the menu of where you went is fully visible. That's why DNS leak testing is the first step every VPN tutorial recommends after installation.

Frequently Asked Questions

What is a DNS leak?

A DNS leak occurs when DNS queries from your device go to a resolver outside the protection you intended — typically your ISP's resolver instead of the VPN's or your configured encrypted-DNS resolver. The result is that your ISP (or whoever operates the leaking resolver) sees the domain names you visit even though the rest of your traffic is encrypted or tunneled.

What causes a DNS leak?

Several causes: operating system DNS settings that bypass the VPN's tunneled DNS, IPv6 traffic going outside an IPv4-only VPN, browser-level DNS-over-HTTPS overriding the system resolver, multi-homed devices sending DNS to whichever interface has the lower metric, and split-tunnel VPN configurations that route DNS outside the tunnel by design. The fix depends on which cause applies.

How do I test for a DNS leak?

Visit a DNS leak test site while connected to your VPN or encrypted-DNS setup. The site queries a unique subdomain it controls, observes which resolver looked up that name, and reports the resolver's IP. If you see your ISP's resolver instead of the VPN's or your configured resolver, you have a leak. Repeat the test after any network change.

What is the difference between a DNS leak and a WebRTC leak?

A DNS leak exposes the domain names you visit by routing DNS queries to an unintended resolver. A WebRTC leak exposes your true IP address by using the browser's WebRTC API to discover local network interfaces, including the non-VPN one. They are independent failure modes — you can have one without the other, and they require different fixes.

Does encrypted DNS (DoH or DoT) prevent DNS leaks?

It prevents your ISP from seeing query content if the encrypted-DNS resolver is reached. But if the DNS configuration leaks queries to the ISP's plain-DNS resolver instead of the encrypted one, the encryption doesn't apply. Encrypted DNS is a content protection, not a routing protection — both must be configured correctly.