How DNS leak tests work

Run one on /dns-leak-test, or check it alongside your address and WebRTC state on /vpn-check.

Why the subdomains have to be random

A cached answer proves nothing. If the test used a fixed name, your resolver would answer from cache after the first visitor and the authoritative server would never learn who asked.

So the test generates a name that has never existed, something like a7f2c9e41b.probe.example.net, unique per session and per probe. No cache anywhere holds it. Whatever resolver your device uses is forced to do the full recursive walk described in what is DNS, which ends at the authoritative server the test operator runs.

That server logs the query and the source address it came from, keyed by the random label so the result can be matched back to your browser session. The page then polls a small API for the addresses collected against your session ID.

The one thing the test measures

The test sees the resolver’s outbound source address, not the address you typed into your network settings.

This distinction causes most of the confusion about results. When you configure 1.1.1.1, you are talking to an anycast front end. That front end passes the recursive work to a separate pool of outbound resolvers, and one of those queries the authoritative server from its own address. The result shows an address you never configured, in a range belonging to the same operator.

The same is true of ISP resolvers and of the resolvers inside a VPN provider’s network. Read the result as “which organisation resolved this”, not “which address did I configure”.

Reading the result

What appears	Meaning
One or more addresses on your VPN provider’s network, and nothing else	Working as intended
Your ISP’s network, with a VPN connected	A leak
A public resolver you chose, with no VPN	Normal
Several addresses from one operator	Normal. A resolver pool
Addresses in two different countries from one operator	Normal for a large anycast network
An unfamiliar operator you never configured	Worth investigating. Check DHCP, the browser’s secure DNS setting, and any installed filtering software

Also compare the country of the resolver with the country of your exit address. A tunnel that exits in Switzerland while DNS resolves from a German resolver on the same provider’s network is not a leak, but a tunnel exiting in Switzerland while DNS resolves from your home ISP is.

How a leak happens with a VPN connected

A VPN client has two jobs: move your packets, and take over name resolution. It usually fails at the second one.

• The system resolver was never changed. The tunnel carries traffic to the destination, but the query for the name went to your ISP first, over the physical interface.
• The tunnel is IPv4 only. The DNS resolver reached over IPv6 stays on your ISP’s path. This is the same failure that leaves IPv6 web traffic outside the tunnel, and it is the most common one.
• The browser runs its own DoH. Firefox and Chrome can resolve inside the browser, bypassing whatever the VPN client set at the operating-system level. Whether that counts as a leak depends on whether you trust the browser’s resolver more than the VPN’s.
• A second resolver survives on another interface. Windows queries resolvers on several interfaces in parallel by default, so a resolver on the physical adapter can answer first even when the tunnel adapter has its own.
• Split tunnelling includes DNS. If port 53 is outside the tunnel by policy, this is configured behaviour rather than a fault.

What a leak does and does not expose

A leaking resolver operator learns the hostnames you resolve, in order, with timestamps. Over a session that is a fairly complete list of the sites you visited. It does not learn page contents, and it does not learn anything the destination site did not already have.

What it specifically does not do is undo the address substitution. If your public IP is the VPN’s, sites still recorded the VPN’s address. A DNS leak and an IP leak are separate failures, and a full check needs both, plus WebRTC, which can expose a local or reflexive address through the browser without touching DNS at all.

Checking it yourself without a test page

The authoritative-server trick is not hard to reproduce if you run a domain. Point a wildcard at a name server you control, tail the query log, and resolve a random name:

dig $(openssl rand -hex 6).probe.example.net

Without a domain, the two useful commands are the ones that show what your system thinks it should use:

resolvectl status
scutil --dns | grep nameserver

Those report configuration. The leak test reports behaviour, and when the two disagree, behaviour is the one that matters.

Fixing a leak

1. Turn on the VPN client’s own DNS setting, whatever it is named. Most call it “use provider DNS” or “DNS leak protection”.
2. Turn on the kill switch so traffic stops rather than falling back when the tunnel drops.
3. Handle IPv6 deliberately: either the provider tunnels it, or the client blocks it. Check on /ipv6-test.
4. Set the browser’s secure DNS to off, or to the provider’s resolver, so the browser and the tunnel agree.
5. Retest on /dns-leak-test with the tunnel connected, and again after reconnecting it, because some clients only apply resolver settings on a fresh connection.