What a DNS Leak Is, and Where in the Chain It Happens

Before your device connects to a website, it asks a resolver to turn the hostname into an address. A DNS leak is that question leaving your device outside the tunnel, while the connection that follows goes inside it. Nothing breaks and nothing looks wrong — the page loads normally, because the answer was correct. Somebody else simply got to hear the question.

The distinction that matters: a DNS leak exposes the names of the places you went, not the contents of what you did there. That is a smaller loss than it is sometimes described as, and a larger one than it sounds.

Two journeys, one page load

A single visit to a site involves at least two separate outbound conversations, and a VPN client has to capture both.

The first is the lookup: your device sends a short query to a resolver and receives an address back. The second is the connection itself: your device opens a session to that address and exchanges data.

Capturing the second is straightforward: it is ordinary traffic to an ordinary destination, and the routing table sends it through the tunnel like everything else. Capturing the first is a special case, because the resolver’s address is itself configured per network interface, and because the operating system — not your browser, and not the VPN client — decides which resolver to ask. That asymmetry is where the whole problem lives. The chain being interrupted is the one in how DNS resolution works.

Where in the chain it escapes

The escape is always at the first hop: your device to a resolver. Everything after that is somebody else’s business.

When your device asks a resolver, that resolver may go on to consult other servers to find the answer. Those onward steps are outside your control and are not what leaks. What leaks is the single step from your machine to whichever resolver it chose — and if that step went out over the physical interface rather than the tunnel, the operator of that resolver, and your internet provider carrying the query, both learn the hostname.

So the question to ask is never “is my DNS encrypted” but “which resolver received this, and did the query reach it through the tunnel”. Those are two independent properties and both have to be right.

Why the operating system does this deliberately

Resolver settings are not exclusive, and treating them as a list of preferences is by design.

An operating system holds DNS settings per interface. With a VPN connected, your device has resolver settings on the virtual interface and different ones on the physical interface, both valid, both live. Depending on the platform and its version, it may query more than one in parallel and take whichever answers first, or fall back to another interface’s resolver when its first choice is slow.

Both behaviours exist for good reasons — resilience and speed — and neither knows anything about your privacy expectations. The consequence is that a VPN client can correctly configure the tunnel’s resolver and still watch queries go out beside the tunnel, with nothing misconfigured in any conventional sense. This is why leak protection is enforced with firewall rules rather than settings, a point developed in what your VPN’s DNS setting actually changes.

The shapes it takes in practice

Four distinct situations, all reported identically by a test.

The client never replaced the settings. Either it offers a “leave system DNS alone” mode and that is what is selected, or it failed to apply its own. Every lookup goes to whatever your router advertised. This is the cleanest case and the easiest to fix.

Parallel queries. The tunnel’s resolver is configured and used, and another one is also being asked at the same time. Results look contradictory because both resolvers are real.

Fallback on delay. The tunnel resolver is further away than your provider’s and occasionally slower to answer, so the system reaches past it. Intermittent, and the hardest to catch, because a test run at the wrong moment passes.

Interception on the network. Some networks redirect all DNS traffic to their own resolver regardless of what you configured. If the query left outside the tunnel, it can be captured this way and answered by a server you never chose — which is also how a query can be answered incorrectly rather than merely observed.

What the receiving resolver actually learns

A hostname, a timestamp, and your address — repeatedly, for every name your device resolves.

That is enough to reconstruct which services you use and roughly when. It includes the background: the app that checks for messages every few minutes, the software updater, the smart device phoning home. Over a day it is a fairly detailed record of a household’s activity, assembled without seeing a single byte of content.

It does not include which pages you read on a site, what you typed, or anything inside an encrypted session. And hostnames are exposed in more than one place — the beginning of many encrypted connections still names the site — so closing a DNS leak removes one exposure of that name rather than all of them.

Who ends up holding the record is the more interesting question, and it is the same one you face when you choose any resolver at all: see who runs your DNS resolver.

Why encrypted DNS is not the same fix

Encrypting the query changes who can read it, not who receives it.

A browser or system setting that sends lookups over an encrypted connection stops your internet provider from reading them in transit. It does not put them inside the tunnel, and it does not send them to your VPN provider’s resolver — it sends them to whichever resolver that feature was configured to use, which is usually a large public one.

That may be an improvement or a sideways move depending on which party you would rather have the record; the comparison is laid out in DNS over HTTPS versus a VPN. What it definitely does is make leak tests confusing, because the reported resolver is neither your provider’s nor your VPN’s and looks like a fault when it is a feature working as intended.

Closing it

Three things in combination, none of which is sufficient alone.

Point the client at a resolver reachable through the tunnel — normally the provider’s own. Turn on whatever the client calls leak protection, so the alternative paths are blocked rather than merely deprioritised. And disable a browser’s independent encrypted DNS if you want the tunnel’s resolver used consistently, since that feature outranks everything the system was told.

Then verify, and verify again after client updates and on each new network. A DNS leak has no symptoms, which means the only way you will ever know is by looking on purpose.