TL;DR: A DNS leak is when your DNS queries (the list of sites you open) escape the VPN tunnel and go straight to your ISP, even though your IP address is hidden. To fix it you need a VPN that forces all DNS through the tunnel, blocks IPv6 and WebRTC leaks, and runs a kill switch. You can run a DNS leak test in under a minute on sites like dnsleaktest.com and browserleaks.com: turn the VPN on, run the extended test, and check whose resolver answers. If the results show your ISP instead of the VPN, you have a leak — and below you will find how to close it on any platform.
What DNS is and how name resolution works
DNS (Domain Name System) is the phonebook of the internet. When you type limpvpn.com, your device first asks a DNS resolver, 'what is the IP address of this domain?' and only then connects. The catch is that this query usually travels in plain text, and whoever handles it sees every domain you open.
To understand exactly where a leak happens, it helps to picture the path of an ordinary DNS query. It is short, but it passes through several hops, and at each of them someone can see which domain you requested.
Recursive vs authoritative resolver
Your device almost never talks directly to the servers that 'know' a domain's address. First the query goes to a recursive resolver — usually your ISP's server or a public resolver like 8.8.8.8. It does all the work: it asks the root servers, the zone servers, and finally the authoritative server that actually holds the domain's IP record.
The key point for privacy: the recursive resolver sees absolutely all of your queries. If that resolver belongs to your ISP, then your ISP gets the full list of domains you open. The job of a VPN is to move this step into the encrypted tunnel so that the recursive resolver becomes the VPN's server, not the ISP's.
Plain text and port 53
Classic DNS runs over UDP (sometimes TCP) on port 53 and is not encrypted. That means any hop on the path — your ISP, the owner of a public Wi-Fi, a backbone operator — can read the domain name in clear text. This is exactly what makes DNS such a convenient surveillance channel and so vulnerable to leaks: even if your HTTPS traffic is encrypted, the fact that you 'asked for the address of this domain' is visible.
- Resolver — the server that turns a domain name into an IP address; it is the one that sees your list of sites.
- DNS query — a request to the resolver before each new connection to a domain.
- Port 53 — the standard port for classic DNS; traffic on it travels in plain text.
- ISP — by default your DNS resolver belongs to your ISP, so a leak points straight at them.
- VPN tunnel — the encrypted channel; when configured correctly, DNS queries should travel only inside it.
- The core problem — a hidden IP does not help if the domains still leak out.
What a DNS leak is and why it is dangerous
A DNS leak happens when you are connected to a VPN but your DNS queries still go to your ISP's resolver instead of through the encrypted tunnel. The result: your IP address is hidden, but your browsing history of visited domains is not. From the outside it looks paradoxical: the VPN indicator is green, your public IP belongs to another country, yet your ISP still keeps a full log of your domains.
It may seem harmless that 'the ISP just sees domains.' But the list of domains is the most revealing part of your digital profile. From domains alone, without any page content, it is easy to reconstruct your interests, habits, schedule, and even sensitive topics — health, finances, political views.
- Browsing history — your ISP builds an interest profile: which services, forums, medical or financial sites you visit.
- Logging and retention — in many countries operators are required to retain metadata, and DNS logs are part of that volume.
- Timing and frequency — even without content, it is visible when and how often you reach specific resources.
- Data sales — supposedly anonymized DNS logs sometimes become a product for advertising brokers.
- Defeating the point of a VPN — you pay for privacy, but a leak reduces it to zero at the metadata level.
How exactly your ISP gathers this data and why you should shut it out is covered in how a VPN protects you from ISP tracking. The basic diagnostics that show whether the whole tunnel is doing its job are also worth a read in that guide's companion checks.
Why DNS leaks even with a VPN on
Many people assume 'VPN on equals fully protected.' In reality there are several places where DNS traffic slips around the tunnel, especially with a sloppy client. Understanding these mechanisms is half the solution, because almost every leak falls into one of a few typical causes.
- OS resolver — Windows can send parallel DNS queries across every network adapter at once (smart multi-homed name resolution), and some of them bypass the VPN.
- IPv6 — if the VPN only tunnels IPv4 while your ISP has IPv6 enabled, IPv6 DNS and traffic leak out directly.
- WebRTC — a browser technology for calls and video reveals your real local and public IP around the VPN, even without a separate DNS query.
- Transparent DNS proxy — some ISPs intercept all DNS traffic on port 53 and substitute their own resolver no matter what you set.
- A weak VPN client — a poor app fails to enforce its own DNS servers and leaves the system ones inherited from your ISP.
- Browser DNS-over-HTTPS — Chrome or Firefox may use their own encrypted resolver around your system settings and the VPN tunnel.
It is important to realize these causes are not mutually exclusive: a single device can run both multi-homed resolution on Windows and active IPv6 from the ISP at the same time. That is why it is best to diagnose one factor at a time, disabling each and rerunning the test.
Leak types: cause and fix
To avoid confusion, it helps to keep a short summary of the main leak types in front of you. They all lead to the same outcome — your ISP or a third-party observer sees what should have stayed inside the tunnel — but their causes and cures differ.
| Leak type | Cause | How to fix |
|---|---|---|
| DNS leak | The ISP's system DNS stays active; the client does not enforce its own resolvers | A VPN with forced DNS in the tunnel; remove static DNS on the adapter |
| IPv6 leak | The VPN tunnels only IPv4 while the ISP hands out IPv6 | Tunnel IPv6 in the VPN or disable IPv6 in network settings |
| WebRTC leak | The browser exposes your real IP via a peer-to-peer API | Disable WebRTC with a flag or extension; use a client with protection |
| Transparent DNS proxy | The ISP intercepts port 53 and substitutes answers | Encrypt DNS inside the tunnel (DoH/DoT) on top of the VPN |
| Windows multi-homed resolution | The OS queries resolvers on every adapter in parallel | The client disables smart multi-homed resolution for the session |
This table is a navigator: once the test tells you which address or resolver is leaking, you immediately see which way to dig. Next we cover each case in more detail.
DNS-over-HTTPS and DNS-over-TLS: encrypted DNS
Classic DNS is open, and the industry has long looked for ways to close it. The two main answers are DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT). Both encrypt the DNS query itself so your ISP cannot read or alter it. But how they interact with a VPN is not always obvious.
How DoH and DoT differ
DNS-over-TLS wraps DNS in TLS on a dedicated port 853 — your ISP sees that you use encrypted DNS but not the contents of the queries. DNS-over-HTTPS hides queries inside ordinary HTTPS traffic on port 443, so from the outside it is almost indistinguishable from normal web browsing. For privacy, DoH looks more attractive because it is harder to block or single out.
How encrypted DNS interacts with a VPN
Here lies a subtlety. If your browser uses its own DoH resolver (for example, Chrome with 'Secure DNS' on), it may send queries around the VPN tunnel — straight to Google or Cloudflare, bypassing your VPN's DNS servers. Technically it is encrypted DNS, but the queries still go somewhere other than you intended. So during leak diagnostics it is best to disable browser DoH for the test.
The correct scheme is this: the VPN itself forces all DNS through the tunnel to its own resolvers, and those resolvers can then talk to authoritative servers over encrypted protocols if desired. Then your ISP sees nothing and queries do not leak around the tunnel. If DoH is configured around the VPN, you get encryption but lose control over the route.
- DoH (port 443) — DNS hides in HTTPS, indistinguishable from web traffic, hard to block.
- DoT (port 853) — DNS in TLS on a dedicated port, visible as 'encrypted DNS'.
- Risk with a VPN — browser DoH may send queries around the tunnel to a third-party resolver.
- The correct scheme — DNS is forced into the VPN tunnel; encryption happens at the VPN's resolver.
- For the test — turn off Secure DNS in the browser so you see a clean picture.
How to test for a DNS, IP and WebRTC leak
The check takes a couple of minutes and needs no software — it all happens in the browser. The key is to run it with your VPN on, otherwise you will simply see your ISP's data. Run the checks in order: IP first, then DNS, then WebRTC and IPv6 — that way it is easier to tell which protection layer failed.
- IP test — open a service like whatismyipaddress.com and confirm it shows the VPN server's IP and country, not your real ones.
- DNS test — on dnsleaktest.com run the Extended test and look at which resolvers respond.
- WebRTC test — on browserleaks.com/webrtc confirm that the Public IP fields do not contain your real address.
- Owner check — in the DNS results, the organization (ISP) name should match your VPN provider, not your carrier.
- Repeat without VPN — for contrast, run the same tests with the VPN off to see what a leaked result looks like.
- IPv6 test — on test-ipv6.com check that your real IPv6 address does not answer around the tunnel.
How to read dnsleaktest.com results
The extended test result is a table of servers that answered your queries. Each shows an IP, an owner (ISP/Organization) and a country. A healthy picture: every row points to the VPN provider or its DNS partner, the country matches the VPN server's country, and your home carrier's name appears nowhere.
Warning signs: your real ISP's name appears in the list, your home country or city shows up, or a public resolver (Google, Cloudflare) that you did not configure through the VPN responds. Any such row means part of your queries went around the tunnel. One or two 'foreign' servers already count as a leak — you do not need to wait for the whole list to leak.
How many servers is normal
The number of rows alone tells you nothing: VPN providers often use a pool of several DNS servers, and the results may contain three or four addresses from the same owner. That is normal. What matters is the owner and country of each row, not the count. The one question is always the same: is there even a single server here that belongs to your ISP rather than the VPN?
The IPv6 leak in detail
IPv6 is a common and underestimated cause of leaks. Many VPNs were historically designed around IPv4, and if your ISP hands out an IPv6 address, IPv6 traffic and DNS can go out directly while IPv4 neatly travels through the tunnel. From the outside this looks like a partial leak: IPv4 is clean, but IPv6 exposes your real address.
The problem is that modern sites are increasingly reachable over IPv6, and the operating system prefers it to IPv4 when both are available. So with a 'leaky' IPv6, it is your main traffic that leaks, not rare queries. That makes a test on test-ipv6.com with the VPN on a mandatory step.
- Tunneling IPv6 — the best option: the VPN carries IPv6 through the tunnel just like IPv4.
- Blocking IPv6 — an acceptable option: the client blocks IPv6 for the session so it cannot leak.
- Disabling in the OS — a manual option: turn IPv6 off on the network adapter if the VPN does not cover it.
- IPv6 on the router — a home router may hand out IPv6 independently; sometimes it is easier to disable it there.
- Verification — after changes, rerun test-ipv6.com and confirm your real IPv6 does not answer.
The WebRTC leak in detail
WebRTC is a real-time browser technology for calls, video and file sharing without plugins. To set up a direct connection between two browsers, WebRTC must learn your real IP address — and it does so through the ICE/STUN mechanism, which sometimes bypasses the VPN. As a result, a web page can use JavaScript to obtain your real local and public IP even while the tunnel is up.
Important: a WebRTC leak is a leak of your IP address, not DNS. No separate DNS query happens, so dnsleaktest.com will not show it. You need to check WebRTC separately — on browserleaks.com/webrtc, looking at the Public IP fields. If your real address shows there, your protection is incomplete.
- Browser flag — in Firefox, media.peerconnection.enabled=false disables WebRTC entirely.
- Extension — for Chrome there are extensions that limit local IP exposure.
- Client-side protection — some VPNs intercept WebRTC requests at the network level.
- Verify after changes — rerun browserleaks.com/webrtc and confirm your real IP is not visible.
- Trade-off — fully disabling WebRTC breaks in-browser calls; weigh what matters more to you.
How to fix a DNS leak on different platforms
Good news: almost every leak is cured by correct VPN configuration and a couple of system toggles. But the exact steps depend on the platform, so below are the most common scenarios — Windows, macOS, Android, iOS and the router.
Windows
The main enemy on Windows is smart multi-homed name resolution: the OS queries several resolvers in parallel, and some requests bypass the VPN. A good client disables this itself. You should also check that no static DNS (such as 8.8.8.8) is set on the network adapter overriding the VPN, and, if needed, disable IPv6 when the client does not tunnel it.
macOS
On macOS a typical leak cause is DNS set manually in network settings or inherited from a Wi-Fi profile. Make sure the VPN client manages DNS itself rather than leaving the system ones. As on Windows, check the state of IPv6 and disable it on the interface if the tunnel does not cover IPv6.
Android and iOS
Mobile platforms have fewer settings, and the VPN app takes on most of the control. The main risks are Android's 'Private DNS' feature, which can send queries to a third-party resolver around the tunnel, and system calls/services using their own DNS. On iOS, make sure the VPN profile stays active all the time, not just for individual apps. On both platforms the main defense is choosing a client that forces DNS into the tunnel and closes IPv6.
Router
If the VPN runs on the router, the tunnel works at the network level and DNS for every home device goes through the VPN. But if the router has the ISP's DNS set, the leak hits the whole network at once. Check which DNS servers are configured in the router and disable IPv6 on the router itself if the tunnel does not cover it. The ISP's transparent DNS proxy is especially nasty at this level — only encrypting DNS inside the tunnel gets around it.
The general principle for every platform is the same: the client must force all DNS queries through the tunnel to its own resolvers, keep a kill switch, and close IPv6 and WebRTC. After any change, always rerun the test.
The ISP's transparent DNS proxy: the most stubborn case
The transparent DNS proxy deserves a section of its own, because it is the one leak that ordinary settings cannot defeat. The ISP's idea is simple: intercept all traffic on port 53 regardless of which DNS server you set, and answer with their own resolver. You specify 8.8.8.8 — yet the ISP's server still answers, quietly substituting responses and logging domains.
This scheme is used not only for surveillance but also for blocking: by substituting a DNS answer, the ISP redirects you to a stub page instead of the site you requested. Simply changing the DNS server is useless here — the interception happens at the network level, before your query ever reaches the chosen resolver.
The only reliable cure is encrypting DNS inside the tunnel. When a DNS query is wrapped in an encrypted VPN tunnel (and inside it also in DoH/DoT), the ISP physically cannot read or substitute it: it sees only a stream of encrypted data to the VPN server. So what works against a transparent proxy is a VPN with forced DNS, not manual editing of resolver addresses.
- Interception on port 53 — the ISP catches any open DNS no matter what you set.
- Answer substitution — instead of the right IP you may get a stub or someone else's address.
- Changing DNS does not help — interception happens before the query reaches your resolver.
- The fix is the tunnel — DNS inside an encrypted VPN cannot be intercepted or substituted.
- Sign in the test — the ISP's resolver answers even though you never configured it.
DNS leaks on mobile data and public Wi-Fi
Your connection scenario also affects leak risk. Home wired internet, a mobile carrier network, and public Wi-Fi in a cafe behave differently, and understanding the difference is useful.
On public Wi-Fi the observer is no longer just your ISP but also the access point owner and anyone else on the same network. Open DNS is especially dangerous here: the domains are visible to everyone listening. That is exactly why you should test for a leak first on other people's networks, not only at home.
On mobile data the typical trap is IPv6: carriers increasingly hand out IPv6 addresses by default, and if the VPN does not tunnel it, your main traffic leaks. On top of that, the phone's system services sometimes use their own DNS. So on a smartphone a client that forces all DNS into the tunnel and keeps an always-on connection — rather than turning on only for individual apps — matters even more.
- Home network — one observer (the ISP), but a leak points straight at them and gets logged.
- Public Wi-Fi — many observers; open DNS is visible to the access point owner and network neighbors.
- Mobile data — frequent default IPv6 and the phone's system DNS raise the leak risk.
- Always-on VPN — on a smartphone keep the tunnel permanent so queries do not leak while switching networks.
- Test on the spot — test for a leak on the very network where you care about privacy.
Where to look if DNS still leaks
If tests still show a leak after configuration, the cause is almost always one of a few places. Check them one at a time rather than changing everything at once — otherwise you will not know what actually helped.
- Browser — DNS-over-HTTPS built into Chrome or Firefox may use its own resolver around the VPN; disable it temporarily for a clean test.
- Operating system — on Windows the usual culprit is multi-homed resolution and leftover system DNS on the physical adapter.
- Network adapter — statically configured DNS servers (such as 8.8.8.8) can override the VPN's settings.
- Antivirus and firewall — some 'security' modules replace DNS with their own filtering resolver.
- The VPN client itself — if the app has not been updated in a while, an update often closes known leaks.
If the tunnel stops coming up at all after your DNS tweaks, see the dedicated guide the WireGuard protocol explained for how a modern protocol handles routing. And for how a kill switch stops queries from leaking the moment the tunnel drops, read what a kill switch is in a VPN.
Common mistakes when testing and fixing
Many 'leaks' are actually mistakes in the test itself. Before you change any settings, make sure you are testing correctly.
- Testing without the VPN — the most common mistake: people run the test with the tunnel off and panic over a 'leak' that does not exist.
- Browser and DNS cache — old cache entries may show the previous resolver; clear the cache or test in incognito.
- Active browser DoH — Secure DNS in Chrome sends queries around the tunnel and spoils the test result.
- Several VPNs/proxies at once — stacked tunnels and proxy extensions give contradictory results; keep just one.
- Checking only IPv4 — forgetting IPv6 and WebRTC, which are exactly what often leaks.
- An outdated client — a known leak may already be closed in an update you have not installed.
Checklist: test and fix a DNS leak
Let us put it all into one clear order of actions. Go through the items top to bottom — this is the full 'test then fix then retest' cycle.
- Step 1. Turn on the VPN and confirm the tunnel is actually up (the indicator is active).
- Step 2. Check your IP on whatismyipaddress.com — it should show the VPN server's country.
- Step 3. Run the Extended test on dnsleaktest.com and check the resolvers' owner — your ISP must appear nowhere.
- Step 4. Check WebRTC on browserleaks.com/webrtc — the Public IP fields must not contain your real address.
- Step 5. Check IPv6 on test-ipv6.com — your real IPv6 must not answer around the tunnel.
- Step 6. Found a leak — disable Secure DNS/DoH in the browser, remove static DNS on the adapter, disable or tunnel IPv6.
- Step 7. Make sure a kill switch is on and a modern protocol like WireGuard is in use.
- Step 8. Restart the VPN and rerun all the tests — confirm there are no more leaks.
Why a good VPN prevents DNS leaks
A quality VPN service closes every gap listed above at the client level, so you do not have to hand-edit system settings. Ideally you should never even need to learn the phrase 'multi-homed resolution' — the app does it all for you.
- Forced DNS in the tunnel — all queries go only to the VPN's DNS servers; ISP ones are ignored.
- IPv6 leak protection — the client either tunnels IPv6 or cleanly blocks it for the session.
- Kill switch by default — when the tunnel drops, traffic and DNS queries are blocked instead of escaping directly.
- Strict no-logs policy — the service does not even store its own DNS queries, so there is no metadata to leak.
- Modern protocol — WireGuard with proper routing minimizes the number of places a query can slip out.
For more on the protocol itself and why it handles DNS more cleanly, see the WireGuard protocol explained.
Why try LiMP VPN
LiMP VPN is built on the WireGuard protocol and by default routes all DNS traffic only through the encrypted tunnel to its own resolvers, leaving not a single query for your ISP. A built-in kill switch blocks traffic if the connection drops, and IPv6 leak protection is on from the start — with no manual editing of system settings. The plan is simple: 100 ₽ a month for protection on iOS and Android — you can see the terms on the pricing page.
- Own DNS in the tunnel — your ISP sees none of the domains you open.
- Kill switch — when the tunnel drops, DNS queries do not leak out.
- Strict no-logs — the service does not store your DNS queries or connection history.
- iOS and Android — one layer of protection across all devices for 100 ₽ a month.
- WireGuard — a fast, modern protocol with clean DNS routing.
Frequently asked questions
What is a DNS leak in simple terms?
It is when your IP address is hidden by the VPN, but your DNS queries (the list of domains you open) still go to your ISP's resolver. As a result your ISP sees which sites you visit, even though you think you are protected.
How do I run a DNS leak test for free?
Turn on your VPN and open dnsleaktest.com, then run the Extended test. If the results list your internet provider instead of the VPN service, you have a leak. Also check your IP and WebRTC on browserleaks.com.
Can DNS leak through WebRTC?
WebRTC leaks not so much DNS as your real IP address: the browser exposes it for calls and video around the VPN. It is a separate leak, and you should check it alongside DNS on browserleaks.com/webrtc.
Do I need to disable IPv6 to avoid a leak?
If your VPN does not tunnel IPv6, then yes — otherwise IPv6 traffic and DNS escape the tunnel straight to your ISP. Good clients do this automatically, but with a manual setup you should turn IPv6 off.
Why does DNS leak specifically on Windows?
The culprit is smart multi-homed name resolution: Windows queries DNS servers across all adapters in parallel, and some requests bypass the VPN. A quality VPN client disables this feature for the session.
Does a kill switch help against DNS leaks?
Yes, indirectly. A kill switch blocks all traffic the moment the tunnel drops, preventing queries from slipping to your ISP. But against a constant leak while the tunnel is up, it is forced DNS inside the VPN that saves you.
Does DNS-over-HTTPS protect against a leak on its own?
Not always. DoH encrypts the query, but if the browser is set to a third-party DoH resolver around the VPN, the queries still go around the tunnel to someone else's server. It is more reliable when DNS is forced into the VPN tunnel and encryption happens at the VPN's resolvers.
Conclusion
A DNS leak is an insidious problem: your IP is hidden, the VPN indicator is green, yet your ISP still sees the list of your sites. Fortunately it takes a minute to test and is fixed by the right VPN with forced DNS, a kill switch, and IPv6 and WebRTC protection. Run a DNS leak test right now on dnsleaktest.com and browserleaks.com and make sure the privacy you pay for actually works. LiMP VPN closes all of these gaps by default, so you never have to think about the settings.