A DNS leak test is not just a list of resolver IP addresses. A credible test must create a unique DNS query, observe which recursive resolver reaches controlled authoritative infrastructure, and connect that observation to the browser session that initiated the test.
What DNS does in a normal connection
Before a browser connects to a domain, it usually needs an IP address. The device, browser, operating system, router, VPN, or encrypted-DNS client sends a query to a recursive resolver. That resolver performs or retrieves the lookup and returns the answer.
What “leak” means in context
In VPN and proxy discussions, a DNS leak usually means the resolver path does not match the path the user expected. Examples include an ISP resolver still receiving queries after a VPN connects, a browser using its own encrypted-DNS provider instead of the operating system, or one application bypassing the DNS configuration used by another.
| Observed resolver | Possible explanation | Is it automatically a leak? |
|---|---|---|
| VPN-operated resolver | The tunnel handles DNS as expected | No, but ownership and routing still need interpretation |
| ISP resolver | The normal network path may still handle DNS | Potentially, if the user expected the VPN to handle it |
| Public resolver | Manual configuration, browser DoH, router policy, or VPN choice | No; intent and route matter |
| Enterprise resolver | Managed device, VPN, or private network policy | No; it may be required |
| Multiple resolvers | Fallback, parallel queries, split DNS, IPv4/IPv6 differences, or caching | Not automatically; investigate the pattern |
Why controlled infrastructure matters
A test page can generate a random subdomain that has never been requested before. When the browser or another test mechanism triggers that lookup, the authoritative DNS server can log the recursive resolver that asked for the record. The test then maps the random identifier back to the browser session.
Encrypted DNS changes the path, not the need for trust
DNS over HTTPS and DNS over TLS encrypt communication between the client and the selected resolver. They can reduce local-network visibility, but the resolver still receives queries and remains part of the trust model. A browser-level encrypted-DNS setting can also bypass the resolver expected by a VPN or enterprise policy.
VPN, proxy, and browser differences
- Device-wide VPN: may capture system DNS, but implementation and split tunneling matter.
- Browser proxy: may route web traffic without changing operating-system DNS.
- SOCKS proxy: can resolve locally or through the proxy depending on the client and setting.
- Browser DoH: can select a resolver independently of the operating system.
- Split DNS: intentionally uses different resolvers for private and public names.
How to interpret a result
- Write down the DNS path you expect: ISP, VPN, enterprise, router, or chosen encrypted resolver.
- Run the test from the exact browser and network configuration you use.
- Compare resolver ownership and location with the expected path.
- Repeat after reconnecting and after changing IPv4, IPv6, browser, or VPN settings.
- Check whether browser-level encrypted DNS overrides the operating-system configuration.
- Treat multiple resolvers as a clue to investigate, not an automatic failure.
What a DNS leak test cannot prove
- That every future query will use the same resolver.
- That the resolver does not log or retain data.
- That the browser is anonymous.
- That application traffic follows the same route as DNS.
- That a provider’s published privacy policy matches every operational detail.
Aerod DNS test status
Aerod keeps the DNS Leak Test as a planned app until controlled authoritative infrastructure is available, session identifiers are handled safely, resolver observations are explained accurately, and the limitations are documented. The current browser leak workflow can still help users compare IP, WebRTC, browser, and route-consistency signals without pretending that those checks directly observe DNS resolution.
FAQ
What is a DNS leak?
In a VPN or privacy-routing context, it usually means DNS requests use a resolver path that does not match the route the user expected, such as the normal ISP resolver instead of the VPN’s resolver.
Does seeing a public resolver mean I have a leak?
Not by itself. A public resolver may be intentionally configured. The meaningful question is whether the observed resolver matches the user’s expected DNS path and threat model.
Can a website identify my exact DNS path?
Only with an appropriate test design. A credible test typically uses unique domains and controlled authoritative infrastructure to observe which resolver performed the lookup.
Why is Aerod’s DNS Leak Test still planned?
Aerod will not label the route as a working test until controlled resolver infrastructure can associate generated requests with observed DNS resolution and explain the limits accurately.