💧 DNS Leak Test

🔍 What Is a DNS Leak Test?

A DNS leak test checks whether the domain-name lookups your device performs are actually staying inside your VPN's encrypted tunnel, or whether they're slipping out through your regular network path where your ISP — or anyone else positioned on that path — can see exactly which sites you're visiting. Because DNS traffic and general web traffic use separate resolution mechanisms at the operating-system level, it's entirely possible for your browsing to appear fully tunneled while your DNS queries take a completely different, unprotected route. A leak test exists specifically to catch that mismatch before it becomes a real privacy problem.

❓ Why DNS Leaks Happen

Most operating systems resolve domain names using whatever DNS servers are configured at the network-interface level, and that configuration doesn't automatically change just because a VPN application reports itself as "connected." A VPN needs to explicitly capture the DNS resolution path — either by pushing its own DNS servers to the interface, adding firewall rules that block queries to any other resolver, or both. When a VPN client skips this step, or does it incompletely, the operating system keeps sending lookups to whichever resolver it was using before the VPN ever started, commonly your ISP's default DNS servers. The encrypted tunnel still protects the content of your traffic, but the DNS layer quietly reveals the destination.

📜 How DNS Resolution Actually Works

Every time your device needs to reach a domain, it first checks a local cache, then asks a configured recursive resolver. That resolver, if it doesn't already have the answer cached, walks the DNS hierarchy — starting at a root server, moving to the relevant top-level domain server, and finally to the domain's own authoritative nameserver — before returning an answer that eventually gets cached at multiple points along the chain. This entire process happens before a single byte of your actual web traffic is sent, which is exactly why DNS is such a high-value target for both surveillance and leak analysis: it reveals intent and destination even to an observer who can't see the encrypted payload that follows.

⚙️ How This Tool Checks for Leaks

This page runs three independent, browser-native checks. First, it fetches your public IP address over plain HTTPS — a value that should reflect your VPN provider's exit node if a VPN is active. Second, it queries several major DNS-over-HTTPS resolvers (Google, Cloudflare, and Quad9) directly from your browser and reports whether each is reachable and returning consistent, current results, which helps surface misconfigured or overridden DoH settings. Third, it uses the WebRTC API to check whether your browser is exposing local or public IP candidates that bypass your VPN tunnel entirely — a separate but closely related leak vector that catches out even security-conscious users. None of these three checks can identify the exact resolver IP your operating system used for a specific query the way a dedicated backend-logged test can, and the tool is upfront about that limitation rather than pretending otherwise.

🌐 ISP DNS vs VPN DNS vs Encrypted DNS

Your ISP's default DNS servers are the resolvers assigned automatically by DHCP when you join their network — convenient, but visible to the ISP and, in many jurisdictions, subject to logging or even monetization through query-based analytics. VPN DNS refers to resolvers operated by (or explicitly routed through) your VPN provider, which keeps lookups inside the tunnel and out of your ISP's view, shifting trust to the VPN operator instead. Encrypted DNS — DNS-over-HTTPS or DNS-over-TLS — adds a further layer by wrapping the query itself in TLS, preventing on-path eavesdroppers from reading it in transit, though it doesn't by itself guarantee the query goes through your VPN tunnel rather than around it.

🔒 DNS-over-HTTPS, DNS-over-TLS & DNSSEC

DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) both encrypt the DNS query in transit, closing off casual network eavesdropping, but they solve a different problem than a VPN does — they protect confidentiality of the query, not necessarily its routing. A browser configured to use its own hardcoded DoH resolver can actually create a leak of a different kind: bypassing your VPN's intended DNS servers entirely and querying its preferred provider directly, regardless of tunnel state. DNSSEC, meanwhile, is unrelated to leaks in the privacy sense — it authenticates that a DNS answer hasn't been tampered with, but does nothing to hide who's asking the question. Check DNSSEC deployment separately with our DNSSEC Checker.

🖥️ Operating System & Browser Behavior

Windows, macOS, Linux, Android, and iOS all handle DNS interface binding differently, which is a large part of why leak behavior is so inconsistent across devices even with the same VPN app installed. Windows in particular has a long history of "smart multi-homed name resolution" sending DNS queries out over every active network interface simultaneously and using whichever answers first — a behavior that can leak queries even when a VPN is fully connected, unless specifically disabled. Browsers add another layer: Chrome, Firefox, and Edge all now ship a "Secure DNS" or DoH setting that can override system-level DNS configuration independently of what the operating system or VPN client intends.

🔵 IPv4, IPv6 & Dual-Stack Leaks

One of the most common and hardest-to-notice leak types happens on dual-stack networks: a VPN correctly tunnels IPv4 DNS traffic while leaving IPv6 completely unmanaged, because the VPN was configured, tested, or built with IPv4 assumptions baked in. If your network path has native IPv6 connectivity, your operating system may prefer it for DNS resolution by default, sending queries out over an interface the VPN never touched. The safest general practice — and the one most reputable VPN providers now follow — is to either fully tunnel IPv6 DNS alongside IPv4, or disable IPv6 at the system level entirely while connected, rather than leaving it to chance. Our IPv6 Lookup and IPv6 Calculator tools are useful for auditing IPv6 exposure separately.

🛡️ Split Tunneling & VPN Kill Switches

Split tunneling — routing only some traffic through the VPN while the rest uses your regular connection — is a deliberate and often useful feature, but it multiplies the ways DNS can leak if app-level and DNS-level routing rules don't stay in sync. A kill switch, by contrast, is a safety mechanism that blocks all network traffic the moment the VPN tunnel drops, and a genuinely well-implemented one blocks DNS traffic too, not just general internet access; a kill switch that lets DNS queries through during a dropped connection provides a false sense of security precisely at the moment protection matters most.

🌐 Public Resolvers, Private Resolvers & the Resolver Chain

Public recursive resolvers like 1.1.1.1, 8.8.8.8, and 9.9.9.9 are widely used because they're fast and independently operated from most ISPs, but manually pointing your system at one doesn't itself prevent a leak — if it's configured outside the VPN's tunnel, the query still travels in the clear to whichever network path your OS chooses. Private or self-hosted resolvers, meanwhile, put you in control of logging policy but add operational responsibility. In every case, what actually matters for leak prevention is which network path the query physically travels, not merely which resolver ultimately answers it — a detail easy to overlook when comparing resolver providers.

📋 Testing Methodology & Command-Line Verification

For a definitive, resolver-identity-level leak test beyond what any static browser page can offer, use your operating system's own DNS query tools alongside your VPN's dedicated leak-test page (most reputable providers run one). On macOS or Linux, running dig +short whoami.akamai.net @ns1-1.akamaitech.net or similar "who is asking" style lookups against services designed for this purpose returns the IP address your query chain used. On Windows, nslookup paired with ipconfig /displaydns can reveal the resolver cache your system is actually populating. Run these both with your VPN off and on, and compare — a genuine leak shows your real ISP-assigned resolver appearing even while the VPN reports an active connection.

👤 Who Actually Needs This, and Why

🏢 Enterprise & Real-World Scenarios

Remote-first companies frequently discover DNS leaks only after a security audit, because the symptom — DNS queries visible outside the corporate VPN — produces no visible error for the end user, unlike a dropped connection. MSPs managing VPN fleets across client organizations benefit from standardizing on VPN clients with mandatory, non-optional DNS leak protection rather than relying on end users to enable it manually. Cloud engineers testing infrastructure from behind a VPN sometimes intentionally split-tunnel DNS for internal-only domains while tunneling everything else — a legitimate pattern, but one that needs explicit documentation so it isn't mistaken for an unintentional leak during a later audit.

📊 Comparison Tables

❓ Myths vs Facts

🔒 Security & Privacy Implications

A DNS leak effectively hands an observer — your ISP, a network operator, or anyone monitoring that path — a readable list of every domain you visit, even while the actual page content stays encrypted. For most everyday users this is a privacy concern rather than an active security compromise, but for people relying on a VPN specifically to evade targeted surveillance, censorship, or geographic restrictions, a DNS leak can meaningfully undermine the entire reason they're using a VPN in the first place. Leaks are also frequently invisible without active testing, which is exactly what makes routine leak checks worthwhile rather than a one-time setup step.

⚠️ Common Mistakes

• Assuming VPN connection status alone confirms DNS protection
• Never re-testing after an operating system or VPN client update
• Leaving browser-level Secure DNS/DoH enabled with a provider different from the VPN's
• Ignoring IPv6 entirely when auditing a dual-stack network
• Trusting a kill switch that blocks general traffic but not DNS specifically
• Testing only once, right after setup, and never again

✅ Deployment & Prevention Checklist

⚖️ Advantages & Limitations

🛠 Troubleshooting Matrix

🎓 Expert Tips

🔗 More Ways to Investigate Your Network

Check your resolver's raw records directly with DNS Lookup, confirm your visible IP address with My IP Address, and verify DNSSEC deployment separately with DNSSEC Checker. For IPv6-specific auditing, use IPv6 Lookup and IPv6 Calculator.