Read a DNS leak test against your connection settings

To interpret a DNS leak test, compare the listed resolvers with your VPN and browser settings. A different company or country name alone doesn't establish a leak. First determine which service you expect to answer DNS requests. A browser with a custom secure DNS provider can produce a different result from the system configuration. Repeat the test under recorded conditions and compare the difference with your provider's documentation. An ordinary-looking result also cannot guarantee that every app uses the same route through every connection state. The result describes requests observed during that test.

What does the DNS server list actually show?

The result lists servers through which the test's DNS requests arrived. Keep those separate from your web connection's exit IP. DNS resolves a site's name into address information; connecting to the site is a separate step. The DNS answering service and web exit can therefore have different names.

DNSLeakTest's explanation of DNS leaks describes a system continuing to use its default DNS despite a VPN connection. It also discusses encrypted DNS in browsers. These are possible configurations to investigate. A server name in the results alone doesn't establish every part of the network path the request followed.

Check the expectation your VPN's documentation sets. Does it use its own DNS, allow custom resolvers, or specify a browser configuration? If the answer is unclear, mark the result for investigation. Avoid guessing who operates a resolver.

Record the browser's exit IP separately for comparison. These addresses have different roles. A mismatch alone is insufficient to establish a leak.

Which settings should you record before testing?

Record the VPN app and selected server, browser, network, and any custom DNS configuration. If your browser offers secure DNS, note its mode and selected provider too. Use those notes to compare the conditions of each test run.

Keep the current result first. If device policy permits, pause sensitive work and make a comparison with the VPN disconnected. Reconnect it before requesting a fresh test. Interpret matching or different server lists alongside the settings. A fixed custom DNS provider could appear in both runs; understanding that result requires knowing the intended route.

Treat a second browser as a separate comparison. Changing browser, network, and VPN server together obscures the cause of a difference. An old results page also cannot establish the state of a new connection without running the test again.

Use the setup instructions to match the starting configuration to your app. On a managed device, leave DNS and profile changes to the administrator. Deleting settings to produce a cleaner-looking result could break a connection the device needs.

How can secure DNS in the browser change the result?

A browser can resolve names through the secure DNS provider selected in its own settings. The resolver listed by the test may therefore be the browser's chosen service. DNS over HTTPS, or DoH, encrypts the name-resolution connection. The identity of the service receiving those requests still matters when evaluating privacy.

Google's Chrome security instructions for Android explain that automatic secure DNS can fall back to unencrypted resolution when a lookup fails. The same guide says that selecting a custom provider prevents this automatic fallback. Account for that specific distinction when interpreting a result. An enabled toggle alone cannot describe every operating mode.

The setting is called "Use secure DNS" in that guide. If you've assigned a provider there, seeing its name requires an explanation of that browser configuration. It doesn't establish that the VPN selected the resolver. Equally, encrypted DNS alone cannot prove the connection to that resolver traveled inside the VPN tunnel.

Check your VPN's compatibility guidance before disabling secure DNS. The purpose of the test is to understand the request path. Decide whether to change a protection after understanding which resolver receives the requests.

Can a country or company name prove a DNS leak?

Country and company labels help identify results that deserve investigation, but they cannot establish a leak alone. A familiar name also needs verification. Compare the resolver's identity with the provider documented by your service or custom configuration. A displayed location cannot describe the full packet route.

ObservationSupported interpretationNext checkBrowser's custom DNS provider appearsBrowser settings may be involvedMatch the selected providerInternet provider's name appearsDNS routing needs investigationCompare with documented VPN behaviorAn unfamiliar company appearsResolver identity remains unclearGive support the IP and test timeServer list stays emptyThe test produced no interpretable resultRun again and inspect browser errors

If several servers appear, don't use their count alone as a security verdict. Apply the same question to each entry: does the expected configuration explain this resolver? Avoid inventing a fixed acceptable server count.

Give support the observed IPs and test settings. A country name alone leaves too little information to investigate resolver identity. Confirm the result in a fresh run so that an old page doesn't become the basis for a configuration decision.

Which parts of the connection remain untested?

A browser test reports on requests made by that test. Other apps, a VPN disconnect, and IPv6 behavior need separate investigation. A result without unexpected resolvers cannot establish kill-switch behavior during a failure or guarantee coverage across the device. Keep the conclusion within the conditions actually examined.

The OpenVPN 2.6 manual illustrates why scope matters. Its Windows-specific --block-outside-dns option restricts TCP and UDP access to port 53 outside the tunnel. That description alone does not establish coverage of every form of encrypted DNS. Keep claims about a setting within its documented behavior.

If IPv6 is active on your connection, check the provider's support and an appropriate test separately. Missing IPv6 results in one tool cannot establish the state of every route on the device. A DNS result also makes no assessment of malware, phishing pages, or account security. The explanation of VPN protection limits helps keep those questions separate.

What should you do about an unexpected resolver?

Save the settings and result, then compare them with the provider's documentation. If you expect DNS to follow the VPN's documented route and a different resolver appears, postpone sensitive work on that connection until the discrepancy is explained. Randomly changing several controls tends to destroy useful diagnostic context.

Include resolver IPs, browser name and secure DNS mode, selected VPN server, and test time in your support request. Explain whether the result also appears with the VPN disconnected. Redact account or personal details before sharing screenshots. A password or private connection key is unnecessary for explaining the test result.

ZibalVPN users can send these observations through support. After a recommended change, retest using the same browser and network, then keep the new result beside the revised configuration.