Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.
What Is a DNS Leak? How to Test and Fix It
Ryan Foster
October 5, 2026· 10 min read
A DNS leak occurs when a name lookup follows a path outside the protection you intended to apply. To diagnose a DNS leak, compare the expected DNS policy with observed requests; a different resolver name or country alone does not prove that queries bypassed your VPN.
Key Takeaways:
- Resolver identity, query route, and DNS encryption answer different questions.
- Compare disconnected and connected results on the same device and browser.
- Browser secure DNS can use a different resolver without necessarily leaving the tunnel.
- Change one setting at a time, restore failed changes, and retest both browsing and DNS.
What does a DNS leak reveal about the query path?
DNS translates a name into information an application needs to connect. Your system can send requests to a router, a network-supplied resolver, or a configured service; a browser can also choose its own resolver. The important question is which path those requests take relative to the policy you meant to enforce.
A VPN exit address identifies where a particular connection reached a website. It does not identify every DNS request made by the device. Dual-stack routing and other interfaces can create a path around a tunnel, so a working web connection is not sufficient evidence of complete coverage.［1］
The diagram separates a lookup sent through the VPN from a lookup sent directly over the access network. It is a generic routing model, not a capture of a provider or evidence that either path is active on your device. You must compare the model with the configured policy and actual observations.
| Question | Useful evidence | What it cannot establish alone |
|---|---|---|
| Who answered? | Resolver operator or observed server address | Which device-side route carried the lookup |
| Where did it travel? | Authorized route or packet observations | Whether the resolver retains logs |
| Was DNS encrypted? | Documented DoH or other secure DNS configuration | Whether traffic used the VPN |
| Did the page connect? | Exit address and successful request | Coverage of all lookups and applications |
What do you need before a DNS leak test?
Write down the policy you expect: for example, all tested browsing should use the VPN, while an employer-managed configuration may intentionally resolve internal names elsewhere. Record device, operating system, VPN app version, browser version, active adapters, and browser secure DNS settings. A deliberate exception is a policy choice to evaluate, not automatically an accidental leak.
Only change a network or device you are authorized to manage. On work equipment, ask the administrator about internal domains and resolver requirements; replacing corporate DNS can break access without improving privacy. Close sensitive sessions and preserve the original settings before experimenting.
Use a diagnostic that explains what it measures and can generate fresh lookup names. Cached replies may produce no new query, which can confuse a comparison. An ordinary resolver test commonly observes the recursive resolver that contacted its authoritative server, not a complete capture of the route from your laptop.
How can you compare the VPN and DNS results?
- Save the baseline. With the VPN disconnected on a trusted network, use the same browser to record its secure DNS mode and the diagnostic's resolver results. Check the current exit address and record time and network. Keep exact addresses private when sharing the record.
- Establish the connected comparison. If using AethoVPN for this comparison, select a currently available location, connect, and check the exit again before repeating the DNS observation. This establishes a VPN-connected reference for the web request; it does not establish that every DNS query used that path. On iPhone, iPad, or Mac, configuration requires Pro or Premium.［3］ Create an account for the 3-day Pro trial if you need to establish that comparison; trial eligibility is once per user.［3］
- Repeat fresh lookups. Use the same diagnostic and a fresh test session, keeping the network and browser constant. Save the resolver operator, addresses, time, and any reported uncertainty. Repeat if the service returns an error rather than treating an empty list as a pass.
- Compare browser and system configuration. Check whether secure DNS is set in the browser, whether the operating system has a manual resolver, and whether another adapter or proxy is active. Record differences before changing anything. The browser can bypass the system resolver while its HTTPS DNS connection still follows the tunnel.［2］
- Validate the suspected route. If results contradict the intended policy, consult the VPN's documentation or support. On your own device, an authorized route inspection or packet capture can strengthen the diagnosis; a resolver's country label cannot replace that evidence. Do not capture other users' traffic or disclose raw logs publicly.
- Apply one narrow correction and retest. Restore an unintended manual setting to the documented configuration, or align browser DNS with the policy you actually want. Restart the relevant application if its documentation requires it and repeat the same observations. If internal resources fail or the cause remains unclear, restore the previous value and escalate.
For a wider health check, use the complete connection-testing workflow. It complements this DNS-specific comparison; it does not turn a resolver list into proof of every route.
How should you interpret a DNS leak test result?
A resolver matching your access provider is a reason to investigate when you expected VPN-controlled resolution, especially if fresh queries still use it after connection. It is not conclusive alone: a service might intentionally use an external resolver, or the browser may have a separate secure DNS endpoint. Compare the result with documented behavior and route evidence.
Likewise, a resolver associated with a large public DNS service is not inherently safe or unsafe. The same operator can be reached through the tunnel or directly. Multiple resolver addresses can reflect load balancing or different query paths; you need more context before assigning a cause.
| Observation | Possible explanation | Next action |
|---|---|---|
| Same resolver before and after | Deliberate external resolver, browser DNS, or bypass | Compare policy and inspect the actual route |
| New resolver after connection | Configuration changed or VPN resolution applied | Confirm route; do not infer full device coverage |
| Different resolver country | Infrastructure placement or geolocation database | Focus on operator and policy, not the flag |
| No resolvers returned | Diagnostic error, caching, filtering, or no new queries | Repeat fresh lookups and verify browsing |
| Browser and other apps differ | Separate DNS settings or application paths | Test each relevant application independently |
A DNS leak test is therefore a diagnostic input, not a binary privacy certificate. Record “route confirmed,” “policy mismatch,” or “route uncertain,” together with how you reached that conclusion. A result can be acceptable for one deliberate policy and unacceptable for another.
How can you fix a DNS leak without breaking the network?
Start with configuration you can explain. Check for an old manual resolver, stale VPN adapter settings, a second active VPN, or a browser-specific override. Follow current documentation for your operating system rather than copying commands that clear routes or overwrite adapter settings indiscriminately.
Do not present “use a public DNS server” as a universal repair. That changes the recipient of a lookup, not necessarily its transport path. DoH sends DNS over HTTPS, but encryption of that connection does not prove it travels through your VPN. The resolver still processes the query, and the outer VPN connection remains a separate visibility issue.［2］ See what encrypted DNS does and does not hide.
If the suspected bypass uses a different address family, continue with the IPv6 coverage checks. If the original public address appears in a browser media diagnostic rather than in resolver observations, use the WebRTC candidate guide. Mixing these symptoms can lead you to adjust DNS while leaving the real cause untouched.
Do not disable IPv6, remove every network adapter, or install an unknown extension as the first response. Each can introduce a new failure and obscure the original observation. If you cannot identify a supported correction, stop changes, retain the baseline and comparison, and ask the administrator or provider for the intended DNS path.
When is the retest complete?
A useful retest reproduces the original conditions after the documented correction. Check fresh DNS queries, ordinary page access, and any internal resource you require. Restore normal browser use and repeat after a routine reconnect so that a transient result does not become your only evidence.
Keep a short record of the setting changed, original value, corrected value, observed resolver, route evidence, and recovery outcome. If the result remains uncertain, label it that way; do not use an exit IP change as a substitute. Review the trial acceptance worksheet before making a purchase based on the diagnosis.
If the device is managed, a correction should end at the approved configuration rather than your personal preference. If browsing fails after a change, restore the recorded value before trying another fix. For the broader relationship between routing and privacy, use the VPN foundations overview.
Summary
- Decide which DNS path your configuration is supposed to enforce.
- Compare fresh disconnected and connected observations without changing several variables.
- Treat operator, country, encryption, and route as separate evidence.
- Make one supported correction, verify recovery, and keep uncertain conclusions explicit.
FAQ
Is an ISP resolver always a DNS leak?
No. It may be inconsistent with your expected policy, but you need the documented configuration and route evidence to establish that queries bypassed the tunnel.
Can secure DNS still travel through a VPN?
Yes. A browser's HTTPS connection to a DoH resolver can use the VPN route even when that resolver differs from the system resolver.
Does a foreign resolver country prove a leak?
No. Country labels can reflect infrastructure or geolocation data. Identify the operator and expected route instead of drawing a conclusion from a flag.
Should I switch to public DNS immediately?
Not as a universal fix. It changes who resolves the name, but without a routing check you have not established where the query travels.
Why does a test return no DNS servers?
It may be a diagnostic failure, caching, or filtering. Repeat fresh lookups and confirm that the diagnostic actually generated requests before treating it as useful evidence.
Can DNS tests detect WebRTC address exposure?
Not reliably. Resolver observations and browser media candidates describe different mechanisms, so diagnose the original public address with a WebRTC-specific comparison.
What if a fix breaks work resources?
Restore the original recorded setting and stop further changes. Ask the administrator about internal resolver requirements instead of replacing managed configuration on your own.
Disclaimer: This workflow is for devices and networks you are authorized to manage. Observations apply only to the recorded configuration and do not establish anonymity.
Sources
- RFC 7359 — Layer 3 Virtual Private Network Tunnel Traffic Leakages in Dual-Stack Hosts/Networks
- RFC 8484 — DNS Queries over HTTPS
- AethoVPN — Official website
Sources checked 5 October 2026.
