IPDO · Browser privacy checks
DNS Leak Test
Observe which DNS resolvers handle browser probes and look for signs of an exposed ISP resolver.
What is a DNS leak?
A DNS leak happens when your web traffic uses a proxy, VPN, or another tunnel but domain lookups still go to the network's default resolver. A website may see the proxy egress while the ISP, router, or network administrator can still see the domains you asked for. The lookup path and the web egress can therefore reveal different locations or networks.
A DNS leak test complements an IP purity and privacy check. Cross-border commerce, AI services, streaming, and proxy users can compare DNS, WebRTC, and HTTP egress results to find requests that bypass the intended path. A resolver and egress mismatch is a signal to investigate, not automatic proof of a leak.
What is DNS?
DNS (the Domain Name System) translates a domain name into an IP address that a device can connect to, such as resolving baidu.com to an IPv4 or IPv6 address. Browsers, apps, and the operating system usually perform this lookup before connecting to a domain that is not already cached. The recursive resolver may be supplied by an ISP, configured by an organization, or chosen as a public or encrypted DNS service.
Why do DNS leaks happen?
A browser proxy commonly handles HTTP(S) traffic only, and some VPN clients change routing without taking over DNS. The operating system can still query the resolver configured by the network adapter before a connection is made. Rules that resolve a domain to match an IP range can trigger another lookup. FakeIP behavior, split routing, IPv6 paths, and a browser's independent secure DNS setting can also make the real path differ from the expected one.
Why should I care about a DNS leak?
A DNS query does not contain the page contents, but it can reveal the domains you wanted to visit and the order in which you visited them. An ISP, company, or school network may use that information to build an access record. Streaming, AI, and risk-sensitive services may also notice that the DNS location and web egress do not match, which can affect availability or trigger extra checks.
What does this test do?
A browser cannot directly read the computer's DNS configuration, so this page observes where recursive resolvers go for fresh, random names. The result describes the resolvers seen by these probes; it is not a replacement for system-level packet capture or configuration review.
- Generates a 12-character random token and a new subdomain for each probe so cached answers are not reused.
- Sends requests through the browserleaks IPv4 and IPv6 probe endpoints, making the active recursive resolver look up names it has not seen before.
- Reads the resolver IP, country or region, location, and provider returned by the probe, then merges duplicate records.
- Marks possible ISP resolvers using a provider-name heuristic. It is an investigation hint, not confirmation of a leak, and a public resolver is not an absolute safety guarantee.
How should the result be read?
- Resolvers and the web egress follow the same expected network path: this usually means there is no obvious detour, but the proxy's DNS handling still matters.
- An ISP or local broadband resolver appears while the web egress is elsewhere: this is the main DNS leak signal and the proxy's DNS takeover should be checked.
- Only Google, Cloudflare, Quad9, or another public resolver appears: the query was delegated to that provider, which can still see it. This does not automatically mean safe or leaked.
- No resolver was observed: network blocking, an extension, a probe outage, or an incomplete request may be responsible. No result is not proof that there is no DNS leak; try again from another network.
How can DNS leak risk be reduced?
Let the proxy or VPN take over the complete DNS path first, then choose encryption and routing rules for your use case. Reload and test again after changing a setting. Names differ between clients, but the goal is the same: domain lookup and application traffic should follow the intended path.
- Prefer a VPN TUN mode or a proxy client's Tun + FakeIP mode so the local system sees only placeholder addresses and the real lookup happens at the proxy.
- Prefer domain-based routing. When IP matching is necessary, use no-resolve where supported so a local lookup is not triggered just to evaluate a rule.
- DoH or DoT can encrypt the path to a resolver and reduce observation or tampering in transit, but they do not hide the query from the final resolver or guarantee that the proxy handles it.
- Review nameserver-policy, IPv6, browser secure DNS, and router DHCP settings so a fallback path cannot bypass the proxy.
Frequently asked questions
Why can DNS still use the ISP while a VPN is connected?
Many browser proxies and some VPNs handle web connections while leaving DNS on the adapter or router configuration. A full-tunnel mode that also takes over DNS is more likely to keep lookup and web egress consistent.
Does seeing 8.8.8.8 or 1.1.1.1 mean there is no leak?
Not by itself. The page sees the address used by the recursive resolver when it queries the authoritative probe, which may differ from the resolver IP configured on the device. Public DNS reduces reliance on the local ISP, but the provider can still see the query and the route still needs to match your expectation.
Do I still need a test when DoH or DoT is enabled?
Yes. DoH and DoT mainly encrypt the connection between the device and the resolver. They do not guarantee that the proxy performs the lookup or that the resolver cannot see the domain. The probe helps show which resolver ultimately reaches the authoritative service.
Does no observed resolver mean that I am safe?
No. An empty result can come from network restrictions, an extension, a probe outage, or a timeout. It means this run did not observe a response, not that every DNS path is protected.
Does IPDO store the DNS test result?
No. Random probes and result aggregation run in this browser. IPDO cannot read your system DNS configuration and does not upload the lookup history. The probe service can see the network egress that performs the lookup; refer to that provider's policy for retention details.
