Every site visit starts with a name lookup. Here is how that request travels, how a VPN can fail to capture it, and how to check whether yours leaks.
On this page
Typing a name like browserscan.one into the address bar is a convenience we take for granted. The internet itself runs on numbers, so before any page loads, your device has to translate that name into the numeric address of a server. The translation is a DNS lookup, it happens before a single byte of the page you asked for leaves your machine, and it is one of the easiest places for a VPN to quietly fail.
The lookup before the page
DNS is a distributed directory with no single machine holding the whole of it. When you visit a site, the sequence runs roughly like this.
- Your device checks its own cache and hosts file. If the name is already there, no network request is needed.
- If it is not, your device asks a resolver: a server, usually run by your ISP or a public provider, that does the legwork on your behalf.
- That resolver walks the hierarchy, asking root servers, then the servers for the top-level domain, then the site’s own authoritative servers, until it has an answer.
- It returns the address to your device and caches it for next time.
The detail that matters is step two. The resolver sees every name you look up. It learns which sites you visit, in what order and how often. That is a detailed browsing history, held by whoever operates the resolver, which by default is your internet provider.
A list of domain names is more revealing than it sounds. Even without a single page view, it describes a person’s interests, habits, health concerns and politics well enough to sketch them.
What a VPN is supposed to capture
A VPN exists to move that trust. Instead of your provider’s resolver, lookups should travel inside the encrypted tunnel and leave from the VPN’s network, using the VPN’s resolver. Your provider then sees only encrypted traffic to a single endpoint. It learns nothing about which sites you visit.
That is the design. The failure mode is that DNS does not always go where the design intends.
Four ways a lookup escapes
A leak is a lookup that travels unencrypted, or to a resolver outside your tunnel. There are four common causes.
- Split tunnelling. If the VPN client routes only some traffic through the tunnel, lookups from excluded applications go out directly to your provider.
- The operating system or browser overrides the tunnel. Modern browsers and phones increasingly use DNS over HTTPS, sending lookups encrypted to a chosen provider. If that provider is a public one rather than your VPN, the lookups bypass the tunnel even though ordinary browsing does not. The encryption protects them in transit, but the resolver still sees them, and it is not the resolver you chose for privacy.
- IPv6. Many VPN clients handle IPv4 reliably and handle IPv6 poorly or not at all. If your network has IPv6 and your provider’s resolver is reachable outside the tunnel over that path, lookups can slip out. We cover this in more detail in IPv4 versus IPv6 privacy.
- A misconfigured client. A VPN can push the wrong resolver address, or fail to push one at all, leaving your device to fall back on whatever the network hands it.
The common thread is that DNS is a separate channel from the traffic you are trying to protect, and protecting one channel does not automatically protect the other.
Reading the test output
You do not have to guess. Our DNS leak test shows which resolvers your lookups reach. Compare that against the resolver your VPN is meant to use; the two should match. Here is how to read what comes back, with a VPN running.
| What the test shows | What it means | Who can read the names | What to do |
|---|---|---|---|
| Resolvers on your VPN’s network | Lookups are inside the tunnel | Only your VPN | Nothing |
| Your provider’s resolvers, at their real location | A leak | Your ISP | Fix the client |
| Resolvers on unrelated networks | An encrypted public resolver | Its operator | Check the setting |
Test more than once, since some clients leak only after a reconnect or when switching between Wi-Fi and mobile data.
Why a leak is worth fixing
A leak does not expose the contents of your traffic. On an HTTPS site it reveals which domains you asked about, not which pages you read — but that is still a lot, and it is fixable. It is a configuration problem, not a limitation of the technology, which is why checking is worthwhile rather than merely alarming.
Hiding your address is also not the same as hiding your activity. The public address a site sees, which you can read on the what is my IP address tool, is one layer, and a resolver log is another, a distinction we draw in what your IP address reveals. DNS is not the only side channel either. The WebRTC leak test checks a different one, where the browser’s own connection discovery hands out addresses it should not, while your ordinary traffic keeps using the address you expect.
Run these two tests
So switch your VPN on and run the DNS leak test before you browse anything sensitive. If the resolvers you see are not your VPN’s, fix the client or its settings before trusting it. Then run the WebRTC leak test as well, so that both side channels are covered rather than just the one you happened to read about.