Guide
How to fix a DNS leak
Most guides tell you to switch DNS providers. That doesn’t fix a leak. It changes who receives the leaked queries.
Two problems, not one
Mixing these up is how people “fix” a leak and stay exposed.
- Your queries are going somewhere you didn’t choose.That’s the leak. It’s fixed wherever the diversion happens: your VPN, your operating system, your router, or a device that ignores both.
- Whoever answers them sees every domain you visit. That’s true leak or no leak, and it’s fixed by choosing who you trust.
Encrypted DNS helps with the second and softens the first, since leaked queries at least become unreadable to your ISP, and on port 443 or 853 they can’t be silently rerouted the way port 53 can. The queries are still going somewhere you didn’t pick, though, so fix that properly.
Part one: stop the leak
Where the fix lives depends on what diverted the query. On a VPN it is nearly always the VPN app or the operating system. Without one it is usually the network or the device itself. Skip ahead if that’s you.
Start with the VPN app
Most clients have a setting called DNS leak protection, Use VPN DNS, or Block outside DNS. Turn it on, and turn on the kill switch while you’re there so nothing escapes if the tunnel drops. That’s the whole fix more often than you’d expect.
Windows
Windows is the usual culprit, and it’s by design. It sends the same lookup to every network adapter at once and takes whichever reply arrives first. Your ISP’s server is closer than your VPN’s, so it usually wins. The feature is called smart multi-homed name resolution.
On Pro and Enterprise, open Group Policy and set Turn off smart multi-homed name resolution to Enabled under Computer Configuration → Administrative Templates → Network → DNS Client.
On Home, set DisableSmartNameResolution to 1 under HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient, then reboot.
macOS
macOS leaks when two interfaces are live at once, like Wi-Fi and Ethernet, because each carries its own DNS settings. Turn off the one you’re not using, then check System Settings → Network → your interface → Details → DNS for anything still pinned to your router.
iPhone and iPad
This nearly always means the VPN isn’t capturing all traffic. In the VPN’s settings, look for an option to include all networks or route all traffic. If you’ve installed a custom DNS profile under Settings → General → VPN, DNS & Device Management, it overrides your VPN. Remove it while testing.
Android
Private DNS (Settings → Network & internet → Private DNS) runs independently of your VPN and can send queries straight out regardless of the tunnel. Set it to Off or Automatic while on a VPN, and turn on Block connections without VPN.
Linux
Run resolvectl status and check the per-link DNS servers. If your physical interface still lists your router while the tunnel is up, the VPN never claimed DNS. Most clients fix that by setting ~. as a routing domain on the tunnel interface so it wins for everything.
If you’re not using a VPN
You still configured something, and something is still ignoring it. Work down in this order, because the first one is invisible from the device and the rest are not.
- Check whether your provider intercepts port 53. Some redirect every DNS query on their network to their own servers, transparently, so the answers look correct and nothing warns you. Run the test. If we report your own ISP answering when you configured somebody else, that is what happened. The fix is encrypted DNS, DNS over HTTPS or DNS over TLS, which travels on port 443 or 853 where it can’t be quietly rerouted.
- Set DNS on the router, not just the laptop. A per-device setting is overridden by the next DHCP lease on plenty of networks.
- Turn off your browser’s own DNS. Firefox and Chrome resolve over HTTPS by themselves, bypassing a Pi-hole or a router setting entirely. Firefox: Settings → Privacy & Security → DNS over HTTPS. Chrome: Settings → Privacy and security → Security → Use secure DNS. Either point it at the same resolver as the rest of your network, or switch it off.
- Force stubborn devices through your resolver. Chromecasts and much IoT hardware ignore DHCP and talk to
8.8.8.8regardless. The only reliable fix is a firewall rule on the router redirecting outbound port 53 to your own resolver. - Check the phone isn’t on two networks at once. Wi-Fi and cellular each carry their own DNS settings, and whichever answers first wins.
Your router
Running the VPN on the router itself? Point its upstream DNS at your VPN provider’s resolver. It’s also the only practical way to cover TVs, consoles and smart-home gear that can’t run a VPN client.
Part two: the IPv6 leak nearly everyone misses
Plenty of VPNs only capture IPv4 and let IPv6 walk straight out of the tunnel. If your network has IPv6 and your VPN doesn’t, you can leak all day while every IPv4 test says you’re clean.
- Best fix: use a VPN that routes IPv6 through the tunnel.
- Failing that: turn IPv6 off on the adapter while connected. It works, though you’re giving something up, and more of the internet expects IPv6 every year.
Part three: choose who answers
With the leak closed, one question is left. Who holds the list of every domain you visit? Someone does. Do nothing and it’s your internet provider.
While the VPN is connected, its own resolver is usually the right answer, since the queries never leave the tunnel. Otherwise any of these are solid. No ranking, and no affiliate links.
The right answer while the VPN is on. The queries never leave the tunnel.
Blocks domains known to serve malware. No logging of personal data.
Consistently among the fastest. Publishes independent audits of its retention claims.
You choose the filtering and whether anything is logged at all. Generous free tier.
Per-device profiles and granular rules. Paid beyond a limited free tier.
Use the encrypted form of whichever you pick, DNS over HTTPS or DNS over TLS, so the queries can’t be read or rewritten on the way. All of them support both. If you’d rather nobody outside your house held the list, run a resolver on your own network and point it upstream over an encrypted connection.
Then test again
Reconnect the VPN if you use one, and run the test again. Every resolver listed should be one you deliberately chose, either your VPN’s or the provider you configured. We name each operator so you can tell them apart at a glance. If something you don’t recognise is still answering, the queries are still being diverted and the provider change didn’t fix it. Back to part one.