A DNS leak happens when the lookups your device performs to turn hostnames like example.com into IP addresses are sent to a DNS resolver that sits outside the privacy boundary you think you have established — most commonly outside your VPN tunnel. The leaking lookups expose every domain you visit to whoever runs that resolver, usually your ISP, even when the rest of your traffic is encrypted.

Does a VPN automatically prevent DNS leaks?

Not always. A VPN reliably tunnels normal IP traffic to its exit, but the operating system decides which DNS resolver to use through a separate code path that the VPN does not always control. Windows in particular is famous for sending DNS to whatever the network DHCP advertised in parallel with the VPN's resolver. Some VPN clients fix this with a 'DNS leak protection' flag; many do not unless you turn it on.

Can my browser leak DNS even if my OS is configured correctly?

Yes. Firefox and Chrome can be configured to send DNS over HTTPS directly to Cloudflare, Google, or NextDNS, bypassing both the system resolver and the VPN. This is great for privacy from your ISP but it means the browser is making queries through a code path that your VPN client cannot inspect. Whether that counts as a "leak" depends on your threat model.

Why does IPv6 keep showing up in leak tests?

Many consumer VPNs only route IPv4. When your machine asks for an IPv6 address and your connection is dual-stack, the resulting AAAA query and the resulting IPv6 traffic both leave through the real interface — visible to the ISP, geo-located normally, and entirely outside the VPN. The fix is either a VPN that supports IPv6 inside the tunnel, or fully disabling IPv6 on the host while the VPN is up.

DNS leak test — is your DNS escaping outside your VPN?

What "DNS leak" actually means

Every time you visit a website, your device first translates the hostname (example.com) into a numeric IP address. That translation happens through the Domain Name System — a request goes from your laptop to a resolver, the resolver chases the answer through a chain of authoritative servers, and the IP comes back. The resolver sees every lookup. If your resolver is your ISP's default, your ISP sees the timestamped list of every domain you visit, even when the connections to those domains are encrypted by HTTPS.

A VPN's job is to put a tunnel between you and the open internet — but only for routed IP traffic. DNS lookups are a separate subsystem. If the VPN client does not also redirect them to a resolver inside the tunnel (or to a resolver the VPN trusts), your lookups continue going to whoever was configured before the VPN came up. That is the leak.

How to test, quickly and confidently

A clean DNS leak test has two parts. First, force a lookup that the resolver cannot have cached — typically a unique random subdomain on a domain whose authoritative server records every query. Second, compare which resolver actually asked the authoritative server, against the resolver you expect. The two best public testers:

dnsleaktest.com — the canonical reference. Run the "Extended test" mode for ~36 lookups so sporadic leaks show up.
browserleaks.com/dns — shows the source IP each authoritative server saw, side by side with your reported ISP and country.
The shell of last resort: with a VPN up, run dig +short whoami.cloudflare CH TXT @1.1.1.1 — the response is the resolver Cloudflare saw. If that matches your VPN provider's resolver, you're clean. If it shows your ISP, you are leaking.

Why this happens — five concrete causes

1. Windows "smart multi-homed name resolution"

By default Windows sends DNS queries in parallel to every configured resolver on every adapter and uses whichever answers first. That includes the resolver your VPN added and the resolver from the underlying physical interface. The VPN almost always wins on routed traffic — but the underlying interface still sees the query, and your ISP sees the lookup. The fix is a group-policy setting (DisableSmartNameResolution) or a VPN client that forcibly removes the underlying resolver while the tunnel is up.

2. Split-tunnel VPNs

Many corporate and consumer VPNs offer "split tunneling" — some apps go over the VPN, everything else goes direct. The split is enforced on routed traffic. DNS rarely gets the same treatment, so the non-VPN apps' lookups still go through the VPN resolver (or vice versa) depending on how the split is implemented. Worth testing both directions.

3. IPv6 dual stack

Your laptop is probably IPv6-capable; your VPN provider is probably IPv4-only. When you visit a dual-stack site, the OS happily queries the AAAA record over IPv6, opens the connection over IPv6, and bypasses the VPN entirely. Run the IPv6 test with the VPN up — if it shows your real ISP and your real IPv6 address, you have an IPv6 leak that is broader than just DNS.

4. DNS-over-HTTPS in the browser

Firefox and Chrome can each be configured to send DNS over HTTPS directly to Cloudflare (1.1.1.1) or Google (8.8.8.8). The traffic looks like normal HTTPS to the network, so the ISP sees nothing — great for privacy from the ISP, but the system VPN client also sees nothing, so the queries are out of its control. Whether this is a "leak" depends on whether your threat model includes the DoH provider as a trustworthy third party.

5. mDNS, NetBIOS, and link-local resolution

On Windows and macOS, queries for unqualified names (printer, nas) often go out as multicast DNS on the local network rather than to your configured resolver. These never leave your LAN segment, so they are not technically a "leak" — but a hostile device on the same coffee-shop Wi-Fi can answer them and observe which hostnames you're looking for. Disable Bonjour/Avahi if you want to fully suppress it.

Fixing it — step by step

If you control your own VPN

Inside your WireGuard or OpenVPN config, add an explicit DNS line that points at a resolver reachable through the tunnel. On Linux the helper resolvconf or systemd-resolved will then enforce that resolver for the lifetime of the connection. On Windows the WireGuard client takes care of this automatically; on macOS the same is true for the native Tunnelblick and official WireGuard clients.

If you use a commercial VPN

Open the client's advanced settings and enable "DNS leak protection," "Block DNS outside the tunnel," or whichever name the vendor uses. Reputable VPNs (Mullvad, ProtonVPN, IVPN, NordVPN, Express) all have this and most have it on by default. If yours doesn't, that itself is a yellow flag.

If you cannot trust any of the above

The hardest fix is the most reliable: disable IPv6 entirely on the host while the VPN is up, configure the OS resolver to point only at the VPN's resolver (deleting every other DNS server), and disable browser-level DoH so all queries flow through the OS path you control. Run the leak test, run it again with a different domain, and run it once more while toggling the VPN off and on. If you see the ISP resolver in any of those three runs, the box is still leaking.

How DNS leaks pair with WebRTC leaks

A DNS leak tells an observer which domains you visited. A WebRTC leak tells a website which IP address you have. They are independent — fixing one does not fix the other. A common operational mistake is to configure a privacy-focused browser correctly for DoH (no DNS leak) but leave WebRTC default-on (still leaking the public IP). Both tools on IPFerret are linked from the diagnostic section of /tools.

FAQ

Will turning off "secure DNS" in Chrome help?

It changes the question rather than answering it. With secure DNS off, Chrome uses the OS resolver, which is whatever your VPN configured — usually safer. With secure DNS on, Chrome talks directly to Cloudflare or Google. Pick the resolver you trust more; that's the trade-off.

Does Tor leak DNS?

The Tor Browser bundle handles DNS correctly — it tunnels lookups through the Tor circuit end-to-end. Rolling your own with a SOCKS proxy and a regular browser is exactly the configuration where DNS leaks live: applications resolve hostnames locally before sending the connection to the proxy, defeating the privacy guarantee.

I run my own router with Pi-hole. Does the VPN matter?

Pi-hole is an ad-blocking resolver, not a privacy tunnel. Your queries are unencrypted between the Pi-hole and its upstream, and the Pi-hole logs every lookup locally. That's fine if you're the only person on the network and you trust your own logs — but a VPN still serves a separate purpose: hiding the queries (and the IP traffic) from your ISP. The two stack: Pi-hole inside the LAN, VPN at the egress.

How fresh is the leak-test data?

Each lookup creates a new entry on the authoritative server. Cached results lie. That is why dnsleaktest.com's "Extended test" generates dozens of unique subdomains in a row — one stale cache hit could hide a leak that runs in parallel for everything else.

Where to go next

WebRTC leak test — the other half of the VPN-privacy story.
IPv6 reachability test — is your traffic v4 or v6 today?
DNS lookup — resolve any record type live via Cloudflare DoH.
Glossary: DNS — five-minute plain-English explanation of how the system actually works.