DNS Leak Test: How to Detect and Fix VPN DNS Leaks

What a DNS leak actually is

You connect to a VPN expecting your traffic — and the metadata around it — to flow through the VPN provider. A DNS leak breaks that assumption: while your application traffic is correctly encrypted and tunneled, your DNS lookups (the bank.com → 1.2.3.4 translations) escape the tunnel and go directly to your ISP's resolver, or to a third party.

The consequence: your VPN provider sees nothing, but your ISP sees the name of every website you visit. The "browsing privacy" you paid for is partially gone.

DNS leaks are common, often silent, and usually fixable in a few minutes.

How leaks happen

There are four common causes:

1. The VPN client doesn't push DNS

A correctly configured VPN sets your operating system to use a DNS resolver inside the tunnel — usually one operated by the VPN provider. A poorly configured one leaves your system's DNS settings untouched, so lookups continue to go wherever the OS was already sending them (typically the DHCP-assigned resolver of whatever Wi-Fi you're on).

2. The OS prefers a "smart" resolver

iOS has a feature called Private Relay (part of iCloud+) and Android has private DNS. macOS has its own resolver caching. Windows has had the long-running "DNS prefetching" issue where the OS sends parallel queries to multiple resolvers. Each of these can bypass the VPN's DNS setting in specific edge cases.

3. IPv6 escapes the tunnel

Many VPN setups only tunnel IPv4. If your network gives you IPv6 connectivity, IPv6 DNS queries can route around the VPN entirely. This is one of the most common modern leak sources because IPv6 deployment has grown significantly.

4. Apps with their own DNS

Some apps (including a few browsers, like Chrome with DNS-over-HTTPS enabled) maintain their own DNS configuration independent of the OS. Even with a perfectly configured VPN, those apps may resolve names against their hardcoded resolver (often Cloudflare or Google) and reveal which domains you're looking up — to that resolver, not your ISP.

This last category isn't strictly a "leak" in the traditional sense, but it has the same observable effect: someone besides your VPN provider knows what you're looking up.

How to test for a DNS leak

The test is straightforward: while connected to the VPN, visit a service that reports back the resolver that received your query.

Reliable tests:

• dnsleaktest.com — run the "Extended test" (it queries from multiple subdomains to catch round-robin leaks).
• browserleaks.com/dns — shows the resolver and its geographic location.
• ipleak.net — combines DNS, IPv6, and WebRTC checks in one page.

What you want to see: the resolver(s) listed should belong to the VPN provider's network — same ASN, same country as the VPN server you're connected to. If you see your home ISP's name (Comcast, Vodafone, Rostelecom, whoever), you have a leak.

What "leak" looks like in practice

A clean result on a VPN connected to Frankfurt might show:

DNS server: 10.64.0.1
Hostname: dns.veiltun.example
ISP: VeilTun
Country: Germany

A leak typically shows:

DNS server: 192.168.1.1 → 8.8.8.8
ISP: Comcast Cable Communications
Country: United States

The country mismatch is the loudest signal: if your VPN is in Germany but your DNS resolver is in your home country, traffic is leaking.

How to fix it

The fix depends on which of the four causes is at play. In order of likelihood:

Fix 1: Update or replace the VPN client

If you're using an old VPN app, OS-level changes (especially iOS 17+ and Windows 11 DNS handling) may have broken its DNS configuration. Update first. If the leak persists with an updated client and the provider's support can't explain why, the provider's client is broken — switch.

A well-configured WireGuard client (including VeilTun) sets DNS = 10.64.0.1 (or similar) in the WireGuard config and the OS honors it. This is one of WireGuard's structural advantages: DNS routing is part of the protocol config, not a separate negotiation.

Fix 2: Disable IPv6 if it leaks

Test specifically for IPv6 leakage at ipv6leak.com. If your VPN doesn't tunnel IPv6 and your network gives you IPv6, the simplest fix is to disable IPv6 on the affected adapter:

• macOS: System Settings → Network → Wi-Fi → Details → TCP/IP → Configure IPv6 → Link-local only.
• Windows: Network adapter properties → uncheck "Internet Protocol Version 6 (TCP/IPv6)".
• iOS: No user-accessible toggle. Use a VPN that explicitly supports IPv6 tunneling (most modern WireGuard configs do).

This is a workaround, not an ideal solution — better to use a VPN that tunnels IPv6 properly.

Fix 3: Disable iCloud Private Relay (or coordinate with VPN)

On iOS/macOS, iCloud Private Relay can interact unpredictably with VPNs. If you're paying for both, you typically don't need both. Disable Private Relay while using the VPN: Settings → [your name] → iCloud → Private Relay → off.

Fix 4: Force DNS-over-HTTPS through the VPN

If you use a browser with built-in DoH (Chrome, Firefox, Edge), set it to use a resolver inside your VPN provider's network, or turn DoH off entirely. The "default" DoH provider in most browsers is Cloudflare — which means even on a clean VPN, your DNS lookups go to Cloudflare instead of the VPN provider.

In Firefox: Settings → Privacy & Security → DNS over HTTPS → Off (or custom resolver). In Chrome: Settings → Privacy and security → Security → Use secure DNS → with custom (point to VPN's resolver) or Off.

Verifying the fix

After making changes, repeat the leak test from a fresh browser window. Specifically check:

1. DNS test: all reported resolvers belong to the VPN provider.
2. IPv6 test: either tunneled through the VPN or unavailable (shows "no IPv6").
3. WebRTC test: your real IP is not exposed (this is a separate leak class, but worth checking).
4. Browser-level: disable any browser-level DoH that uses a non-VPN resolver.

If all four are clean, you're not leaking.

What VeilTun does about this

A WireGuard tunnel correctly configured pushes a DNS server inside the tunnel and routes IPv6. VeilTun's iOS client uses Apple's Network Extension framework with includeAllNetworks enabled, which prevents most OS-level routing exceptions from leaking around the tunnel. We also recommend (and ship by default) disabling iCloud Private Relay while VeilTun is active, because the two features overlap and the interaction is unpredictable.

If you ever see a leak while connected to VeilTun, that's a bug — tell us and we'll fix it.

The bottom line

DNS leaks are the single most common failure mode in consumer VPN setups. They're easy to test for (one webpage) and usually easy to fix (one setting). Run the test once when you first set up a VPN, and again whenever you change networks, update your OS, or install a new browser. Leak protection isn't a one-time setup — it's a check you periodically repeat.