01
DNS QUERY
Send unique DNS query
DNS Leak Test
Check if your DNS requests are leaking outside your VPN or proxy tunnel
HOW IT WORKS
DNS leak detection process
02
RESOLVER DETECTION
Detect processing DNS server
03
GEOLOCATION
Check resolver country vs VPN
04
LEAK ANALYSIS
Determine VPN tunnel leaks
Eight Ways DNS Escapes Your VPN. Most Leak Tests Catch Two.
A DNS leak isn't "your queries went to your ISP." It's a routing misfire. Browser asked for example.com, the request hit a resolver outside the tunnel, and somebody you didn't invite now knows you typed that URL. ISP. Public DNS operator. The coffee shop's captive portal. Sometimes all three inside the same minute, three separate witnesses watching the same envelope change hands. The stubborn part: there are at least eight ways DNS escapes a tunnel, and the average leak test covers maybe two. Green checkmark, close the tab, twenty minutes later your phone hops onto a wifi that pushes a fresh resolver via DHCP. That green stopped being true before you finished your latte. Tutorials skip this because it doesn't fit in a screenshot. Below: where leaks actually originate, why popular "DNS leak test" sites hand you a grade they can't back up, and what the real fix looks like when you stop trusting the one-click toggle in your VPN app.
The Eight Vectors
Most write-ups frame it as "ISP intercepts DNS." That's vector one out of eight. The neighborhood everybody already knows about. Vector two is Windows. Specifically Windows 10's Smart Multi-Homed Name Resolution, which fires the same DNS query at every network interface in parallel and picks whichever answer lands first. Your VPN tunnel is one interface. Your physical NIC is another. Race condition, plain and simple. The race typically goes to the closest resolver, which is your ISP. Microsoft documented this behavior. They considered it a feature. Let that sink in. IPv6 opens vector three. Most consumer VPNs tunnel IPv4 only. OS happily ships v6 DNS queries over native IPv6, which means ISP, home router, and whatever country-level firewall sits on the v6 path can all watch the query sail past. Invisible to the VPN client because the traffic never entered the tunnel in the first place. Browsers own vector four. Chrome and Firefox both ship built-in DoH. Firefox flipped the default to Cloudflare back in 2018 for US users and the switch still catches people off guard six years later. That query never touches your tunnel's resolver. Straight to Cloudflare on port 443, camouflaged as normal HTTPS. Transparent to every VPN on the market. The remaining four, quick: DHCP override on captive networks that silently swap your resolver. Kill switch race conditions where the tunnel reconnects and DNS squirts out the gap. mDNS broadcasts (.local hostnames) announcing your machine's name to everyone on the LAN like a new kid shouting their own name on the first day of school. And device discovery (Chromecast, AirPlay, printer SSDP probes) that ignores VPN routing entirely because the protocol spec says so. Most leak tests probe vector one. Some hit IPv6. The rest? Invisible.
Why the Green Checkmark Lies
Run any popular DNS leak tool. Here's what it does: fires one or two queries to a unique subdomain, checks which resolver answered, compares the country to your VPN exit. Match? Green. Mismatch? Red. Done. Three problems with that. First: one query is one sample. DNS leaks are often intermittent. On dual-stack networks the OS picks v4 or v6 per-query, sometimes load-balancing between them at random. One sample catches v4 going through the tunnel. Next forty queries split half-and-half. Test missed it. Casting a single fishing line into a lake at noon tells you nothing about what bites at dusk. Second is geography. Anycast routing parks Cloudflare's 1.1.1.1 in 300-plus datacenters worldwide. A query from a London VPN exit can land in Frankfurt's POP because BGP decided so. Test sees "DNS resolver: Germany, VPN exit: UK" and screams leak. Except nothing leaked. Turns out this false positive fires constantly with Cloudflare DoH and nobody's bothered to fix the test logic. Third is framing, and this one's sneaky. "1.1.1.1 protects your privacy" is wrong in a specific way. Cloudflare doesn't sell your queries. They do see them. Google with 8.8.8.8, same deal. Quad9, same deal. If your threat model is "ISP shouldn't know what I browse," switching to Cloudflare fixes that. If your threat model is "no third party should know," you need your own resolver. About 0.1% of VPN users actually run one. Tests that grade on "is my resolver Cloudflare or my ISP" are grading the wrong exam. The right question: what's the full topology of my queries across every interface, including the ones I forgot exist? Harder to answer. Harder to display. But the only question that matters.
What Actually Seals the Tunnel
The fix isn't a checkbox in your VPN client. It's a routing table. Your OS maintains one. Without specific instructions it sometimes obeys the VPN and sometimes freelances. Getting to "always obeys" requires three layers stacked. First layer: forced routing of all traffic through the tun interface, v4 and v6 both. WireGuard configs with AllowedIPs = 0.0.0.0/0, ::/0 handle this. OpenVPN configs with redirect-gateway def1 ipv6 do the same. Anything that doesn't explicitly enumerate v6 leaves a gap the width of a loading dock. Second layer: a firewall rule that blocks all traffic on non-VPN interfaces when the tunnel is up. Linux: nftables drop on the output chain. Windows: WireGuard's kill switch is actually a netsh rule under the hood. macOS: pf rules, but Apple removed pfctl from the GUI years ago so it's a manual config adventure. Straight up, without this layer the kill switch is a polite suggestion, not a wall. Third: the browser. Chrome, chrome://flags/#dns-over-https, set Disabled. Firefox, about:preferences, Network Settings, uncheck "Enable DNS over HTTPS." Skip this and Firefox keeps its private backchannel to Cloudflare regardless of what the OS does. Like boarding up the front door while leaving the kitchen window open. For the genuinely paranoid: run your own resolver. Pi-hole with Unbound, configured for DoT upstream to Quad9, all queries forced through the VPN by routing rules. About four hours to set up properly. Zero leaks afterward. Side benefit: nothing on your network resolves a single domain without going through your validated stack. The WHOX test queries multiple endpoints across both IP families and surfaces which specific vector failed, not just whether something failed. Useful when the generic test says green and you still don't trust it.
FREQUENTLY ASKED QUESTIONS
How do I fix a DNS leak?
Most VPN apps have a 'DNS leak protection' option - enable it. You can also manually configure your system to use your VPN's DNS servers or a secure DNS service like 1.1.1.1 or 8.8.8.8.
What is DoH leak?
DoH (DNS over HTTPS) leak happens when your browser sends DNS queries directly to a DoH server (like Cloudflare or Google) bypassing your VPN. Some browsers enable DoH by default.
Is DNS leak dangerous?
A DNS leak reveals your browsing history to your ISP and potentially to anyone monitoring your network. While it doesn't expose the content you view, it shows which websites you visit.
All our tests
Run the full WHOX toolkit from one place: leak checks, fingerprint probes, network diagnostics, reputation lookups, and privacy failure tests.