How DNS leaks quietly expose your location, even with a VPN running

A VPN encrypts your traffic and routes it through an exit server. That part works. What's less reliable, on Windows specifically, is making sure every DNS lookup also takes that path. When DNS leaks, your ISP sees the domains you visit even though everything else is encrypted. The leak is silent — your browser shows no warning, the VPN client says you're connected, and your ISP is logging every site you look up anyway.

This post explains the four common leak paths, how to test for them, and how Fexyn closes them.

Where the leaks come from

1. Smart Multi-Homed Name Resolution (SMHNR)

Windows 8 introduced a feature called Smart Multi-Homed Name Resolution. It sends DNS queries simultaneously to every available DNS server and uses whichever response comes back first. The intent was to speed up DNS resolution for users with multiple network interfaces.

The result, with a VPN running: your DNS queries go to both the VPN's resolver (inside the tunnel) AND your ISP's resolver (outside the tunnel) at the same time. Your ISP sees the query regardless of whether the VPN's response wins the race.

This was changed slightly in Windows 10 — SMHNR is supposed to prefer the VPN tunnel when one exists. In practice, it doesn't always. The behaviour depends on adapter metric ordering, the Network Connectivity Status Indicator (NCSI), and which interface Windows considers "primary" at any moment. The leaks are intermittent, which is the worst kind: a single test passes, but actual usage leaks.

2. IPv6 fall-through

Most VPN protocols only tunnel IPv4. If your ISP gives you IPv6 connectivity (most do, in 2026) and your machine prefers IPv6 over IPv4, then DNS lookups can take the IPv6 path. The IPv6 query goes out your real interface, hits your ISP's IPv6 DNS resolver, and your ISP sees the lookup.

This isn't theoretical — it's the default behaviour on Windows for the last decade. The fix is to either disable IPv6 on the underlying interface while the VPN is up, or to tunnel IPv6 traffic through the VPN.

3. DNS-over-HTTPS in the browser

Modern Chrome, Firefox, Edge, and Brave can do DNS-over-HTTPS to a public resolver (Cloudflare, Google, Quad9, NextDNS). When DoH is active, the browser bypasses the system DNS layer entirely.

This is good for privacy from your ISP — DoH to Cloudflare is more private than your ISP's resolver. It's bad for VPN-tunnelled DNS, because the browser is now talking to Cloudflare directly through the underlying interface (DoH uses HTTPS, which the OS routes through the active interface — and that's the VPN's tunnel only if the VPN tunnels everything).

The result: DNS leak testers that expect all DNS to come from the VPN's resolver flag DoH-using browsers as "leaking." Whether this is actually a leak depends on what threat model you care about.

4. WebRTC and STUN

WebRTC is a browser API for peer-to-peer connections. It uses STUN servers to discover your public IP. The STUN exchange operates above the network stack — the browser knows your real IP locally and just tells the page when asked.

This is not a DNS leak per se, but it's adjacent. A page running WebRTC can learn your real IP address even with a VPN active and even with all your DNS going through the tunnel. Different fix entirely.

Read the WebRTC piece for that one.

How to test

Use Fexyn's DNS leak test tool while the VPN is connected. Two checks:

Standard test. Single batch of queries. Catches consistent leaks.
Extended test. Six rounds spread over time. Catches intermittent leaks from SMHNR or adapter-priority races.

The result should show only resolvers operated by the VPN provider. If it shows your ISP's resolvers (or your ISP's name in any of the entries), you have a leak.

What an attacker or ISP sees from a leak

Each leaked DNS query gives them:

The exact domain you're looking up
The timestamp
The frequency (if it happens repeatedly)
The pattern of your browsing — which sites correlate to others

This is enough to build a detailed browsing profile. The encrypted traffic itself is opaque, but the destinations are not. Your ISP knows what you browse without ever seeing the contents.

In countries that retain DNS query logs by default (UK under the Investigatory Powers Act, France under the Loi Renseignement, others), the leaks become long-term records. The retention window varies; the existence of the records does not.

How Fexyn prevents leaks on Windows

Fexyn's helper service installs a layered defence:

Name Resolution Policy Table (NRPT) rules. NRPT operates at the OS level, before any application sees the DNS request. Fexyn installs catch-all NRPT rules that force every domain lookup through the VPN's resolver. NRPT overrides per-adapter DNS settings, manual configurations, and SMHNR. It's the OS-level lock on DNS routing.

Per-protocol DNS configuration. Each VPN protocol (WireGuard, VLESS Reality, OpenVPN) is configured with its own DNS path. WireGuard uses the AllowedIPs catch-all. VLESS uses tun2socks with a tunnel DNS override. OpenVPN pushes DNS via dhcp-option DNS. All three converge on the VPN resolver.

IPv6 null-routing. When the VPN is active, Fexyn null-routes IPv6 traffic. Rather than hoping IPv6 takes the tunnel (it sometimes doesn't), all IPv6 traffic is routed to a local null destination. This eliminates the IPv6 leak path entirely. IPv4 connectivity through the tunnel is unaffected.

Windows Filtering Platform kill switch. If the tunnel drops, WFP filters block all non-tunnel traffic — including DNS. There's no leak window during reconnects.

The combination addresses SMHNR (NRPT overrides it), IPv6 fall-through (null-routed), and tunnel-drop leaks (WFP blocks). DoH in the browser is left alone — it's the user's choice whether to use a public DoH resolver or the VPN's.

What to do if you're leaking

If the test shows leaks, work through this in order:

Reconnect the VPN. The simplest fix. NRPT rules sometimes drift after sleep/resume cycles or after a Windows update. A fresh connect re-applies them.
Try a different protocol. Switch to Fexyn Stealth (VLESS Reality) or Fexyn Secure (OpenVPN). Each has a different DNS path; if one is misconfigured for your network, another may not be.
Try a different server. Some servers' resolvers are slower; if the resolver is dropping queries, the OS may fall back to the system resolver.
Check for other VPN clients running. Cloudflare WARP, NordVPN's Meshnet, Tailscale, corporate VPN clients — multiple VPNs install competing NRPT rules and fight each other. Quit (don't just disconnect) any other VPN.
Disable browser DoH temporarily. If you want all DNS to flow through the tunnel for testing purposes, turn off browser-level DoH for the test session.

The full troubleshooting guide is on the support page.

Try Fexyn free for 7 days. The DNS lock is on by default; you don't have to enable it.