What is a DNS leak and how to stop it

Before your browser can load a page it has to turn a name into an address, and that question goes to a DNS resolver. When you use a VPN or a proxy, you expect the question to travel inside the tunnel along with everything else. A DNS leak is what happens when it does not: the lookup goes out the ordinary way, to your provider's resolver, with your real connection behind it. The page itself still loads through the tunnel, so nothing looks wrong, but the lookup has already told a third party where you really are.

This article explains how that happens, how a leak test catches it, and how to stop it on each operating system, in each browser and in the VPN or proxy itself.

How DNS resolution normally works

1. Your application asks the operating system's stub resolver for the address of a name.
2. The stub resolver sends the query to the recursive resolver it has been given, usually by your router over DHCP, which in turn got it from your provider.
3. The recursive resolver walks the DNS hierarchy, asking the root, the top-level domain and finally the authoritative name server for that domain, then caches the answer for the record's TTL.
4. The answer comes back and the application connects to the address.

Two parties learn something in that chain. The recursive resolver sees every name you look up, which is why your provider's resolver is a privacy problem in itself. The authoritative name server sees the address of the recursive resolver that asked, which is how a test page can tell which resolver you are really using.

What leaks, exactly

A website never sees your DNS query. What leaks is the identity of your resolver, and with it:

• Your real provider, because the resolver belongs to it.
• Your real country or region, because the resolver sits there.
• Every domain you visit, to the provider, even though the page content is encrypted.

For privacy users the third point is the problem. For anyone using a proxy or VPN to appear somewhere else, the first 2 are, because they create a contradiction: an address in one country and resolvers in another. Fraud and anti-abuse systems that operate name servers for their own domains can observe exactly this, and our anonymity score deducts 15 points for it. The glossary entry on DNS leak has the short definition; the rest of this article is the mechanics.

How a DNS leak test works

The test cannot ask your resolver who it is, so it works from the other end. The page makes your browser request a handful of hostnames that have never existed before, under a domain whose only authoritative name server is ours. The only way to resolve those names is to ask that server, so every resolver that does so has identified itself. The test then compares each resolver's network and country with your public IP.

Run the DNS leak test and read the table: each row is a resolver that asked for one of your unique names, with its address, network and country. Pass means every resolver belongs to the same provider as your IP or sits in the same country. Resolvers in your real country while the IP is somewhere else is the leak. Large public resolvers answer from many machines, so the address you see may not be the one you configured, but its operator and country still tell the story.

The 6 common causes

Cause	What happens	Typical setup
Manually set DNS on the adapter	The system keeps using the configured resolver even though a tunnel is up	Someone set a public resolver years ago and forgot
Browser Secure DNS (DNS over HTTPS)	The browser bypasses the system resolver and talks to its own DoH provider directly	Chrome, Edge, Brave and Firefox with DoH on
IPv6 DNS	The router advertises an IPv6 resolver; queries to it travel outside an IPv4-only tunnel	Any dual-stack network with a VPN that ignores IPv6
Split tunneling	Apps or domains excluded from the VPN resolve names directly	Gaming or streaming exclusions, corporate split DNS
Proxy without remote DNS	The browser resolves the name locally and sends only the connection through the proxy	HTTP and SOCKS proxies, antidetect profiles
Multi-homed resolution on Windows	Windows sends the query out of every interface and uses the fastest answer	Any Windows machine with a VPN adapter plus a physical adapter

A seventh, rarer cause is a VPN that drops and reconnects: during the gap the system falls back to the physical adapter's resolver and the operating system caches the answers. Clients with a kill switch prevent this.

Fixes by operating system

Windows

1. Open Settings > Network & internet, click Wi-Fi or Ethernet, then the active connection.
2. Next to "DNS server assignment" click Edit. If it is set to Manual with a resolver you did not expect, switch it to Automatic (DHCP) so the VPN can override it, or set it to the VPN's resolver.
3. Turn off multi-homed resolution. Open the Local Group Policy Editor (gpedit.msc), go to Computer Configuration > Administrative Templates > Network > DNS Client and set "Turn off smart multi-homed name resolution" to Enabled. On Windows Home editions, which lack the policy editor, create the DWORD value DisableSmartNameResolution = 1 under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient.
4. Flush the cache with ipconfig /flushdns and re-run the test.

Windows 11 also supports encrypted DNS on the adapter itself (the "DNS over HTTPS" option under the same Edit dialog). Leave it off while a VPN is active unless the VPN's own resolver supports it.

macOS

1. Open System Settings > Network, select the connection and click Details…, then the DNS tab.
2. Remove any manually added resolvers, or replace them with the VPN's.
3. Run scutil --dns in Terminal to see the resolvers the system is really using for each interface; the entry for the VPN interface should be listed first.
4. Flush the cache: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.

Linux

1. Run resolvectl status (systemd-resolved) to see the resolver per interface. The VPN interface should show its own DNS server and the routing domain ~., which means "use this for everything". If only the physical interface has a resolver, the VPN client did not configure DNS.
2. Without systemd-resolved, check /etc/resolv.conf; a VPN that manages DNS rewrites it while connected.
3. With NetworkManager, pin a resolver on a connection with nmcli connection modify "name" ipv4.dns "address" ipv4.ignore-auto-dns yes, then reconnect.

Android

Settings > Network & internet > Private DNS. "Automatic" uses encrypted DNS when the network's resolver supports it, "Private DNS provider hostname" sends every query to that provider. With a VPN running, set it to Off or Automatic so the VPN's resolver is used, then test. On mobile data without a VPN, the carrier's resolver is used and there is nothing to leak around.

iPhone and iPad

iOS uses the resolver of the active network, or the one a VPN app installs. For Wi-Fi, manual resolvers live under Settings > Wi-Fi > the i icon > Configure DNS; set it to Automatic if a VPN should control DNS. There is no manual DNS setting for cellular.

Fixes by browser

Browser-level encrypted DNS is the cause people overlook most, because it bypasses every system setting above.

• Chrome: Settings > Privacy and security > Security > "Use secure DNS". Turn it off while using a VPN, or set it to "With your current service provider", which keeps the system resolver.
• Edge: Settings > Privacy, search, and services > Security > "Use secure DNS to specify how to lookup the network address for websites". Same 2 choices.
• Brave: Settings > Privacy and security > Security > "Use secure DNS".
• Firefox: Settings > Privacy & Security, scroll to "DNS over HTTPS". "Default Protection" defers to the system when a VPN is present; "Increased" and "Max" force Firefox's DoH resolver regardless. Choose Default or Off while tunneling.
• Firefox with a SOCKS proxy: in Settings > Network Settings, tick "Proxy DNS when using SOCKS v5" (the preference network.proxy.socks_remote_dns). Without it the browser resolves names locally and only the connection goes through the proxy.

For proxies in general, the question is whether the browser sends the hostname to the proxy or resolves it first. HTTP proxies receive the hostname by design. SOCKS5 can do either, and the default varies by client, so test rather than assume. Antidetect browsers expose the choice per profile, often labeled "DNS through proxy" or "remote DNS"; turn it on.

Fixes in the VPN client

1. Enable the option named "DNS leak protection", "Use VPN DNS" or similar. It forces all queries to the resolver inside the tunnel and blocks the others.
2. Disable split tunneling while testing, then re-enable it only for apps that do not need to hide. Remember that an excluded app resolves names on its own.
3. Check the IPv6 setting. A client that tunnels IPv4 only must either block IPv6 or assign an IPv6 address inside the tunnel; otherwise IPv6 DNS queries, and IPv6 traffic in general, leak. The IPv6 leak entry and the IPv6 test cover this side.
4. Turn on the kill switch so that a dropped tunnel does not silently fall back to the physical adapter.

Verifying the fix

After each change, flush the DNS cache, restart the browser so that it drops its own cache, and run the test again from the same browser you will actually use. The resolver list should contain only addresses that belong to the VPN or proxy, or public resolvers reached through the tunnel and therefore located at the tunnel's exit. The combined IP leak test runs the DNS check next to the WebRTC and IPv6 checks, which is the quickest way to confirm that closing one door did not leave another open.

If you want to see the resolution side directly, the DNS lookup shows what our resolver returns for any name, which is useful when a leak-free setup resolves a site to a different address than your previous resolver did; that is normal for content networks and not a sign of a problem.

The limits of a leak test

A test can only report the resolvers that asked our name server during the run. A system that sends queries to several resolvers in parallel may show a different mix on each run, so run it twice. Corporate networks with internal resolvers, routers that intercept port 53 and redirect it to the provider, and resolvers that forward to other resolvers all change the picture, and the result will describe those cases rather than claim certainty. What it will never do is miss a resolver that asked: if your real provider's resolver appears, the query reached it, whatever the VPN's status screen says.