What is a DNS leak — and how to actually test for one

The short version: a VPN tunnel encrypts the IP packets your device sends to other servers. DNS is the lookup that happens before the packet is sent — your device asking "what IP address belongs to example.com?" If that lookup goes to your ISP's resolver instead of through the VPN, then your ISP sees the domain even though it never sees the encrypted traffic that follows. That's a leak. It defeats the main privacy promise of a VPN for the simplest possible reason: the wrong DNS resolver got asked. The good news is leaks are easy to detect, usually easy to fix, and most properly-built VPN apps prevent them by default. The bad news is that "most" isn't "all," and a handful of common configurations cause leaks even on otherwise-correct VPN setups.

What DNS actually does and why it leaks

DNS — the Domain Name System — is the address book of the internet. Every time your device connects to a website, it first has to translate the human-readable hostname (example.com) into a numeric IP address (something like 93.184.216.34) that routers can actually forward packets to. That translation step is a DNS query, and it's a separate network operation from the actual web request that comes after it.

On a typical home connection, your DNS resolver is assigned by your ISP via DHCP — the same mechanism that hands out your IP address. When you connect to Wi-Fi, the router tells your device "your DNS server is 192.168.1.1, which forwards to your ISP's recursive resolver." Every domain you look up flows through that resolver. The ISP can log it, sell it to a data broker (in the United States, this is legal), or hand it to law enforcement.

When you connect a VPN, two things should happen. First, your network traffic gets encrypted and routed through the VPN tunnel. Second, your DNS resolver should change — from the ISP's resolver to one operated by the VPN provider (or a third-party privacy-focused resolver), reachable only through the encrypted tunnel. If only the first half happens, you have a DNS leak. The traffic is encrypted but the lookups that preceded the traffic still flow to the ISP, telling them every site you're about to visit.

From a privacy standpoint, the DNS query is almost as revealing as the traffic itself. The query reveals the exact domain (down to subdomain — mail.example.com is distinguishable from www.example.com) and the timing. Combined with the encrypted traffic volume immediately afterward, a DNS-leaking VPN gives an observer enough metadata to reconstruct your browsing session in almost every meaningful way.

The four ways a DNS leak happens

DNS leaks aren't a single bug. They're a family of related misconfigurations, each with a different root cause and a different fix. In rough order of frequency:

1. OS bypass — Windows split DNS / Smart Multi-Homed Name Resolution

Windows has a feature called Smart Multi-Homed Name Resolution that, when enabled, sends DNS queries in parallel to every available DNS resolver — including the ISP's resolver on the physical interface, even when a VPN is active. Whichever resolver answers fastest wins, and the others are ignored, but the queries themselves have already been sent. On most Windows machines this is on by default. The fix is to disable the feature via Group Policy or by configuring the VPN client to do so on connection. Linux has a similar issue with systemd-resolved if not configured correctly; macOS and iOS handle this better but not perfectly.

2. Split tunnel misconfiguration

Split tunneling lets you route some apps through the VPN and others through your normal connection. A common configuration mistake is to set up app-based split tunneling without also configuring per-app DNS — meaning that an app routed outside the VPN tunnel still tries to use the VPN's DNS resolver, or vice versa, and ends up leaking through whichever path the OS provides. A worse variation: the split tunnel correctly routes the app's TCP traffic outside the tunnel, but the OS-wide DNS resolver is still the ISP's resolver, so every app — tunneled or not — leaks its DNS queries to the ISP. We cover the broader topic in our writeup on what split tunneling actually does.

3. IPv6 fallback

Many VPN clients were designed when IPv4 was the only routing concern. They install IPv4 firewall and routing rules that correctly route DNS through the tunnel, but they don't install matching IPv6 rules. If your network has IPv6 connectivity, the OS will sometimes prefer IPv6 for DNS queries — and those queries flow out the bare interface, bypassing the VPN entirely. This is one of the most common leak modes in 2026 and it's especially common on residential broadband connections that have dual-stack IPv4/IPv6 from the ISP. The fix is either disabling IPv6 globally (heavy-handed but reliable), or using a VPN client that explicitly handles IPv6 routes.

4. WebRTC and browser-resolved DNS

Modern browsers — Chrome, Edge, Firefox, Safari — can perform DNS lookups themselves rather than using the OS resolver. The most notorious case is WebRTC, the peer-to-peer protocol used by video chat. WebRTC uses STUN servers to discover your real local and public IP addresses, and historically it would broadcast both even when a VPN was active. The "real" IP from WebRTC has been a long-standing browser-side leak that requires explicit mitigation. Separately, browsers using DNS-over-HTTPS (DoH) can route DNS queries directly to Cloudflare, Google, or NextDNS regardless of the OS resolver setting — which sometimes helps (DoH-to-public-resolver is more private than plaintext-to-ISP) and sometimes hurts (the public resolver still sees your queries, and the browser is bypassing the VPN's DNS rules).

How to test for a DNS leak in under a minute

Testing for a DNS leak takes longer to describe than to do. Connect your VPN, then visit any of these three tools. They each reveal slightly different aspects of the leak surface.

dnsleaktest.com

The classic. Visit dnsleaktest.com, click "Extended test," and wait about 20 seconds. The tool issues a series of DNS queries for unique hostnames it controls, then shows you which resolvers actually performed those lookups. If you see your ISP's name (Comcast, Verizon, BT, etc.) in the resolver list, you're leaking. If you see only the VPN provider's resolver (or a privacy-focused public resolver like Quad9 or Cloudflare's 1.1.1.1), the OS DNS path is correct.

browserleaks.com/dns

More detailed than dnsleaktest. It shows you not just which resolvers handled the query, but also their geographic location, ASN (the network operator), and whether they support DNS-over-HTTPS or DNS-over-TLS. Useful for catching subtle leaks where the right type of resolver is being used but it's in the wrong country, or for confirming that an encrypted DNS protocol is actually in use.

ipleak.net

The most comprehensive — it tests DNS leaks, WebRTC leaks, IPv4 and IPv6 visibility, and shows what your geolocation appears to be. The WebRTC section is critical: if you see a "local IP" address in the 192.168.x.x or 10.x.x.x range exposed alongside a "public IP" that matches your VPN endpoint, your VPN is doing its job but your browser is leaking via WebRTC. The IPv6 section catches IPv6 fallback leaks that dnsleaktest sometimes misses.

What a clean result looks like vs a leaky one

On dnsleaktest.com's extended test with a properly configured VPN, you should see something like this:

Test results (clean):
  Server: 1.2.3.4    Hostname: dns.vpn-provider.com    ISP: VPNProviderCo    Country: Netherlands
  Server: 1.2.3.5    Hostname: dns.vpn-provider.com    ISP: VPNProviderCo    Country: Netherlands

Conclusion: No DNS leak detected. All queries went to the VPN's resolver.

And here's what a leak looks like:

Test results (leaking):
  Server: 1.2.3.4    Hostname: dns.vpn-provider.com    ISP: VPNProviderCo    Country: Netherlands
  Server: 75.75.75.75    Hostname: cdns01.comcast.net    ISP: Comcast        Country: United States
  Server: 75.75.76.76    Hostname: cdns02.comcast.net    ISP: Comcast        Country: United States

Conclusion: DNS leak detected. ISP resolver (Comcast) received queries.

The key signal is the ISP column. If anything other than your VPN provider (or a deliberately chosen public resolver) appears, your DNS is leaking. If the country column shows your real country alongside the VPN exit country, you're leaking. If only the VPN's endpoint country appears, you're clean.

Leak types compared

Each of the four leak types has a distinct fingerprint in the test results, a distinct set of observers who can exploit it, and a distinct fix:

Fixing the four common causes

Fixing OS-bypass leaks (Windows)

On Windows 10 and 11, disable Smart Multi-Homed Name Resolution either through Group Policy (Computer Configuration → Administrative Templates → Network → DNS Client → "Turn off smart multi-homed name resolution" → Enabled) or via PowerShell: Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name "DisableParallelAandAAAA" -Value 1. Reboot. Some well-maintained VPN clients do this automatically on connection — if yours doesn't, do it manually.

Fixing split-tunnel leaks

Audit your split-tunnel ruleset. For any app that should be protected, verify that both its TCP traffic and its DNS queries are routed through the tunnel. Some VPN clients let you configure per-app DNS; most don't. If yours doesn't, the safer default is to disable split tunneling entirely and use a full tunnel — which routes everything (including all DNS) through the VPN. For most users, the convenience benefit of split tunneling isn't worth the leak risk.

Fixing IPv6 leaks

The most reliable fix is to use a VPN client that supports IPv6 inside the tunnel (or at minimum installs matching IPv6 firewall rules that block IPv6 traffic when the tunnel is up). If you can't switch clients, disable IPv6 on the physical network interface: on Windows, in the adapter properties; on macOS, in System Settings → Network → Advanced → TCP/IP. This is heavy-handed (you lose IPv6 connectivity entirely) but it eliminates the leak vector.

Fixing WebRTC leaks

In Firefox, set media.peerconnection.enabled to false in about:config. In Chrome and Edge, install an extension like WebRTC Network Limiter or uBlock Origin's WebRTC-blocking option. Safari handles WebRTC more conservatively by default but you can still leak local IPs in some configurations; Safari 17+ improved this significantly. Test after the change with ipleak.net.

Why "use a VPN" alone doesn't guarantee no leaks

There's a common assumption that connecting to a VPN automatically prevents DNS leaks. It doesn't — the prevention depends on the VPN client doing a series of things correctly: changing the system DNS resolver, installing firewall rules to block direct-to-ISP DNS, handling IPv6, disabling Windows SMHNR (or equivalent OS-level bypass features), and surviving network changes (Wi-Fi roams, sleep/wake cycles) without re-introducing the leak.

A well-built VPN client does all of this automatically and you never have to think about it. A poorly-built one — or a "free" VPN that uses the OS's built-in VPN profile without any extra leak protection — does some subset, leaving leak vectors open. The only way to know which category you're in is to actually run a leak test after connecting. If the test comes back clean, you can stop worrying about it; if it shows leaks, you have specific problems to fix and you now know which ones.

DNS leak prevention on iOS, Android, Mac, and Windows

iOS

iOS handles DNS through the NetworkExtension framework. A properly-built VPN app uses the NEDNSSettings object to specify a custom resolver that's used while the tunnel is active. iOS enforces this at the OS level — apps cannot bypass the configured DNS without explicit permission. The main leak vector on iOS is iCloud Private Relay, which (when enabled alongside a VPN) can route DNS through Apple's resolver instead of the VPN's. If you're using a VPN for privacy, disable iCloud Private Relay to prevent the two from conflicting. iOS 14 added the includeAllNetworks flag (often used alongside kill-switch behavior) that ensures even system-level DNS goes through the tunnel.

Android

Android's VpnService API lets the VPN client specify DNS servers that apply to all tunneled traffic. The "Always-on VPN" system setting with "Block connections without VPN" enabled provides the strongest guarantee — no app can resolve DNS without the tunnel being active. Android also supports system-wide private DNS (Settings → Network & internet → Private DNS), which forces all DNS to use DNS-over-TLS to a chosen provider. Combining Always-on VPN with Private DNS gives belt-and-suspenders protection against DNS leaks.

macOS

macOS uses scutil and the System Configuration framework to manage DNS settings. A VPN client running through the NetworkExtension framework can install DNS settings that take precedence while the tunnel is active. The main leak vector on macOS is browser-level DNS-over-HTTPS, which bypasses the system resolver entirely — disable browser-level DoH or configure it to point to the same resolver as the VPN. Test with scutil --dns in Terminal to see the active resolvers; only the VPN's resolver should appear in the top-priority section.

Windows

Windows has the largest leak surface of any major OS, primarily because of Smart Multi-Homed Name Resolution. Beyond disabling SMHNR (covered above), check that the VPN's virtual adapter has higher metric priority than your physical adapter, that IPv6 is either disabled or properly tunneled, and that no app is configured with its own DNS overrides. Windows 11 added improved DNS settings UI but the underlying behavior is similar to Windows 10. The ipconfig /all command shows the active resolvers per interface.

What good VPN apps do under the hood to prevent leaks

A well-engineered VPN client doesn't ask you to think about DNS leaks. It handles them as a baseline part of the connection process. Specifically:

• Configures a custom resolver on connect. The client tells the OS "while I'm connected, all DNS queries go to this specific IP address" — typically the VPN provider's own resolver, reachable only through the tunnel. The client also restores the previous DNS settings on disconnect.
• Installs firewall rules to block direct DNS. Even if some app tries to query a DNS server on its own (e.g., a hardcoded query to 8.8.8.8), the firewall rule blocks the outbound packet on UDP port 53. The only DNS that can leave the device is what flows through the tunnel.
• Uses encrypted DNS (DoT or DoH) inside the tunnel. Even after the query is inside the tunnel, the resolver-to-server hop is encrypted with DNS-over-TLS (RFC 7858) or DNS-over-HTTPS so the upstream operator can't see the query content. Our writeup on DNS-over-HTTPS vs DNS-over-TLS covers the trade-offs between the two protocols.
• Handles IPv6 explicitly. IPv6 routes are either tunneled through the VPN (preferred) or blocked at the firewall to prevent IPv6 fallback. The client never leaves IPv6 routing unconfigured.
• Pairs with a kill switch. If the tunnel drops momentarily, the kill switch blocks all traffic — including DNS — until the tunnel re-establishes. This prevents the "tunnel dropped, DNS leaked, tunnel came back" race condition. We cover this in detail in what is a VPN kill switch.
• Tests on every connection. Some clients run a built-in leak test after every connect, flagging any anomaly to the user. This is rare but it's the strongest possible model.

Casper's Cloak uses a custom DNS resolver reachable only inside the WireGuard tunnel, encrypted end-to-end via DNS-over-TLS, with IPv6 routes explicitly tunneled and Windows SMHNR disabled at install time. The threat protection feature performs DNS-level filtering against known-malicious domains at the same resolver, so the same DNS that's leak-protected is also actively blocking phishing and malware. The mechanism is documented in our writeup on how DNS-level filtering actually works. The combined effect: properly configured by default, no leaks under any of the four common failure modes, and active filtering on top.

For the underlying protocol background, the IETF specification of DNS-over-TLS is documented in RFC 7858, which covers the cryptographic and transport-layer requirements for sending DNS over a TLS-secured channel. The same framework is what privacy-focused public resolvers (Cloudflare, Quad9, NextDNS) use for their secure DNS endpoints.

Bottom line: a DNS leak is the most common way a VPN's privacy promise quietly fails. It's easy to test for, usually easy to fix, and any VPN you trust should pass a leak test without manual intervention. If your VPN doesn't, that's a signal — either misconfigure or move on.