How to Test and Fix DNS Leaks While Using a VPN

A DNS leak occurs when domain lookups use a resolver outside the path and policy you intended for the VPN. The encrypted tunnel may still carry web traffic while an ISP, local network, browser-selected service, or corporate resolver receives the domain queries. Testing requires more than opening one leak-test page.

Understand What You Are Testing

DNS translates names such as vpnwp.com into addresses. A full-tunnel VPN normally provides a resolver and routes requests to it through the tunnel. A split tunnel may deliberately use different resolvers for public and private zones. That is not automatically a leak; the important question is whether observed behavior matches documented policy.

Browsers can use DNS over HTTPS independently of the Windows adapter. IPv6 can follow a different route from IPv4. Cached results may avoid a new query. These factors explain why two tests on the same computer can appear to disagree.

Record the Baseline

Before connecting, open PowerShell and record:

Get-DnsClientServerAddress
Get-NetIPConfiguration
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric
Get-NetRoute -AddressFamily IPv6 | Sort-Object RouteMetric

Note the active adapter, DNS server addresses, public IPv4 and IPv6 addresses, and browser encrypted-DNS setting. Connect the VPN and run the same commands again. A full-tunnel configuration should show the expected VPN route and resolver policy.

Run More Than One DNS Test

1. Use a reputable browser-based DNS leak test while connected.
2. Repeat in a private window to reduce cache effects.
3. Run Resolve-DnsName from PowerShell for a name you have not recently queried.
4. Compare the observed resolver organization and country with the VPN provider or your own server.
5. If IPv6 is enabled, check the public IPv6 address and confirm that it follows the intended path.

A resolver owned by a cloud or content provider may not display the VPN brand. Confirm the documented resolver addresses before deciding that the result is a leak.

Fix the VPN Adapter DNS Policy

First use the VPN client’s supported DNS setting. Manually forcing an adapter resolver can be overwritten at reconnect or conflict with corporate policy. For WireGuard, the DNS entry belongs in the interface configuration and the resolver must be reachable through AllowedIPs.

Remove stale DNS settings from unused virtual adapters only after recording them. Use Get-NetAdapter to identify old VPN interfaces, and uninstall abandoned clients through Windows settings rather than deleting driver files manually.

Control Browser Encrypted DNS

Review secure DNS or DNS over HTTPS in each browser. Three valid policies exist:

• Use the operating-system resolver so the browser follows the VPN.
• Use a designated encrypted resolver that is explicitly part of your privacy model.
• Apply a managed browser policy for a company environment.

The unsafe state is accidental bypass. Do not assume that enabling encrypted DNS always improves VPN privacy; it changes who receives the queries and may bypass private DNS zones.

Handle IPv6 Deliberately

If the VPN supports IPv6, route it through the tunnel and provide an appropriate resolver. If the VPN is IPv4-only while the local network provides IPv6, an application may reach the internet outside the tunnel. Prefer a VPN with complete IPv6 support. Where that is unavailable, use a documented client setting or adapter policy to prevent unintended IPv6 traffic, then retest after every update.

Do not make broad registry changes copied from an old guide. They can affect local services and future network behavior. A narrow, reversible setting at the VPN or adapter layer is easier to audit.

Split DNS and Corporate VPNs

Corporate environments often resolve internal names through company DNS and public names through another approved resolver. Windows Name Resolution Policy Table rules, VPN client policy, and route metrics may all participate. Test one unique internal name and one unique public name, and document which resolver should answer each.

If internal names fail but public browsing works, do not replace all DNS servers with a public resolver. That can hide the symptom while breaking private service discovery. Check the tunnel route to the internal resolver and the assigned DNS suffix.

Flush Caches and Retest Correctly

After a legitimate configuration change, disconnect the VPN, run Clear-DnsClientCache, reconnect, and query a new name. Restart the browser if it maintains its own cache. Repeat the public IP, IPv6, browser leak, and PowerShell tests. Record screenshots without exposing tunnel keys, internal addresses, or account details.

If the tunnel itself is being rebuilt, follow our safe WireGuard setup for Windows 11. If results vary or time out, first rule out path instability with the latency and packet-loss workflow.

Common Causes of Apparent Leaks

• The browser uses its own encrypted resolver.
• The VPN assigns DNS but does not route that resolver through the tunnel.
• IPv6 remains outside an IPv4-only tunnel.
• A split-tunnel rule intentionally sends public DNS directly.
• An old virtual adapter has a preferred metric or static resolver.
• The test reports the resolver’s upstream network rather than its consumer-facing brand.
• A cached answer means no new DNS request was made.

Frequently Asked Questions

Does seeing Google or Cloudflare prove a DNS leak?

No. A VPN service may use an upstream resolver or anycast infrastructure. Compare the address and documented design, and verify whether the request traveled inside the tunnel.

Should I disable IPv6 permanently?

Prefer complete VPN IPv6 support. A temporary, documented restriction may prevent bypass in an IPv4-only design, but permanent global changes can create other problems and should not replace proper support.

Can DNS over HTTPS leak outside a VPN?

Yes. If the browser connects directly to a chosen DoH provider under split routing, the request may bypass the VPN’s resolver policy even though it remains encrypted.

Final Check

A resolved leak is demonstrated, not assumed. The active routes match the tunnel design, the operating system and browser use approved resolvers, IPv6 follows an explicit policy, private zones still work, and repeated tests agree. Save that known-good state so future client or browser updates can be compared quickly.