DNS leak tests: what an unexpected resolver means

Quick answer: An unexpected name in a DNS leak test tells you which resolver the test observed, not automatically whether a query escaped your VPN tunnel. First write down which resolver you intended to use. Then check the browser’s DNS-over-HTTPS setting, the VPN’s DNS setting and any custom or managed DNS policy. Compare the same test with the VPN off and on, and try a second browser before changing settings. A failed test page is inconclusive, not proof of safety or exposure.

Important constraint: A browser-based DNS check samples that browser and that test path. It does not show how every desktop app resolves names, whether every packet used the VPN, or what happens during a tunnel interruption. A VPN IP-address badge answers a different question: the apparent exit address of that web request. Keep DNS-resolver diagnosis separate from kill-switch testing. Sources: Mozilla DNS-over-HTTPS guidance, Mullvad DNS guidance.

DNS turns a name such as a website address into information an application can use to connect. The device, browser, VPN and network may each influence which resolver is asked. Encrypted DNS protects the DNS exchange between the client and its resolver according to its configuration; an encrypted VPN tunnel carries network traffic through a VPN path. They can operate together, separately or in conflicting configurations. The label reported by a test is a starting observation, not the full story of that path.

Set the expectation before interpreting the result

Write down the resolver you expect for this device and browser in this mode. If the VPN is configured to supply DNS, you may expect its resolver. If you deliberately selected a browser DNS-over-HTTPS provider, the expected name may be that provider even while the VPN is connected. If an organization manages DNS policy, the expected resolver may be set by its administrator rather than by the VPN app. An unspoken expectation creates false alarms and false reassurance.

Use a five-column note for every observation. It is small enough to fill in while testing and specific enough to compare after changing one setting.

The rows are diagnostic cases, not results from a particular VPN or computer. The first row shows the expected resolver for that check. The second may be entirely intentional; a third-party name alone cannot tell you whether its encrypted DNS connection went through or around the VPN. The third warrants investigation, especially if you did not configure the ISP resolver. The fourth gives no usable resolver observation.

Mullvad’s DNS leak article describes a connection check that treats a resolver outside Mullvad as a leak under its own expected setup. That is useful for someone who intended Mullvad’s DNS path. It should not be universalized into “any third-party resolver is a leak” for a person who intentionally uses another resolver. The service may also fail, and a failed check should not be translated into a clean result.

Check the browser’s DNS behavior

Browsers can resolve names through their own DNS-over-HTTPS setting rather than relying solely on an operating-system resolver. Firefox, for example, documents Default, Increased, Max and Custom protection modes in Mozilla’s current guidance. Default can fall back to ordinary DNS under described conditions and can respond to VPN, enterprise or parental-control settings; Max has a different failure behavior. Do not generalize one Firefox mode’s fallback to every browser or even every Firefox configuration.

Open the browser’s DNS setting and record its actual mode and selected provider. If the browser says “Default,” avoid assuming it means “always VPN DNS” or “always browser DoH.” Compare the observed resolver with the mode’s documented behavior. A Custom setting is especially important: a test may correctly display the custom provider even if the user expected to see the VPN brand. If an enterprise policy manages the setting, do not override it just to change the test result; ask the administrator what is intended.

Try the same resolver test in a second browser with its settings recorded. If the two browsers disagree, compare their DoH modes and custom-provider settings before changing the VPN.

Run a reversible baseline-to-VPN comparison

First note the ordinary network and browser configuration before connecting the VPN. Record the test time, browser and version, DoH mode, any custom DNS setting, and the resolver the test reports. A baseline helps you recognize an ISP resolver later, but it is not automatically the only possible non-VPN path. Do not publish the log if it includes account, network or identifying details.

Connect the VPN in the mode you actually intend to use and repeat the same browser test. Record the VPN app’s connection status and its DNS settings. Compare the resolver label with your expected value from the worksheet. If it differs, use the second browser and check whether the difference follows the browser configuration or appears across both. Keep the test network and other settings stable where possible so you are changing one variable at a time.

Next, select one reversible setting whose behavior you understand from its vendor documentation—perhaps the browser DoH mode or an intentionally configured custom resolver. Change it only if you are authorized to do so and it does not undermine a managed policy. Retest, note what changed, and restore the intended configuration afterward. Do not blindly disable encrypted DNS, uninstall security software or permanently alter enterprise controls to make a diagnostic page display a preferred brand name.

If a test repeatedly shows an unexpected ISP or unfamiliar resolver, investigate where DNS is configured at the browser, operating system, VPN and network layers. The observed name can narrow the search. If the result has material privacy implications for your work, use the VPN or OS vendor’s support path with the recorded settings and timestamps rather than treating a single screenshot as a complete audit.

When a test page fails to load or reports no resolver, separate the test service from the connection. Check whether an ordinary permitted web page loads, whether the VPN app reports connected, and whether the same DNS page works later or from a second browser. A failed page could reflect its own outage, a blocked test technique or a local connectivity problem. Do not replace a missing result with the last successful resolver label; note the failure and time, then repeat under a known configuration. That record prevents a troubleshooting session from producing a confident conclusion based on stale output.

Separate resolver identity from network path

Two questions often get mixed: “Which resolver answered?” and “How did the DNS request reach it?” A test that displays a third-party resolver is primarily evidence about the first. The second may require configuration records or more detailed network observation. A deliberately chosen encrypted resolver can appear by name while its traffic travels inside a VPN tunnel; conversely, an expected resolver name in a browser test does not prove no other app sent DNS elsewhere.

The VPN exit-IP check is a third question. A page showing the VPN’s public IP suggests that page request used the VPN egress at that moment. It does not show the resolver for all names and does not test what happens if the tunnel drops. Keep these results as separate lines in your log: apparent web egress, observed DNS resolver, browser mode and VPN state. If you later test a kill switch, do it as a controlled interruption with its own evidence, not by reading the DNS page as a substitute.

This distinction matters especially with a browser’s DoH feature. It can have its own fallback and provider selection, while the operating system and other applications use different settings. Mozilla’s documented modes demonstrate why there is no single behavior to infer from the words “DNS over HTTPS enabled.” Mullvad’s troubleshooting advice about browser DoH applies to the configuration it is diagnosing; it is not a general instruction that a more private result always requires disabling browser encryption.

Decide what the result justifies

If the observed resolver matches your configured expectation, record a limited match for that browser and moment. If it shows a deliberately selected browser DoH provider, decide whether that was your intended DNS arrangement; the provider label alone is not an escape-path verdict. If it shows an unexpected ISP resolver, check the browser, VPN and managed settings in order and seek more evidence. If the test fails, repeat or use another trusted observation route before drawing any conclusion.

Keep the worksheet after an app, browser or operating-system update, because settings and fallback behavior can change. Record a fresh result on the configuration you actually use, not a temporary diagnostic setup. If the resolver changes after an update, repeat the comparison with the saved settings before changing VPN providers. The privacy hub covers related VPN choices.