Run a focused DNS leak test, compare resolver owner before and after VPN changes, and understand whether a mismatch is a real review item or normal resolver routing.
DNS privacy check
Seeing a resolver mismatch or leak above? Here's how to fix a DNS leak →
The check makes this browser look up one-time names under bash.ws and reads back which resolvers asked bash.ws's authoritative DNS server for them. A forwarding resolver shows only its last hop, browser Secure DNS shows its provider, and a result with nothing to review is not a no-leak guarantee for every app on the device.
What this means for you
This block turns the result into plain language: what the finding does and does not show, and what to do next.
Nothing has been checked yet.
Direct answer
DNS Leak Test reviews limited resolver evidence that the browser and public DNS checks can observe. It can show useful DNS consistency clues, but it cannot prove every app, device, or resolver path is using the same route.
Short answer
If your VPN is connected and DNS still goes to your ISP, router, or an unexpected browser Secure DNS provider, that is worth reviewing. If only the country label differs, it may be anycast, resolver routing, or database mismatch rather than a leak.
| Result | Likely meaning | Next step |
|---|---|---|
| Resolver is VPN provider | Usually expected when the VPN controls DNS. | Run VPN, WebRTC, and IPv6 checks before calling the setup clean. |
| Resolver is ISP/router | Possible DNS leak while VPN is connected. | Review VPN DNS leak protection, Windows adapter DNS, and split tunneling. |
| Resolver is public DNS you chose | May be intentional browser Secure DNS or system DNS. | Document it in the receipt and check whether it matches your goal. |
| Country differs only | Not automatically a leak; anycast and geolocation can differ. | Focus on resolver owner and route intent. |
Use the first run as a baseline, then reconnect the VPN or change Secure DNS and run the DNS leak test again. The useful comparison is whether resolver ownership moved from your ISP, router, or browser Secure DNS provider to the route you expected.
When to investigate
Review the setup when the resolver still belongs to your ISP or router while the VPN is connected, when browser Secure DNS bypasses the route you expected, or when the result changes between normal and private browser profiles.
Then check VPN DNS leak protection, split tunneling, operating-system DNS settings, browser Secure DNS, and router DNS in that order.
How it is measured
Each run gets a one-time id from bash.ws, and your browser looks up a few names under it. Those names exist nowhere else, so the resolvers that ask bash.ws's authoritative DNS server for them are the ones answering for this browser. That is stronger evidence than a public DoH endpoint can give.
The test zone belongs to bash.ws, not MyIPScan. No account is needed, the one-time id stays inside the check, and when bash.ws does not answer, the result says Unable to check instead of showing a clear result.
A DNS review flag means a resolver answered from a different network than your public IP, which may not match what you expected. It is not automatic proof of harm. Receipt exports use safe categories and remove raw resolver IPs and other sensitive diagnostic identifiers. Read the methodology.
See what Safe Copy includes before sharing or saving a result.
Combine IP, WebRTC, IPv6, DNS leak, fingerprint, user-agent, and related privacy signals in one report.
DNS turns a domain name into the IP address your browser needs to connect. This page shows the resolvers that looked up a one-time test name for this browser, with their network and country, next to your public IP, and whether the MyIPScan server-side DNS control is reachable.
A resolver on a different network than your public IP, or in another country, is worth checking against your expected VPN or Secure DNS route. It is not automatic proof of a problem.
This page cannot see every DNS request made by your operating system, router, VPN app, or other apps. A resolver that forwards to another shows only its last hop, and with browser Secure DNS (DoH) on, the result shows the DoH provider rather than your system resolver.
Use the result as a practical signal, then compare it with your VPN app settings and a second network or browser when the signal looks inconsistent.
When you press Run DNS Check, the page gets a one-time id from bash.ws and makes the browser look up a few names under it. The resolvers that ask bash.ws's authoritative DNS server for those names are listed with their IP, network and country, then compared with your public IP: same network, a public DNS service such as Google or Cloudflare, a different network, or a different country and network.
The page also calls the MyIPScan DNS Lookup API for a harmless control lookup of example.com. That API uses a free public DoH resolver, so it shows the site's own DNS path works; it is never counted as evidence about your resolver.
Run the check before changing VPN or secure-DNS settings, save the result, then reconnect your VPN and run the check again. The comparison stays in memory for this page session only.
Fixes
These steps can help when DNS signals do not match the route you expected.
When a VPN is working, the resolver you see should belong to the VPN — not your home ISP. Most major VPNs route DNS through private in-tunnel addresses; this check shows the public address that resolver uses to reach bash.ws, so the resolver owner, not the country label, is what tells you whether DNS is leaking. Use the table below as a reference, then run the check above to compare.
| VPN | Expected DNS when connected | Counts as a leak if you see… |
|---|---|---|
| NordVPN | NordVPN in-tunnel DNS (103.86.96.100 / 103.86.99.100) or a Nord-owned resolver. | Your ISP resolver (e.g. Comcast, BT, Vodafone) while NordVPN shows connected. |
| ExpressVPN | ExpressVPN's own DNS handled inside the tunnel; no separate setup needed. | ISP DNS, or Google/Cloudflare DNS you did not set yourself. |
| ProtonVPN | ProtonVPN in-tunnel resolver (10.2.0.1) on the secure core route. | ISP DNS, especially on Windows after a network change. |
| Mullvad | Mullvad DNS (10.64.0.1) or a Mullvad-operated public resolver. | Any non-Mullvad resolver while connected, including your router. |
| Surfshark | Surfshark private DNS (162.252.172.57 / similar) inside the tunnel. | ISP or router DNS appearing alongside the Surfshark exit IP. |
DNS addresses change as providers update infrastructure, and the in-tunnel addresses above are usually not the address the check shows. The reliable signal is whether the resolver owner matches your VPN. A different country label alone is often anycast routing, not a leak.
Many VPNs only tunnel IPv4. If your network also has IPv6 and the VPN does not handle it, your device can send IPv6 DNS queries straight to your ISP — a leak that an IPv4-only test may miss. If this check or your VPN behaves inconsistently, disable IPv6 at the OS level or pick a VPN that tunnels it, then retest. Confirm separately with the IPv6 Leak Test.
Results explained
No leak: the resolver belongs to your VPN or a privacy DNS you chose. Possible leak: your ISP or router resolver appears while the VPN is connected — review DNS leak protection and IPv6. Unclear: the resolver owner can't be identified, so retest on a second network or browser before drawing a conclusion.
A transparent DNS proxy is a device on your ISP's network that catches ordinary DNS queries (port 53) on their way out and answers them from the ISP's own resolver, whatever server your device asked. You may have set 8.8.8.8 or 1.1.1.1, but the reply comes back as if from that address, so nothing on your device shows the swap.
In your result
Before / after privacy flow
This page is focused on browser-visible resolver signals and resolver-owner mismatch. Run the focused DNS check first, then use Public Exposure Report when IP, WebRTC, IPv6, and fingerprint context also matters. Results are visible browser/session signals, not a certification.
Status language
These labels keep the result understandable without implying a VPN, browser, device, or account is safe.
A browser/session signal was visible and should be compared with what you expected.
The observed signal appears consistent with the stated route or browser behavior.
The signal may need closer review before relying on this setup for the current session.
The check ran, but this page cannot cover every app, device route, server, or future connection.
The tested signal was not observed in this browser/session.
The signal has not run yet or the browser did not provide enough data.
Fix checklist
Settings names change. Treat this as a route to verify, then rerun the focused check and the Public Exposure Report.
Check DNS
Visible DNS resolver signals, including resolver owner, route expectations, browser Secure DNS behavior, and mismatches between DNS and the visible IP route.
Limits
It cannot see every DNS request from every app, inspect router or ISP logs, or prove that all browsing destinations are private.
Read results
A good result means the resolver owner matches the route you expected, or the result explains a known provider or anycast mismatch without an ISP/router resolver appearing unexpectedly.
Warnings
A warning means DNS may still be routed through an ISP, router, browser Secure DNS provider, or resolver path you did not expect while testing.
Fix path
Review VPN DNS settings, browser Secure DNS, router DNS, and split-tunnel rules. Country labels alone can be misleading because DNS uses anycast and shared infrastructure.
Retest
Retest after reconnecting the VPN, changing Secure DNS, changing router DNS, switching browser profiles, or moving to another network.
Runs a limited resolver-signal DNS check and explains what it cannot prove.
The result shows which recursive resolver answered for this browser and how its network compares with your public IP. Resolver evidence is indirect: what reaches us is the resolver that made the final query, which can be your VPN's, your ISP's, or a forwarder somewhere in between.
A DNS leak happens when your device sends DNS queries outside the VPN tunnel — exposing the domains you visit to your ISP or a third-party DNS resolver, even though your VPN is connected. Your IP is hidden, but your browsing destinations are not. A DNS leak test checks which resolver is actually handling your queries.
Run this test while your VPN is connected. If the resolver shown belongs to your ISP (e.g. BT, Comcast, Vodafone) rather than your VPN provider, you have a DNS leak. A clean result shows your VPN provider's DNS servers or a privacy DNS you chose, like Cloudflare or Mullvad. The page compares each resolver's network with your VPN IP for you.
1. Check whether your VPN has a DNS leak protection setting and turn it on - most clients have one, and it is off by default in some. 2. Enable the VPN kill switch so traffic stops if the VPN drops. 3. Manually set your OS DNS to your VPN provider's servers. 4. Disable IPv6 if your VPN does not tunnel it. 5. Retest after each change. Full step-by-step in our DNS leak fix guide.
No. Many VPNs fail to tunnel DNS on Windows after a network change, when split tunneling is on, or on macOS after a sleep-wake cycle. Some VPN apps also respect the OS fallback DNS setting, bypassing the tunnel silently. Always verify with a DNS leak test after connecting — especially after switching networks.
When your VPN is working correctly you should see your VPN provider's DNS servers — not your home ISP's. Inside the tunnel your device asks private addresses such as 10.64.0.1 (Mullvad), 10.0.254.1 (IVPN) or 10.2.0.1 (ProtonVPN); this test shows the public address those resolvers use to reach the internet, which normally sits on your VPN's own network. If the resolver row names your home ISP (e.g. BT), DNS is leaving the tunnel.
Yes. Without a VPN you will see your ISP's DNS resolver, which is the expected result. The test is most useful when run twice: first without a VPN (to see your baseline DNS), then with a VPN connected (to confirm the VPN is routing DNS through its own servers).
Each provider page walks through the same IP, DNS, WebRTC and IPv6 checks with that service connected. Results describe your current browser session only, not a certification or review of the provider.