ENA DNS leak test identifies the resolver infrastructure handling DNS queries from your browser. It shows the providers and locations involved in those lookups. You can then compare the result with the DNS path you expected from your VPN, proxy, or chosen DNS service.
The result page can look alarming. A long list of unfamiliar IP addresses does not prove that something has leaked. The useful question is simple. Did any DNS request go somewhere it was not meant to go?
| Quick Check | What to Look For |
|---|---|
| Likely Pass | Only Approved VPN, Proxy, or Chosen DNS Providers Appear |
| Likely Leak | Your Local ISP Resolver Appears When Another Resolver Was Expected |
| Partial Leak | Both the Approved Resolver and the Local ISP Resolver Appear |
| Needs a Closer Look | An Unknown Provider Appears or No Resolver Is Detected |
What Is a DNS Leak Test?
DNS translates a domain such as example.com into an IP address that a device can use. A DNS resolver handles that lookup. Most people use a resolver supplied by their ISP unless a VPN, browser, router, or custom DNS service changes it.
A DNS leak happens when a query reaches a resolver outside the path you intended to use. This matters most when a VPN or proxy is supposed to keep the local ISP out of the lookup process.
The word leak needs context. If you are browsing without a VPN and expect to use your ISP DNS, seeing that provider is normal. If you connect to a VPN that should manage DNS and your local ISP still appears, the same result now points to a problem.
I would not judge a test until I know what the expected resolver is. Without that baseline, a green badge or a red warning is only the test site giving its best guess.
How Does a DNS Leak Test Work?
An online test creates domain names that have not been requested before. Your browser tries to resolve them. The requests pass through the DNS path selected by the browser, operating system, VPN, or proxy.
The process usually looks like this:
- The test creates several unique hostnames.
- Your browser triggers a lookup for each hostname.
- A recursive DNS resolver handles or forwards the request.
- The test domain records the resolver infrastructure that asks for the answer.
- The test page maps those addresses to a provider, network, and location.
The page does not always show the exact DNS address in your device settings. A public provider may use many servers. Requests may also pass through a forwarding resolver. Provider and location databases can be wrong too. The test still gives you useful evidence. It just needs interpretation.
How to Run a DNS Leak Test Correctly
A useful test starts before you connect the VPN or proxy. That first result gives you something real to compare against.
- Disconnect the VPN or proxy.
- Run the test and record the resolver provider, ASN, and country.
- Record your visible public IP as well.
- Connect the VPN, proxy, or browser profile you want to test.
- Open a fresh test page and run the check again.
- Compare the new resolver set with the original baseline.
- Repeat the extended test if the first result is unclear.
Change one thing at a time. If you change the proxy, browser DNS, and VPN protocol together, you may never know which change fixed the problem.
After the DNS check, run a broader BrowserLeaks IP and fingerprint test. Keep the results separate in your notes. Clean DNS does not prove that the public IP, WebRTC behavior, or browser settings are also correct.
The test operator will see your connection IP and the resolver requests made for the test. Check its privacy policy. Do not install an unknown extension just to see a DNS result.
Standard vs Extended DNS Leak Tests
Many tools offer a quick test and a longer test. DNSLeakTest.com calls them Standard and Extended. Other services may use different names and a different number of queries.
| Test Mode | Best Use | Main Limit |
|---|---|---|
| Standard | A Quick Check after Connecting | It May Miss a Resolver That Appears Only Sometimes |
| Extended | A Wider Sample of Resolver Activity | It Takes Longer and Still Tests Only the Current Session |
On DNSLeakTest.com, the Standard test uses six queries and the Extended test uses 36. BrowserLeaks currently tries 50 random hostnames. Half use IPv4 only and half use IPv6 only. These numbers describe each tool. They are not an industry standard.
How to Read DNS Leak Test Results
Start with the provider column. Then check the ASN or network owner. Look at the country after that. The number of IP addresses comes last.
This order matters. Five addresses owned by one approved provider may be less concerning than one address owned by your home ISP.
| Result | Likely Meaning | What to Do Next |
|---|---|---|
| Only Approved Resolver Infrastructure Appears | The Observed Queries Followed the Expected Setup | Check IP and WebRTC Separately |
| Approved Resolver and Local ISP Resolver Both Appear | Some Queries Used Another Path | Review Browser DNS, Split Tunneling, IPv6, and Fallback Behavior |
| Only Local ISP DNS Appears While a VPN Is Active | The VPN Did Not Handle the Observed DNS Requests | Check the VPN Client and Its DNS Protection Settings |
| Google, Cloudflare, or Quad9 Appears | A Public or Secure DNS Service May Be Active | Confirm Whether You Selected That Provider |
| Several IPs Belong to One Approved Provider | The Service Uses Several Resolver Exits | Usually No Action Is Needed |
| An Unknown Provider Appears | A VPN Partner, Upstream Resolver, or Unexpected Service May Be Involved | Check Provider Documentation and Test Again |
| No Resolver Appears | The Test May Be Blocked or Incomplete | Retry with Another Tool or an Extended Test |
When Your ISP Appears
Seeing the local ISP is the clearest warning when a VPN was expected to manage DNS. If it appears beside the approved VPN resolver, treat the result as a partial leak. Some lookups followed the intended route and others did not.
When Google or Cloudflare Appears
Public DNS is not automatically a leak. You may have selected Google, Cloudflare, or Quad9 in the browser or operating system. That provider can still handle your queries. If your VPN claims to use only its own DNS, investigate the result.
When Several DNS Servers Appear
Several resolver IPs can be normal. Large DNS services balance requests across many servers. Group the results by provider and ASN. Then ask whether each organization belongs in the setup.
When the Country Looks Wrong
A DNS server does not have to sit in the same city as the VPN exit. Public resolvers use distributed infrastructure. VPN providers may use partners. Location databases may also be wrong. A country mismatch is worth checking, but network ownership tells you more than a city label.
What a DNS Leak Test Cannot Prove
A clean resolver list answers one narrow question. It shows which resolver infrastructure handled the queries observed during that browser test.
It does not show whether ordinary DNS traffic was encrypted. It does not tell you whether the resolver keeps logs. It cannot prove that every app on the device uses the same DNS path. It also says nothing about what happens after the VPN disconnects or the network changes.
Browser Secure DNS adds another layer. DNS over HTTPS encrypts traffic to the selected resolver. It may also use a resolver that differs from the operating system. A DNS leak test can identify that resolver. It cannot prove that the encrypted request traveled inside the VPN tunnel.
The difference between a proxy, VPN, and antidetect browser matters here. Each one controls a different part of the connection or browser environment. A pass in one layer does not clear the others.
What to Do If Your DNS Is Leaking
Do not start by changing every network setting. Confirm the result first.
- Run the test again with another reputable service.
- Check whether the same local ISP appears in both results.
- Review DNS leak protection in the VPN client.
- Check browser Secure DNS and any custom DNS provider.
- Review full tunnel and split tunnel settings.
- Check whether IPv6 follows the same protected route.
- Reconnect the VPN or proxy and test again.
Clearing the DNS cache can remove old answers. It does not repair routing. Changing to a public resolver also does not guarantee that the request stays inside a VPN or proxy path.
If the leak continues, save both results. Include the provider, ASN, browser, operating system, and VPN protocol. That gives support teams useful evidence.
DNS Leak vs IP Leak vs WebRTC Leak
These tests often appear together. They do not measure the same thing.
| Test | Main Signal | What an Unexpected Result May Reveal |
|---|---|---|
| DNS Leak Test | Resolver Infrastructure | Domains or Services Requested through an Unintended Resolver |
| IP Leak Test | Public Connection Address | Network Origin and Approximate Location |
| WebRTC Leak Test | Browser Connection Candidates | An Unexpected Local or Public IP Address |
If browser connection candidates are the concern, run a separate WebRTC leak test. That test does not identify the resolver that handled a DNS query.
The same boundary applies to a browser fingerprint. It combines browser and device signals such as the user agent, timezone, fonts, Canvas, and WebGL. Fixing DNS does not change them.
DNS Testing for Proxies and Browser Profiles
A proxy can show the right public IP while DNS follows another path. The profile looks ready at first, then a second test tells a different story.
Proxy DNS behavior depends on the protocol, browser, client, and provider. Do not assume that every HTTP or SOCKS connection resolves names in the same place.
When setting up a profile, I use this order:
- Set up the proxy in MoreLogin.
- Confirm that the visible public IP belongs to the expected proxy.
- Run a DNS leak test and compare it with your approved provider set.
- Run a separate WebRTC test.
- Check timezone, language, and geolocation consistency.
- Test the profile again after a proxy or network change.
MoreLogin also documents how to add and edit self owned proxies. Once the proxy is assigned, the live test shows how the browser and network behave together.
In a multi account browser, each profile keeps its own proxy settings, cookies, storage, and browser configuration. That separation makes review easier. It does not replace network testing.
Conclusion
A DNS leak test replaces a guess with something you can inspect. The hard part is reading the result without overreacting to every unfamiliar address.
Define the expected resolver first. Check provider ownership before location. Treat several IPs from one approved service as a normal possibility. If the local ISP appears outside the plan, investigate it.
One clean result is a snapshot, not a lifetime certificate. Test again when the proxy, VPN, browser, network, or DNS setting changes.
DNS Leak Test FAQ
How do I know if my DNS is leaking?
Record the resolver used without the VPN or proxy. Connect and test again. If the local ISP still appears when another resolver was expected, the setup likely has a leak. If both appear, it is usually a partial leak.
Can a proxy leak DNS?
Yes. A proxy may route browser traffic while DNS follows another path. The result depends on the protocol, browser, client, and DNS policy. Test the setup instead of relying on the proxy label.
Can DNS over HTTPS prevent a DNS leak?
DoH encrypts DNS traffic between the browser and the selected resolver. It does not guarantee that the resolver follows your VPN policy. It also does not prove that the encrypted request traveled inside the VPN tunnel.
Does a clean DNS result mean the VPN is fully protected?
No. The result covers DNS queries observed during that test. Check the visible public IP, IPv6, WebRTC, and connection behavior separately. A VPN can pass one test and still have a problem elsewhere.
Is a DNS leak test safe?
A reputable browser based test is generally low risk. The service will see the connection IP and resolver activity needed for the test. Avoid tools that ask you to install unknown software or enter account details.
When should I run the test again?
Retest after changing a VPN server, proxy, browser, network, operating system, Secure DNS setting, or IPv6 configuration. Also test after an update that changes network behavior.
Check Each Profile before You Rely on It
A clean proxy connection is a good start. It is not the whole check. Review the visible IP, DNS resolver, WebRTC behavior, and browser settings before the profile is used for important work.
Try MoreLogin Free to keep proxy settings and browser data organized in separate reusable profiles.
