A VPN is supposed to wrap your internet traffic in an encrypted tunnel, hiding your activity from your ISP and anyone watching the network. But there’s a specific failure mode that quietly breaks this guarantee — one that doesn’t trigger any error message and leaves most users completely unaware: the DNS leak.
When a DNS leak occurs, your device sends domain name resolution requests outside the encrypted tunnel, often directly to your ISP’s default DNS resolver. Your VPN connection can appear healthy and active while your ISP logs every domain you visit. The traffic content may be encrypted, but the destination — the sites you’re reaching — is fully exposed.
What DNS Actually Does and Why It Leaks
Every time you type a URL into a browser, your device needs to translate that human-readable domain into a numerical IP address. That translation request is a DNS query. Under normal VPN operation, these queries should travel through the encrypted tunnel and exit through the VPN provider’s chosen DNS resolver, keeping the request away from your ISP.
DNS leaks happen when the operating system bypasses the VPN’s DNS settings and routes queries through its default resolver instead. Windows is particularly prone to this. A feature introduced in Windows 8 called “Smart Multi-Homed Name Resolution” sends DNS queries to all available network interfaces simultaneously and accepts the fastest response — which is usually the ISP’s resolver, not the VPN’s. This behavior persists in Windows 10 and Windows 11 unless explicitly disabled.
Other causes include VPN clients that fail to override the OS-level DNS settings during connection, DHCP configurations that push ISP resolver addresses to the device before the VPN initializes, and IPv6 connectivity. Many VPN clients focus their DNS routing rules on IPv4 while leaving IPv6 queries unhandled. If your device has an active IPv6 address and the VPN doesn’t tunnel IPv6 traffic, DNS queries over IPv6 bypass the tunnel entirely — a variant sometimes called an IPv6 DNS leak.
What a DNS Leak Actually Reveals
The immediate exposure is your browsing destinations. Every domain you resolve — search engines, news sites, banking portals, messaging apps — appears in the query log of whatever resolver receives it. For an ISP, that data is commercially valuable. In many jurisdictions, ISPs are permitted or required to retain DNS logs, and those records can be subpoenaed, sold in aggregate, or exposed through a breach.
Beyond browsing history, DNS query patterns can reveal behavioral details that go beyond simple site visits. Query timing and frequency can expose when you’re awake and active, what apps are running in the background, and whether specific services like corporate VPNs, financial platforms, or health-related sites are part of your routine. A sequence of DNS queries can sometimes fingerprint a specific application just from the pattern of subdomains it contacts during initialization — analytics endpoints, license servers, and CDN hostnames each leave a recognizable signature.
Detecting a DNS Leak
Several online tools exist specifically to test for DNS leaks while a VPN is active. DNS Leak Test (dnsleaktest.com) and IPLeak.net both show which DNS resolvers are answering your queries during the test. The process is straightforward: connect to your VPN, then load one of these tools. If the resolver addresses shown belong to your ISP or a third-party provider you didn’t configure, your queries are leaking outside the tunnel.
A more precise method is to run the test multiple times and compare the extended results. Some tools offer a “standard” test and an “extended” test — the extended version sends a larger number of queries and checks whether different resolvers respond to different requests, which can catch intermittent leaks that only occur under certain timing conditions. Checking both IPv4 and IPv6 resolver results matters here; a connection can pass the IPv4 check while still leaking over IPv6.
You can also test manually using command-line tools. On Linux and macOS, dig or nslookup can be pointed at specific addresses to confirm which resolver your system is actually using. Running dig whoami.akamai.net will return the IP address of the DNS resolver that handled the query, letting you verify whether it belongs to your VPN provider or someone else. On Windows, nslookup provides similar functionality, though the Smart Multi-Homed Name Resolution behavior can sometimes cause nslookup results to differ from what the browser actually does.
Prevention: Configuration Changes That Work
Fixing a DNS leak requires ensuring that all DNS queries leave through the VPN tunnel and reach a resolver your VPN provider controls — or a trusted third-party resolver you’ve chosen, configured to be reachable only over the tunnel.
On Windows, the first step is disabling Smart Multi-Homed Name Resolution through Group Policy or the registry. The setting lives at Computer Configuration > Administrative Templates > Network > DNS Client > Turn off smart multi-homed name resolution. Setting this to Enabled (which, confusingly, means the feature is disabled) prevents Windows from racing multiple interfaces. Beyond that, setting a static DNS server address in your VPN adapter’s IPv4 and IPv6 properties — rather than relying on automatic assignment — removes the DHCP vector for leak introduction.
VPN client configuration matters significantly. Many commercial VPN clients include a DNS leak protection setting that, when enabled, uses firewall rules to block any DNS traffic not routed through the tunnel interface. OpenVPN configurations can include the block-outside-dns directive, which achieves the same effect on Windows by dropping DNS packets that don’t travel over the tun or tap interface. WireGuard setups require specifying a DNS field in the interface configuration and ensuring the AllowedIPs entry covers the DNS server’s address, so those queries travel through the tunnel.
For IPv6, the safest option if your VPN doesn’t support IPv6 tunneling is to disable IPv6 on the network adapter entirely. This eliminates the leak surface rather than trying to manage it. Some VPN providers configure their clients to block IPv6 traffic at the firewall level instead of disabling it on the adapter, which achieves the same practical result without removing IPv6 support from non-VPN connections. Using a DNS resolver address that exists only within the VPN’s private address range — unreachable from the public internet — is an additional safeguard, since any query that escapes the tunnel will simply fail rather than reaching an ISP resolver.
One detail often overlooked: DNS leak protection settings in a VPN client typically only apply while the VPN is actively connected. During the window between system startup and VPN initialization, the OS sends DNS queries through the default interface. A kill switch that blocks all internet traffic until the VPN tunnel is established closes this gap. On Linux, this is commonly implemented using iptables or nftables rules that default-deny all traffic except through the tunnel interface. Some commercial clients include this as a toggle, though the underlying mechanism and reliability varies considerably between implementations.
The question of which DNS resolver receives your queries after leaving the tunnel is a separate concern from whether the queries leave through the tunnel correctly. Using a VPN provider that operates its own DNS resolvers means your queries are visible to that provider. Whether that’s preferable to ISP visibility depends on your threat model — and the answer isn’t the same for every user.
