DNS resolver and leak checks
Compare resolver observations with expected routing, separating ordinary checks, authoritative DNS and HTTP references. A resolver address differs from client egress by design; interpretation needs routing context.
Compare resolvers with your expected routing
Confirm your network and expected proxy rules, then inspect observed recursive resolvers, sources, sample counts and timestamps. Basic and authoritative checks have different coverage; an unconfigured authoritative service remains unavailable.
To investigate answer differences, compare A, AAAA, CNAME and TTL for one domain with multiple resolvers. Check HTTP and WebRTC separately for browser egress; DNS observations do not replace those paths.
Different addresses do not directly establish a leak
Recursive resolvers query names on your behalf; their addresses commonly differ from your public address. CDN steering, caches, forwarders and anycast can affect observations. A leak assessment requires a defined expected route for DNS requests.
Teaching example: exit and resolver countries differ
Suppose HTTP egress is labeled Japan and the resolver United States. Check the label source and resolver role, inspect your proxy DNS configuration, then change one setting and compare saved runs. Two country labels alone are inconclusive. This is an explanatory scenario.
When no resolver is observed
Check timeouts, test-domain resolution and service configuration. Browser privacy restrictions, network blocking or an unavailable service can all produce an empty result; an empty result does not prove there is no DNS leak.
Related tools and guides
Live measurements run in your browser after JavaScript loads. This introduction contains no visitor detection results.