What a DNS Leak Test Is Actually Testing

You run the test, it prints a list of servers, and one of them belongs to your ISP. The page turns red and tells you that you are leaking. It is probably right — but not for the reason the page implies, and the same test goes green in situations where you are still handing your browsing history to somebody you did not choose.

It is worth knowing exactly what the test can and cannot see.

What DNS is doing in the first place

Before your machine can talk to a site it needs the address behind the name. It asks a resolver — normally your ISP's, because that is what the router handed you — and the resolver answers.

That request is a small, plain, historically unencrypted question, and it is asked before any of the encryption people care about exists. Whoever answers it learns every domain you visit, in order, with timestamps. Not the pages, not the content, not who you are logged in as. Just the names and the timing, which is more than enough to reconstruct a day.

What a leak actually is

A DNS leak is a query that left your machine outside the tunnel.

The connection that follows may still be perfectly encrypted and perfectly tunnelled. The exit address the website sees may be exactly the country you selected. None of that helps, because your ISP already watched you ask for the name.

The three usual causes, in descending order of frequency:

• The client never took over DNS. The tunnel came up, routes changed, and the system resolver stayed pointed at the router.
• IPv6 went around the outside. The VPN captured IPv4 only, your ISP gives you working IPv6, and the operating system prefers IPv6. Everything — not just DNS — takes the door that was left open.
• Windows resolved in parallel. Smart multi-homed name resolution asks every available interface at once and takes the first answer. It is a latency optimisation and a privacy catastrophe, and it is on by default.

Why the test result is easy to misread

A leak test cannot see your machine. It works by having your browser look up a series of unique subdomains that only its own authoritative server can answer, then reporting which resolvers turned up to ask.

That gives it the identity of the resolver that reached the internet, and nothing else. Two consequences:

An unfamiliar server is usually fine. Most providers run their resolvers inside the tunnel on private addresses, which never appear on the public internet. What the test sees is the recursive resolver acting on your behalf — often a data centre in the same city as your exit, owned by a company you have never heard of. Unfamiliar is not a leak.

Green is not proof. If your VPN provider is doing the resolving, the test will be perfectly happy, and your provider will still have the same complete list of names your ISP used to have. This is the point people miss: DNS privacy is a question of who you would rather have the list, not whether anybody has it. A tunnel moves the observer; it does not remove them.

Testing it properly

Three checks, all quick.

1. Look at the resolver your machine will actually use. This is more honest than a website, because it shows configuration rather than behaviour:

# macOS
scutil --dns | grep nameserver

# Linux (systemd-resolved)
resolvectl status

# Windows
Get-DnsClientServerAddress

With the tunnel up, the interface carrying your default route should point at the VPN's resolver. If your router's address (192.168.x.1 or similar) is still listed on an active interface, that is the leak, and you found it without a website's opinion.

2. Run a browser-based test — any of the well-known ones — and read the result correctly: you are looking for your own ISP, or servers in your real city while you are supposedly somewhere else. Not for names you do not recognise.

3. Check IPv6 separately. Visit an IPv6 test page with the VPN connected. If it reports a v6 address belonging to your ISP, DNS is the least of it — a portion of your traffic is bypassing the tunnel entirely.

Fixing a real one

• Turn on whatever your client calls DNS leak protection. It exists in most apps and it is not always on by default.
• Deal with IPv6. Either the client tunnels it properly or it should disable it while connected. Leaving it enabled and unrouted is the worst of the three options.
• On Windows, disable smart multi-homed name resolution. Group Policy, under DNS Client, or the equivalent registry value. Nothing else fixes the parallel-query behaviour.
• Use a system-level kill switch. Firewall rules that block everything outside the tunnel block stray DNS too, which is the tidiest fix because it does not depend on anything resolving correctly. See the kill switch piece.
• Consider encrypted DNS as a floor. DNS-over-HTTPS in the browser stops the local network reading queries even when the tunnel is down. It moves trust to the DoH provider rather than eliminating it, but it is a better default than plaintext to whoever runs the wifi.

The part worth carrying away

A DNS leak test answers one narrow question: which resolver reached the internet for you. It cannot tell you whether the query was encrypted on the way there, whether your provider logs what it resolves, or whether the resolver you are so pleased to see is any more trustworthy than the one you were avoiding.

Fix the leaks it finds. Do not mistake a green banner for privacy — for the longer version of why, start here.

Questions people actually ask