DNS Leak Test: How to Check and Fix Exposed DNS

You run a DNS leak test to answer one question: which DNS resolver handles your lookups when your VPN, secure DNS, or filtering setup is active? If the test shows your ISP’s resolver while you expect your VPN provider’s, your DNS is taking a path you didn’t choose. That path tells someone else which domains you visit.

To check for exposed DNS, first record your normal resolver with the VPN off. Then run a resolver-aware dns leak test with the VPN or secure DNS on, and confirm that every listed resolver belongs to the operator you intended. Any resolver owned by your ISP or local network during a protected session is a leak. Distant servers or multiple servers from your chosen provider are normal.

PacketTools builds its free, no-login diagnostics around this kind of verification. They come from nearly three decades of production network work, and they log no IPs, queries, or test data. DNS privacy comes down to evidence. With a few controlled tests, you can tell whether a strange resolver is a real exposure or ordinary anycast routing.

What Counts as a DNS Leak?

A DNS leak happens when your DNS queries go to a resolver outside the path you configured. The most common case is your ISP’s resolver answering while a VPN is connected. Whether a given resolver counts as a leak depends on what you intended, which is why the definition starts with your setup.

How Do DNS Queries Reach a Resolver?

The domain name system translates names like packettools.com into an IP address before any page content loads. Your device sends that lookup to a recursive DNS resolver. The resolver then asks the authoritative servers for the answer.

Your operating system picks the resolver from one of several places:

• DHCP: Your router or ISP hands out resolver addresses automatically.
• Manual configuration: You set the resolvers yourself on the network adapter.
• VPN client: The client pushes its own DNS servers when the tunnel comes up.
• Browser secure DNS: Chrome, Edge, or Firefox can send DNS-over-HTTPS queries straight to a provider and skip the OS resolver.

A leak test works from the far end of this chain. Your browser looks up unique, never-cached hostnames. The test operator’s authoritative server then records which resolver came asking. You see the resolver’s address and owner. You never see your device’s address in that list.

When Is an Unexpected Resolver Actually a Leak?

An unfamiliar resolver is a leak only when it breaks your intended path. Use this rule set:

Your setup	Resolver shown	Verdict
VPN connected	VPN provider’s DNS	No leak
VPN connected	Your ISP’s DNS	Leak
VPN connected	Google or Cloudflare via browser DoH	Bypass of the VPN, encrypted, a policy decision
No VPN, custom DNS	Your chosen provider	Working as configured
No VPN, custom DNS	Mixed ISP and chosen provider	Partial leak

Your threat model settles the bypass case. If you want only your VPN provider to see lookups, browser DoH to a third party breaks that goal. If your goal is hiding lookups from your ISP, encrypted DoH meets it.

What Can Exposed DNS Queries Reveal?

HTTPS hides page content, but plaintext DNS exposes every hostname you resolve. That includes banking portals, health sites, internal SaaS tenants, and the update servers your software calls home to. Taken together, those lookups add up to a detailed record of your browsing history.

Whoever runs the resolver sees this data, and so does anyone on the unencrypted path. On public Wi-Fi, that can include the hotspot operator. For admins, leaked lookups for internal hostnames also reveal tooling and vendor relationships.

How Are DNS Leaks Different from IP and WebRTC Leaks?

Each leak exposes something different, so each needs its own test:

• DNS leak: reveals which domains you look up to the resolver’s operator.
• IP leak: reveals your real public address to the sites you visit. You can confirm your visible address with a quick check of your IP address.
• WebRTC leak: the browser’s real-time media APIs expose local or public IP addresses through STUN requests, even when a VPN is up.

A clean DNS result says nothing about WebRTC leaks, and a clean WebRTC result says nothing about DNS. Run both checks whenever you validate a VPN.

How Do You Run a Reliable Check?

A reliable check compares a recorded baseline against a protected run, then repeats that comparison across browsers, address families, and networks. A single test from a single tab misses fallback resolvers and browser overrides, and those are where most leaks hide.

Record Your Public IP and Expected DNS Provider

Start with the VPN disconnected and any custom secure DNS turned off. Write down two things:

1. Your public IPv4 address, plus the IPv6 address if you have one. The IP address basics guide explains which one sites see.
2. The organization names behind the DNS servers that appear. These usually belong to your ISP, or to a hotel or office network.

You don’t need every resolver IP. What you need is the operator names that handle your DNS when nothing protects it. Those names become your leak signature, and seeing any of them later means traffic escaped. A screenshot works fine as a record.

Run the Test with Your VPN or Secure DNS Enabled

Connect the VPN and wait until the client reports a full connection. Turn on the kill switch if the client has one. Then flush the local cache so earlier answers don’t skew the run:

• Windows: ipconfig /flushdns
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Linux with systemd-resolved: sudo resolvectl flush-caches

Run the extended mode on dnsleaktest.com, or let browserleaks.com run its automatic DNS check. Extended tests send several rounds of probes, so secondary and fallback resolvers have a chance to show up. A single round can miss them.

Repeat the Check Across Browsers and Networks

One browser can follow different DNS rules from another on the same machine. Run the test in at least two:

• One browser with secure DNS enabled
• One browser with secure DNS disabled

Then repeat on a second network, such as a phone hotspot. Test again right after the VPN reconnects and after waking the laptop from sleep. Leaks often show up during transitions and disappear on a steady connection. If your network has IPv6, confirm the test reports both IPv4 and IPv6 results, because an IPv6 path can skip a tunnel built only for IPv4.

How Do You Interpret the Resolver Results?

You interpret results by checking who operates each listed resolver against the operator you intended. Resolver location and resolver count carry much less weight than ownership, and a browser test has blind spots you should know about before calling a setup clean.

Compare Resolver Operators with Your Intended Setup

Look at the organization or ASN column first. Then sort every resolver into one of these groups:

• Expected: your VPN provider, or the encrypted DNS service you chose. This is a pass.
• Your baseline ISP: any match with the operator names from your unprotected run means ISP DNS is still handling queries. This is a leak.
• Third-party DNS server you didn’t pick: Google DNS or Cloudflare showing up with a VPN active usually points to browser DoH or a manual adapter setting. Trace it before you accept it.

The resolver IP doesn’t need to match the exit IP your VPN gave you. Many providers run DNS on separate infrastructure from their gateways, so a mismatch between those two addresses is normal.

Why Multiple or Distant DNS Servers May Be Normal

Large resolvers use anycast and pools of backend nodes. Several probes in one test can land on several different servers that all belong to the same operator. Ten Google addresses means one provider, so treat that as a single result.

Geography misleads the same way. A US user on Cloudflare might see a resolver in another state, or in another country during peering shifts. Distance tells you about routing. Ownership tells you about privacy. If timing looks off, a ping test or a traceroute to the resolver shows where the latency comes from.

What a Browser-Based Test Cannot Prove

A browser test only sees what the browser resolves. Its limits:

• DNS over TLS (DoT) runs at the system level on port 853, and a web page can’t detect it.
• Encryption labels in many tools reflect whether a provider supports encrypted DNS. They don’t confirm your connection uses DNS-over-HTTPS (DoH) or DoT. Cloudflare queried over plaintext port 53 still gets labeled “encrypted.”
• Apps, games, and background services can resolve through other paths the page never sees.
• A result showing no resolvers at all often means browser DoH, aggressive security software, or caching blocked the probes.

To confirm DNS traffic outside the browser, capture packets with Wireshark. Unencrypted queries to non-tunnel interfaces show up immediately.

Why Does DNS Bypass the Intended Path?

DNS bypasses your intended path when some layer (the OS, router, browser, or VPN client) applies its own resolver choice after your configuration takes effect. The causes fall into three groups: how the tunnel claims DNS, where settings compete, and what happens during network changes.

How VPN Tunnels and DNS Resolver Choices Interact

A VPN client protects DNS when it does two things. It pushes its own resolvers, and it blocks DNS sent anywhere else. That blocking is what clients call DNS leak protection. Without it, the OS can still reach the original resolver through the physical adapter.

Manual OpenVPN or WireGuard profiles cause this often. If the config omits a DNS line, or the OS ignores it, the tunnel carries your traffic while DNS keeps going to the router. Split tunneling makes it worse: excluded apps, or a browser on the exclusion list, resolve outside the tunnel by design. A general DNS troubleshooting walkthrough helps you confirm which interface owns DNS.

Where Device, Router, and Browser Settings Conflict

Each layer can override the one below it:

• Router DHCP pushes ISP DNS to every client. Your laptop might be correct while the TV and phones leak. Check the DNS fields in your router’s admin interface.
• Manual DNS setup on the adapter competes with resolvers the VPN pushes.
• Smart Multi-Homed Name Resolution in Windows sends queries out every interface in parallel and takes the fastest answer. That behavior hands lookups to the ISP resolver while the VPN is up.
• Browser DoH skips the OS resolver entirely and sends queries to the browser’s chosen provider.

When IPv6, Reconnection Gaps, or Software Change the Route

An IPv6 leak happens when the tunnel carries only IPv4 while your ISP provides working IPv6. Your device prefers IPv6 and sends DNS outside the tunnel. The IPv4 vs IPv6 comparison explains why dual-stack systems choose v6 first.

Reconnection gaps cause leaks that come and go. When a laptop wakes or switches Wi-Fi, the OS restores the default resolver before the tunnel comes back. Software causes the rest: updates that reset DNS settings, and malware that rewrites resolvers to send you to phishing servers.

How Do You Fix and Prevent Unintended DNS Routing?

Fix DNS routing one layer at a time, and retest after each change so you know which fix closed the leak. Start with the VPN and the OS, isolate the browser and IPv6 next, and then add encryption and network-level controls.

Correct VPN and System DNS Settings, Then Retest

Here is how to fix a DNS leak at the base layer:

1. Use the provider’s official client in place of a hand-built profile whenever one exists.
2. Turn on DNS leak protection and the kill switch, and never turn either off.
3. Set the physical adapter’s DNS back to automatic so it can’t compete with the tunnel’s resolvers.
4. Take your browser off any split-tunnel exclusion list, or disable split tunneling.
5. On Windows, disable Smart Multi-Homed Name Resolution through Group Policy (“Turn off smart multi-homed name resolution”).
6. Update or reinstall the client. Older versions mishandle network changes.

Flush the DNS cache, reconnect, and run the extended test again. Change one variable per run. If lookups start failing after a change, the DNS lookup failed and DNS server not responding guides cover the common breakages.

Check Browser Secure DNS and IPv6 Separately

Browser secure DNS gets its own decision. To keep all lookups inside the VPN, turn it off:

• Chrome: Settings → Privacy and security → Security → Use secure DNS
• Firefox: Settings → General → Network Settings → Enable DNS over HTTPS

If you’re comfortable with your DNS provider handling queries in place of your VPN, keeping DoH on is a valid choice.

For IPv6, turn on the client’s IPv6 leak protection. If the VPN can’t tunnel v6, disable IPv6 on the active adapter, then test IPv4 and IPv6 again separately.

Use Encrypted DNS and Network Controls Where Appropriate

How you prevent DNS leaks without a VPN depends on encryption plus enforcement. Configure DNS over HTTPS (DoH) or DNS over TLS (DoT) at the OS or router so lookups leave the device encrypted. That stops on-path snooping and DNS spoofing, and it blunts man-in-the-middle attacks on public Wi-Fi.

On networks you manage, block outbound port 53 to everything except your approved resolvers, and allow port 853 only to your DoT provider. Devices that hardcode resolvers then fail closed and can’t leak. The same rule cuts off malware that redirects DNS to phishing infrastructure. Confirm the firewall rule with an open port checker and a fresh resolver test.

Verify That DNS Uses the Resolver You Chose

DNS privacy holds only when the resolver in your test results matches the one you configured, every time you check. Record a baseline with protection off. Run extended tests with protection on, and judge each resolver by its operator. Location and resolver count tell you little.

ISP resolvers during a VPN session are a leak. Several nodes from your chosen provider are normal, and browser DoH to a third party is a policy choice you make on purpose. When results look wrong, fix one layer at a time: VPN client, adapter, browser, IPv6, then network enforcement.

Repeat the check after client updates, Wi-Fi changes, and wake-from-sleep, because transitions are when DNS falls back to the default resolver. Keep the baseline screenshot from your unprotected run, since spotting any of those operator names later is the fastest way to catch an exposed DNS resolver.