DNS Leak Testing: What Your VPN Might Not Protect

You connect to a VPN expecting privacy. The encrypted tunnel hides your traffic from the coffee-shop Wi-Fi, the hotel network, and your ISP. The destinations you visit, the data you exchange — none of it should be visible to anyone watching from outside. Most of the time, that's exactly how it works. But there's a quiet failure mode that costs the VPN about half its value: your DNS queries can still be going to your ISP. They can see every domain you look up, even though the rest of your traffic is encrypted. That's a DNS leak.

It's not a glamorous attack. Nobody's stealing your bank password. But if the threat model that pushed you to a VPN in the first place was "my ISP shouldn't have a log of every website I visit," a DNS leak quietly undoes the whole purpose. And it's surprisingly common — by some industry measurements, around a quarter of consumer VPN setups leak at least some DNS some of the time. This post explains what's actually happening, why, and how to fix it.

What's actually happening when DNS leaks

Every time your browser loads news.example.com, it does a DNS lookup first to translate that name into an IP address. The lookup goes to a recursive resolver — by default, the one your operating system was handed by DHCP when it joined the network. On a home ISP, that's usually your ISP's resolver. On a corporate network, it's the company's DNS. On a coffee-shop Wi-Fi, it's whatever the router was configured to use.

When you turn on a VPN, the expectation is that everything — including the DNS query — flows through the encrypted tunnel and out to the VPN provider's resolver. The VPN sees the DNS query inside the tunnel and forwards it to a resolver of its choosing (typically one the VPN operates), and the rest of the network sees only encrypted bytes going to the VPN endpoint. That's the design.

A DNS leak happens when the OS or browser sends the DNS query outside the tunnel anyway. The IP traffic to news.example.com still goes through the VPN — but the lookup that preceded it went directly to the ISP's resolver in plain UDP, where the ISP can see it. Your browsing history shows up in the ISP's DNS logs even though your packets to the site itself are encrypted. From a privacy standpoint, the VPN is doing the cryptographic work without delivering the metadata protection it promised.

Why DNS leaks happen

There's no single bug. Leaks come from a half-dozen separate misalignments between how the OS resolves names and how the VPN tunnels traffic. The most common:

• The VPN client doesn't override system DNS. The cheapest VPN setup is "just route IP packets through the tunnel." That works for traffic — but the OS is still pointed at the old DNS server. Resolutions go to the ISP; only the IP traffic after the resolution is tunnelled. Better clients update the system DNS settings the moment the tunnel comes up.
• Split-tunnel routing. Many VPNs let you choose which apps go through the VPN and which don't. If DNS happens to fall on the "not tunnelled" side of the split, you leak. This is the failure mode for "selective VPN" features that pretend to be privacy-protective but aren't, by default, configured correctly.
• IPv6 isn't tunnelled. A VPN that only carries IPv4 will happily let IPv6 traffic — including IPv6 DNS queries — bypass the tunnel entirely. Plenty of consumer VPNs still don't support IPv6, and on a dual-stack network the resulting v6 queries are an obvious leak path.
• Cached lookups from before the VPN connected. The OS may have a fresh cache entry for news.example.com from before the VPN came up. The browser uses the cached entry; no new lookup happens; everything looks fine. But if the lookup that populated the cache was logged by the ISP, the damage was already done — and after the cache expires, every fresh lookup may or may not leak depending on what else is going on.
• Browser DoH / DoT settings. Modern Firefox, Chrome, and Edge support DNS-over-HTTPS — they bypass the OS resolver entirely and send queries direct to Cloudflare, NextDNS, or whatever you configured. This isn't really a leak (it's a deliberate alternative path), but it can confuse a leak test by making the result look unrelated to the VPN.
• Windows Smart Multi-Homed Name Resolution. Windows sends parallel DNS queries on all available interfaces and takes whichever response comes back fastest. With a VPN, the ISP's resolver almost always responds faster than the VPN's, and Windows uses that response — leaking the query in the process. Microsoft considers this a feature; it requires a registry edit or third-party tool to disable.
• WebRTC / browser pre-fetching. Browsers pre-resolve hostnames they expect to need shortly. Some of those pre-fetches happen via mechanisms that don't honour the VPN's DNS settings the same way ordinary navigation does.

How DNS leak tests actually work

The classical DNS-leak test is more elegant than it sounds. You serve random subdomains of a domain whose authoritative nameserver you control — say, random123abc.test.example.net. You ask the user's browser to resolve a fresh random name. Whichever recursive resolver actually queries your auth NS for that exact label is, by definition, the resolver the browser is using right now. You log the source IP of the incoming auth-NS query, look up its ASN, and compare against the IP the user came from. If they differ in a meaningful way (residential ISP vs VPN provider's ASN), you've found a leak.

That technique requires running an authoritative nameserver with wildcard logging — operationally heavier than most testing tools want to take on. The lighter approach, which is what the DNS leak tool currently uses, is to combine two signals: a server-side baseline (your client IP and ASN as Cloudflare's edge sees you, plus a known-VPN ASN check), and a server-side DoH probe (a "whoami" query to a public DoH provider, which reveals the recursive resolver the server-side worker is using). The two pieces together let the tool say things like "your client posture looks residential, no VPN in play, so there's no tunnel to leak around" or "your client posture looks VPN-shaped, and here's the resolver path."

The honest caveat about the server-side approach is that it observes the worker's resolver, not your laptop's system resolver. The full wildcard-DNS version is a future v2; the current tool gets you 80% of the value (VPN detection is rock-solid) without the operational overhead.

Reading the verdict

Four outcomes cover almost every result you'll see:

• No VPN + ISP-looking resolver. Normal residential connection. No tunnel exists, so there's nothing for DNS to leak around. The verdict is "no VPN, no leak possible."
• VPN + VPN-network resolver. Your client IP is in a known VPN / cloud ASN, and the resolver path lines up with that network. This is the success case — DNS is going through the tunnel.
• VPN + ISP-network resolver. Your client IP looks VPN-shaped but the resolver belongs to a residential ISP ASN. This is a leak — your ISP can see the queries even though the rest of your traffic is encrypted.
• No VPN + public-resolver (Cloudflare, Google, Quad9). Privacy-conscious DoH setup. You don't have a tunnel, but you've chosen to send DNS to a public resolver rather than the ISP's. No leak by any reasonable definition.

Run the test with the VPN off first to establish your baseline. Then turn the VPN on and re-run. The two readings tell you whether the VPN is actually changing your resolver path or just your IP.

Five steps to fix a DNS leak

If the test shows a leak, here's the order to work through:

• 1. Enable "DNS leak protection" in your VPN client. Most reputable VPNs ship this as a setting — sometimes called "Force VPN DNS" or "Block IPs and DNS outside tunnel." It pushes the VPN's resolver into the OS network config and blocks queries that try to go elsewhere. If your VPN doesn't have this setting, that's its own answer about how seriously the VPN takes the threat model.
• 2. Set the VPN's DNS explicitly. In the VPN's connection profile or the OS network settings, hard-code the resolver address the VPN documents — typically something like 10.0.0.1 for ProtonVPN, 10.255.255.1 for Mullvad, or the provider's own DNS IP. Don't rely on the client to figure it out.
• 3. Disable IPv6, or use a VPN that tunnels it. If the VPN doesn't carry IPv6, every IPv6-capable destination will route directly. Either disable IPv6 system-wide while the VPN is up, or switch to a VPN that supports v6 (WireGuard-based providers usually do; OpenVPN setups vary).
• 4. Flush the DNS cache after connecting. On Windows: ipconfig /flushdns. On macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. On Linux with systemd-resolved: sudo resolvectl flush-caches. Stale cached entries from before the VPN came up can produce confusing results until they expire naturally.
• 5. Belt-and-braces with browser DoH. As a fallback, set Firefox, Chrome, or Edge to use DNS-over-HTTPS via Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9, or NextDNS. The browser bypasses the OS resolver entirely, so even if the OS leaks, browser traffic doesn't. It doesn't fix the underlying VPN problem — non-browser apps still leak — but it limits the blast radius.

DNS leak vs WebRTC leak vs IP leak

"VPN leak" is an umbrella term for three different failures with different consequences:

• DNS leak — your ISP sees the domains you look up. Doesn't expose the page contents (those are still tunnelled), but exposes the metadata. Covered by this article; tested with the DNS leak tool.
• WebRTC leak — websites you visit see your real local or public IP because the browser's WebRTC ICE candidate gathering doesn't honour the VPN. Covered in detail in our WebRTC leak post; tested with the WebRTC test.
• IP leak — the catastrophic failure: your real public IP becomes visible to remote services because the VPN tunnel dropped or never came up. The simplest check is just to look up your current IP and confirm it matches the VPN's exit node and not your real address.

You can have any combination of the three. A VPN that hides your IP from websites (no IP leak) but lets DNS go to the ISP (DNS leak) is a common configuration. A VPN that gets both of those right but doesn't disable WebRTC is another. The three tools together — IP lookup, DNS leak test, WebRTC test — cover the full picture in about thirty seconds. See our piece on how VPN detection works for what websites actually see when you're connected, and vpn-check for the ASN-level classification side of things.