DNS Leak Test: What It Checks and How to Fix a Leak

Your VPN can be connected, your IP can look correct, and your internet provider can still hold a list of every site you opened. That gap is a DNS leak. Here is how to see it and close it.

A VPN moves your traffic through an encrypted tunnel and gives you a different exit address. Both of those are visible: sites report a new IP, and your provider sees an encrypted stream to a single host. What is not visible, and what people miss for years, is the small piece of the connection that often refuses to go through the tunnel at all: the name lookup that happens before every request. If that lookup escapes, your provider still has a chronological list of every domain you opened, with timestamps, even though it cannot read a single byte of the traffic. That is a DNS leak, and it is the most common way a correctly connected VPN still exposes you.

Why DNS exists in the first place

Computers route by number, people navigate by name. When you type a domain, your device asks a resolver to convert that name into an IP address, and only then does it open the connection. That request is small, it happens before every new connection, and historically it travels in plain text over port 53.

The resolver is normally the one your network handed you over DHCP, which in a home connection means your internet provider. In that arrangement your provider does not merely carry your traffic - it holds a query log naming every site you asked about. Some providers monetise it, some keep it for troubleshooting, some are required by law to retain it. All of them have it.

When you connect a VPN, the tunnel is supposed to take over that job: DNS queries should go inside the tunnel to a resolver on the VPN's side. When something on your device keeps talking to the old resolver instead, everything appears to work, because the pages load correctly. The only sign is in the query log you cannot see.

How a DNS leak test actually works

Understanding the mechanism makes the results readable. The test page generates a set of unique, random hostnames under a domain it controls - something like a1b2c3.test.example.com - and asks your browser to load a resource from each one. Because the hostname is unique and has never been requested before, no cache anywhere in the world holds the answer, so the query must travel all the way to the test's own authoritative nameserver.

That nameserver records which resolver asked. The page then shows you that list: the IP addresses, and usually the owning organisation, of every resolver that participated in looking up your randomised names.

Reading the result is a single question: do these resolvers belong to your VPN provider, or do any of them belong to your internet provider or your mobile carrier? One entry naming your ISP means the tunnel is leaking, no matter how correct the rest of the page looks. Our own check runs this alongside the IP and WebRTC tests at cyphervpn.net/check.html, and stores nothing.

• Pages loading correctly is not evidence of a working tunnel. A DNS leak breaks nothing you can see; that is precisely why it survives for years.

Cause one: the VPN never set a resolver

The simplest case. A WireGuard configuration carries an optional DNS line inside its Interface section. If the provider left it out, your device brings up the tunnel and keeps using whatever resolver it was already using - your provider's.

How to check: open the configuration file or the tunnel details in your client and look for a DNS entry. If there is none, that is the leak.

The fix: add a resolver line to the tunnel. Any config we issue already carries one pointing at the exit machine, but if you are assembling a tunnel by hand, the DNS field belongs in the Interface block, not the Peer block - a mistake that silently does nothing.

Cause two: Windows asks every adapter at once

Windows has a behaviour called smart multi-homed name resolution. Instead of sending a query to the resolver of the active interface, it sends the query to the resolvers of all interfaces in parallel and takes the fastest answer. Your provider's resolver is physically closer than one across a tunnel, so it usually wins - and it logs the query either way.

This is the single most common cause on Windows, and it is doing exactly what Microsoft designed it to do. It is a speed optimisation that predates the assumption that one of your interfaces is a privacy boundary.

The fix: use a VPN client that disables the behaviour while connected, or turn it off in Group Policy under Computer Configuration, Administrative Templates, Network, DNS Client, by enabling the setting that turns off smart multi-homed name resolution. Re-run the test afterwards, because the change does not always apply until the tunnel is rebuilt.

Cause three: IPv6 walks around an IPv4 tunnel

Many tunnels carry IPv4 only. If your connection also has working IPv6, anything that resolves over IPv6 leaves through your normal connection, outside the tunnel - and this leaks more than DNS: the traffic itself goes out unprotected, showing your real address.

How to check: a leak test that reports both an IPv4 and an IPv6 result, where the IPv6 one names your provider, is showing you this exactly.

The fix: use a config whose allowed addresses cover both families, which for WireGuard means an AllowedIPs value of 0.0.0.0/0 together with ::/0. Ours ship that way. If your provider is IPv4-only, the alternative is to disable IPv6 on the adapter while the VPN is connected, which is blunt but effective.

Cause four: the browser has its own DNS

Modern browsers can perform DNS themselves over HTTPS, bypassing the operating system entirely. Chrome and Firefox both ship this, sometimes enabled by default depending on your region and network. When it is on, your browser's queries go to Cloudflare, Google or NextDNS regardless of what your VPN configured.

This one is genuinely ambiguous, not simply bad. Encrypted browser DNS to a third party is far better than plaintext DNS to your provider. But it is worse than DNS inside your tunnel, because it hands a complete browsing list to a company you did not choose, and it makes the leak test's result confusing - the resolver shown is neither your ISP nor your VPN.

The fix: in Firefox, Settings, Privacy and Security, disable DNS over HTTPS while using a VPN whose resolver you trust. In Chrome, the setting sits under Privacy and security, Security, Use secure DNS. Switch it off and the browser returns to the system resolver, which the tunnel controls.

A test order that saves time

Run these in sequence, re-testing between steps, because fixing one cause often changes what the next test shows:

• Test with the VPN off. Record which resolvers appear. This is your baseline, and it is what a leak looks like.
• Connect and test again. Every resolver from the baseline should be gone. If any survives, you have a leak and now you know which resolver to chase.
• Check the IPv6 line separately. An IPv6 result naming your provider is the second cause, and it is more serious than DNS alone.
• Disable browser secure DNS and retest. If the resolver list changes, the browser was doing its own resolution all along.
• Reboot and test once more. Some leaks only appear on a fresh connection, before the client has finished applying its settings.

• Run all three checks in one page.IP address, WebRTC and DNS, in your browser. Nothing is stored and there is nothing to sign up for.Open the leak check ->

The structural fix

Everything above treats symptoms on your device. The other half of the problem sits on the provider's side, and it decides how much your fixes are worth.

Many VPNs route your DNS to a third-party resolver - a public one, or one belonging to their hosting company. That closes the leak in the strict sense: your provider no longer sees the queries. It also hands the full list to somebody else, which is a change of custodian rather than a removal of the record.

The stronger arrangement is a provider whose exit machine resolves DNS itself. The query never leaves the tunnel, never reaches a public resolver, and never becomes anyone's log. That is how our exits are built, and it is what the no-logs policy at cyphervpn.net/privacy.html describes in detail, including the two places where data does exist.

FAQ

What does a DNS leak actually expose?

The list of domains you visit, with timestamps, held by whoever runs the resolver - normally your internet provider. It does not expose the contents of pages or what you did on them, because that traffic stays encrypted. A domain list plus timing is still a detailed picture of your life.

Does a DNS leak mean my VPN is broken?

No, and that is the trap. The tunnel can be carrying your traffic correctly while name lookups take a different path. Sites will show the VPN's IP address and everything will feel normal. The leak is only visible in a test that watches which resolver answered.

Is a DNS leak test reliable?

The mechanism is sound: randomised hostnames cannot be answered from cache, so the resolver has to reveal itself. What varies is interpretation - a test that names a resolver you do not recognise may be showing your browser's secure DNS or your VPN's upstream rather than a leak. Compare the result against a test run with the VPN disconnected.

Will a kill switch stop DNS leaks?

Not by itself. A kill switch blocks traffic when the tunnel drops; a DNS leak happens while the tunnel is perfectly healthy. They address different failures, and you want both.

Is encrypted DNS in my browser enough?

It is better than plaintext DNS to your provider, but it is not the same as DNS inside a tunnel. Your queries reach a large third party who can see the whole list, and it overrides whatever resolver your VPN configured. With a VPN you trust, turn it off and let the tunnel handle resolution.

Next, the leak that survives even correct DNS: WebRTC and what your browser volunteers

• DNS that never leaves the tunnel.Our exits resolve DNS on the machine itself. No account, no email, paid in crypto from $1.99 a week.Get Cypher VPN ->Telegram: t.me/CypherESIM_bot