Resolvers are observed, no direct-baseline resolver persists, and their network/location is consistent with the intended route.
No DNS mismatch was demonstrated in this sample; not every resolver or future lookup is guaranteed.
Focused diagnostic guide
DNS Leak Test: distinguish resolver evidence from a false alarm
A DNS leak test can observe recursive resolvers that query unique hostnames. Resolver geography or ownership alone cannot prove that DNS bypassed an intended route.
Quick answer
What this result can establish
A browser DNS leak test requests unique hostnames and asks an authoritative service which recursive resolvers looked them up. Compare the observed resolver set before and after changing routes. An exact direct-baseline resolver that persists is worth reviewing, but public resolvers, anycast, encrypted DNS, and geolocation errors make country mismatches insufficient proof of a leak.
Evidence boundaries
Signals checked—and what they do not prove
A trustworthy leak verdict separates observable browser evidence from assumptions about identity, ownership, or route intent.
| Signal | Evidence available | What it does not prove |
|---|---|---|
| Authoritative callback | Which recursive resolver addresses requested short-lived, tokenized hostnames created for this run. | The test does not directly read the DNS server configured in the operating system or browser. |
| Resolver set | Unique observed resolver addresses and their reported network ownership and geography. | One run may not reveal every resolver in a rotating pool. |
| Route consistency | Country and network relationship between public browser routes and observed resolver infrastructure. | Public DNS and anycast can legitimately resolve from another city or country. |
| Baseline comparison | Whether resolvers from a saved direct run reappear after the intended route changes. | The same public resolver may be intentionally configured on both routes. |
Methodology
A baseline-first workflow
- 1
Create unique DNS requests
The browser requests short-lived, tokenized hostnames so the authoritative detection service can separate this run from other visitors and cached lookups.
- 2
Collect the recursive resolvers
The detection service reports resolver addresses that asked for those hostnames. Multiple requests improve the chance of observing a rotating resolver pool.
- 3
Enrich but do not overclaim
Network owner and location data help explain the result, but anycast and public resolver infrastructure can make geography differ from the browser exit.
- 4
Compare a direct and routed run
Save the direct resolver set, change one routing variable, and rerun. Review exact baseline matches alongside the DNS configuration you intended to use.
Interpretation
How evidence maps to a qualified status
No Indicator is narrower than “safe,” Review is not a leak verdict, and Unavailable is never converted into a pass.
Resolver geography or ownership differs, or an exact direct-baseline resolver persists after the route changes.
Inspect the intended DNS mode, provider documentation, and repeated runs. This is not automatic proof of identity exposure.
The DNS path is independently verified to bypass the intended route and reach a resolver that the configuration should not use.
Confirmation needs more than a country mismatch—for example, a known direct resolver plus verified routing/configuration evidence.
No authoritative callback arrives, the service is blocked, or the request expires before a resolver set is returned.
No resolver evidence was obtained. Ad blockers, browser policy, DoH behavior, network filtering, or service reachability may be involved.
Troubleshooting
Diagnose the path before changing settings
Resolvers appear in another country.
- Likely explanation
- Anycast, public DNS infrastructure, a centralized VPN resolver, or stale geolocation data.
- Next check
- Compare provider ownership and a saved baseline; repeat the test before changing configuration.
A direct resolver remains after the proxy is enabled.
- Likely explanation
- The application proxy may not control browser or operating-system DNS, or the same resolver is intentionally configured globally.
- Next check
- Verify whether the client resolves names remotely, locally, through DoH, or through the device tunnel.
DNS detection is unavailable.
- Likely explanation
- The authoritative service or tokenized hostnames may be blocked, cached, filtered, or prevented by an extension.
- Next check
- Retry with extensions disabled and another network, then inspect the browser's secure-DNS and VPN DNS settings.
Limits
What this guide and test cannot guarantee
- The observed recursive resolver is not necessarily the resolver address configured on the device; forwarding chains can hide upstream components.
- A finite sample may miss resolvers in a large or rotating pool.
- Country, city, and ASN enrichment are explanatory metadata, not cryptographic proof of a route.
- Encrypted DNS protects query transport but does not by itself prove that the resolver follows the same proxy or VPN path.
Continue testing
Related evidence and route guides
Use one saved baseline across the related checks so differences remain attributable.
Run the complete IP Leak Test
Compare browser-visible IPv4, IPv6, WebRTC, and DNS evidence against a saved direct baseline.
Open resourceRead the route case series
Review anonymized direct, WARP, and browser-proxy observations from one recorded test session.
Open resourceCompare proxy, VPN, and WARP routing
See which routing layers commonly control application DNS and device DNS.
Open resource