DNS Leak Test

A DNS leak happens because resolving a domain and loading the page travel on two separate paths. Your proxy / VPN stuffs HTTP/HTTPS traffic into the tunnel, but when the OS decides which DNS server to ask for example.com, it follows a different routing table. If that part isn't taken over by the proxy, the query leaves your machine in cleartext straight to your ISP's resolver — and all the work hiding your IP is wasted.

The four most common leak paths: (1) Transparent DNS proxy — some ISPs hijack port 53 and silently redirect your query to their own resolver even after you've manually set 1.1.1.1, disguising it so you can't tell; (2) IPv6 escape — many proxies only tunnel IPv4 while the OS prefers IPv6, so IPv6 DNS goes straight out; (3) Windows' Teredo tunnel and Smart Multi-Homed Name Resolution fire queries at several resolvers at once and use whichever answers first; (4) split-tunnel / routing rules that put DNS on the direct-connect allowlist.

In short, "my VPN is on" does not mean "my DNS is on the VPN too." That's what makes a DNS leak so insidious — your exit-IP check looks perfectly green while your resolver has already given you away.

This detector doesn't just read which DNS you configured — it triggers a real lookup and works out who ultimately resolved it for you. It assigns your browser a one-time test ID and has you resolve a series of subdomains shaped like 1.<id>.bash.ws, 2.<id>.bash.ws; each subdomain can only be resolved once, and the authoritative server behind them records which recursive resolver came asking.

This is the key step. You think you're using 1.1.1.1, but if your ISP transparently hijacks DNS, the authoritative side records the ISP's resolver as the source instead. The detector then lists the DNS servers that actually responded for you, each with its location, ASN and operator type. The verdict is simple: compare those resolvers' locations against your proxy's exit region — if even one sits in your real location instead of the proxy's, your DNS is leaking.

IPOK runs this alongside the WebRTC leak and exit-IP consistency checks on the same page, because these three are the pieces of "is my anonymity actually real." Only when the exit IP is right, WebRTC isn't exposing a real IP, and every DNS resolver is on the proxy's side does it count as clean. We don't log the IP you check — results stay on your side.

Many people think a DNS leak is just "my ISP can see my traffic." For cross-border sellers, streaming unblockers and anyone fighting fraud systems, the real damage is in location detection. Modern CDNs and anti-fraud engines read the client subnet your DNS query carries via EDNS Client Subnet (ECS), combine it with the recursive resolver's location seen at the authoritative side, and infer where you "really are."

That produces a split signal: your exit IP says United States, but your DNS query reveals a recursive resolver back home and an ECS subnet that's also back home. For an unblocking service this reads as "suspicious location" — you get greylisted, routed to the wrong region's edge node, or geo-blocked outright. For a risk engine, an IP-vs-DNS location conflict is itself a high-weight anomaly signal; the extra verification, downranking and blocks people hit at signup or checkout often trace back here while they're still busy auditing IP purity.

So testing for DNS leaks isn't privacy fussiness — it's a live check on whether your proxy stack looks like a genuine local user to the other side. Exit IP, DNS resolver, timezone and language all have to point the same way; any one pointing the other way is a tell.

First pin down which path is leaking, then fix that specifically — blindly changing DNS tends to fix one hole and open another. Universal first step: turn on "DNS over the tunnel / Remote DNS / DNS leak protection" in your proxy / VPN client so resolution enters the tunnel too, then re-run this test.

If it still leaks, IPv6 or the OS layer is usually grabbing the route: (1) When you don't need IPv6, disable it in system network settings (or enable "block IPv6 / route ::/0" in the client) to close the cleartext IPv6 path; (2) Windows users should additionally turn off Smart Multi-Homed Name Resolution and disable Teredo (netsh interface teredo set state disabled) so concurrent queries can't bypass the tunnel; (3) Check your proxy's split / routing rules and make sure DNS isn't on the direct-connect allowlist.

If you suspect transparent ISP hijacking (manually changed DNS still leaks), plain DNS changes get intercepted too — only encrypted DNS gets around it. Switch your resolver to DoH / DoT (e.g. Cloudflare's https://1.1.1.1/dns-query, Google's 8.8.8.8) so port-53 hijacking has nothing to grab. Re-test on this page after every change until every listed resolver sits on the proxy's exit side — that's when it's truly plugged.