What Is a DNS Leak? Causes and Fixes

A DNS leak is what happens when your device sends its DNS queries to your internet provider's resolver even though a VPN tunnel is connected and carrying your traffic. The tunnel works, the connection looks protected, and yet the questions your device asks, which names it wants to reach, travel outside the tunnel to a resolver you did not choose for this session. Nothing is hacked and nothing is broken in the dramatic sense. It is a configuration gap between what the VPN carries and what the system uses for DNS, and it is common enough that checking for it belongs in any VPN setup.

What actually leaks, and to whom

Every name your device resolves passes through a resolver, and whoever operates that resolver can see the query: the name asked for, the time, and the address asking. Page content stays inside the tunnel and stays encrypted, but the list of names builds a clear picture of which services, sites, and apps you use. That is the whole substance of a leak. DNS resolution explained walks through the resolver's place in the chain, and it is worth being precise about the audience: the exposure is to the resolver's operator, typically your internet provider, not to the open internet at large.

The usual causes

• System fallback. When the tunnel's resolver answers slowly or fails, many systems quietly fall back to the resolver from the local network, because a working answer beats a private one.
• Split tunnelling. Configurations that route only some traffic through the VPN often leave DNS outside the tunnel entirely, pointed at the provider's resolver as if no VPN existed.
• Browser secure DNS. Browsers with their own encrypted DNS setting can send queries to the browser's chosen provider, independent of both the system and the VPN.
• Network changes. Moving between Wi-Fi networks, waking from sleep, or a tunnel reconnect can restore the network's default resolver settings over the tunnel's.
• Unmanaged IPv6. A tunnel set up only for IPv4 leaves IPv6 queries to travel the normal connection to the normal resolver, untouched by the VPN.

Notice what is absent from that list: malice. A leak is almost never an attack. It is the accumulated result of defaults, each component, the operating system, the browser, the VPN client, the router, making its own reasonable choice about which resolver to use, with nobody reconciling the choices. That is also why leaks survive VPN updates and reconnects: the settings causing them were never wrong individually, just never aligned.

How to check which resolver answers you

1. 1

   Note your baseline

   With the VPN disconnected, find which resolver your system is using: it is shown in your network settings, and resolver-check websites will report the operator of the resolver that answers a test lookup. This baseline is usually your provider.

2. 2

   Connect and compare

   Connect the VPN exactly as you normally do, then repeat the same check. If the reported resolver operator is now the VPN provider or a resolver you chose, DNS is inside the tunnel. If it is still your provider, you have a leak.

3. 3

   Check both address families

   Repeat the check on an IPv6-capable connection if you have one. A setup can be sealed for IPv4 and wide open for IPv6, and a single-family check will report success while the other family leaks.

4. 4

   Retest after changing networks

   Wi-Fi to mobile data, one network to another, a tunnel reconnect: each transition is a chance for defaults to return. A check that passes once, on one network, is a snapshot, not a guarantee.

A related tool answers a different question, and keeping them apart avoids confusion: the DNS lookup tool shows what public DNS publishes for a domain, the records themselves. A leak check instead asks who performed the lookup for you. To understand the roles on each side of that question, what a DNS server is separates resolvers from authoritative servers.

Reading a leak check: a worked example

Suppose you run the check with your VPN connected and the page reports several resolver addresses, every one of them operated by your internet provider. That is a leak in plain sight: the tunnel is up and your traffic exits through it, but the names are being resolved by the provider's machines, reached outside the tunnel. Now suppose the same check reports resolvers operated by your VPN provider, or by the public resolver you configured yourself. That is the tunnel doing its job, and the exact addresses varying between runs means little, because large operators answer from pools of machines that rotate.

The awkward case is the mixed result: some answers from your chosen resolver, some from the provider's. Mixed results usually mean two paths are racing, the system sending some queries each way, or one address family sealed and the other left open. Treat a mixed result as a leak, because it is one: any query that escapes is visible to whichever resolver received it, and you cannot control which names take which path or reconstruct afterwards which ones escaped. The fix is the same closing work described below; a partial arrangement is not a stable one, and a checker that passes four runs out of five is reporting a leak with good luck.

What a DNS leak is not

Precision helps, because the term gets stretched. A DNS leak does not expose the content of your browsing: pages, messages, and passwords stay encrypted, and the resolver sees names, not what you did at them. It is not your IP address leaking, which is a separate question about the tunnel itself, and it is not proof that a VPN is fraudulent or broken; most leaks come from ordinary settings on honest software. It also is not a way for random websites to watch you: the observer in a DNS leak is specifically the operator of the resolver your queries escaped to.

Where encrypted DNS fits

Encrypted DNS, the DoH and DoT options in systems and browsers, encrypts the query itself and changes who can observe it: the network in between no longer can, but the chosen resolver still can, because it still does the resolving. On a VPN connection this cuts both ways. Encrypted DNS pointed at your chosen provider can reinforce the tunnel's arrangement. Encrypted DNS pointed somewhere else, a browser default, for instance, quietly rebuilds the leak with better encryption: your provider no longer sees the names, but a resolver you never chose does, outside the tunnel you paid for. The question is never just encrypted or not; it is encrypted to whom.

Leaks beyond the computer: phones, TVs and other devices

The leak model so far assumes one device running one VPN, and real households are messier. A VPN app on a phone protects that phone; it does nothing for the smart TV, the games console or the laptop beside it, each of which resolves names through whatever resolver the router hands out by default. Devices that never run a VPN client at all, most TVs, streaming sticks and internet-of-things gadgets, always ask the default resolver, so their lookups are visible in exactly the way this article describes, tunnel or no tunnel elsewhere in the house.

Phones add a wrinkle of their own. Mobile systems and individual apps can apply separate DNS choices per app or per network, so the browser may resolve inside a protected arrangement while another app asks the network directly. Where the concern is the household rather than one machine, the resolver decision belongs at the router, which sets the default for everything behind it, while the VPN decision is still made per device. A leak check run on one device reports on that device only, and a sealed laptop says nothing about the television.

How to close a leak

Closing a leak means making one deliberate decision about which resolver you trust, then making every layer honour it. In the VPN client, enable its DNS or leak-protection setting so queries are forced through the tunnel to the provider's resolvers. In the system, set the resolver addresses explicitly to the ones you chose rather than accepting the network's, so a fallback has somewhere intended to fall. In the browser, either turn its independent secure-DNS setting off or point it at the same resolver you chose, so it stops making a separate decision. Review split tunnelling so DNS is not exempted from the tunnel. And if your VPN cannot carry IPv6, follow its guidance for that gap rather than leaving the second family to chance. Afterwards, rerun the checks above, including after a network change, because a fix you have not retested is a hope, not a setting.

A few attempted fixes feel productive and change nothing, and they are worth naming:

• Changing the resolver while the VPN is off. If the VPN client installs its own resolver settings when it connects, the addresses you set by hand are replaced at exactly the moment they matter, and your careful configuration never gets used.
• Encrypting to the wrong place. Switching on a browser's secure DNS with its default provider stops the local network seeing your names, but sends them to that provider instead, still outside the tunnel you are trying to seal.
• Testing once, on one network. A pass at home says nothing about the café Wi-Fi where a tunnel reconnect restores different defaults, which is where the check most needed to pass.

None of this makes DNS private in any absolute sense: some resolver always sees your queries, because resolving them is its job. The goal of closing a leak is narrower and achievable, that the resolver seeing them is the one you picked, inside the arrangement you thought you had. A leak is a gap between expectation and configuration, and it closes the moment the two are made to match.