DNS Leak Test: A Resolver Name Is Not the Route

Three arrangements count as correct DNS for a VPN user: queries to the operator's resolver, queries to an encrypted resolver you chose, and split DNS that sends work names to the organization. A leak test reports a resolver, and that single label cannot tell you which arrangement you actually have. Decide the intended policy first, then test against it. Otherwise you are comparing a number against a feeling.

Decide What You Wanted Before You Read the Result

Name the policy in one sentence: all names to the VPN resolver, all names to a chosen encrypted resolver, or split DNS with internal names going to the organization. Each is defensible for a different user, and each produces a different expected answer. Without that sentence, any result that differs from a screenshot in a forum post looks alarming. Write the policy down before the first test.

A test performed before the policy is defined measures nothing. It produces a resolver name with no reference point.

A Resolver Name Proves Neither Path nor Recipient

Two questions matter: who received the query, and which route carried it. A third-party resolver can be reached through the tunnel while a settings screen shows the provider's address. The label on a leak-test page describes the observer's view, not your routing table.

A browser can use its own encrypted DNS while site traffic goes through the tunnel, and cached answers can let a page load without a fresh lookup. That is why a public-IP result says nothing about DNS. DoH and DoT protect the query in transit to the resolver, and that resolver still sees the names.

resolvectl status
resolvectl query example.com
dig +short example.com

Split DNS Makes Multiple Resolvers Correct

An organization may send internal names to its own DNS and everything else elsewhere. A test that lists several resolvers can therefore be describing the intended policy rather than a fault. Compare the observed set with the documented split-DNS rules before disabling anything. Turning off the internal resolver to make a test page look cleaner breaks private names.

Split tunneling and split DNS are different choices: one routes packets, the other routes questions. Changing a tunnel route does not move a name lookup, and changing the resolver does not fix a website path. IPv6 is a third question, since an unintended IPv6 connection is not automatically a DNS leak.

Turn the Result Into an Investigation

Record the intended policy and the browser's secure-DNS setting before testing. Run the test with the tunnel active, note every resolver it names, and compare the set with the policy rather than with a single expected address.

Repeat after a reconnect if that is when the symptom appears, because a policy applied at connect time can be lost later. Use the client's documentation for internal DNS exceptions instead of guessing at the settings.

Fix the mismatch you found: a browser choice, a VPN DNS setting or a split-DNS rule. If queries must stop when the tunnel fails, the kill switch is a separate setting, and DNS configuration alone will not supply it. The RFC 8484 specification is useful when you need to explain what an encrypted resolver does and does not hide.