Your VPN DNS Fallback: Where the Query Really Goes

A resolver setting flips from the private address to a public one, and the conclusion arrives immediately: the tunnel is leaking. Sometimes it is. Often the fallback query still travelled inside the tunnel to a resolver the administrator chose, which makes it a policy decision rather than a defect. Separating those cases takes three facts rather than one, and the first of them is who answered. Find out who received the query, which route carried it, and which names were asked for.

Fallback Is a Policy, Not a Single Behaviour

Every client has to decide what to do when the preferred resolver stops answering. It can block resolution, retry, use a configured alternative, or defer to the operating system, and those are four different products from a privacy point of view. Reading the setting screen tells you which behaviour is configured; it does not tell you which one occurred. A screen that offers one switch is not describing four possibilities.

Browsers add their own layer. A browser with secure DNS enabled can resolve a name through its own chosen provider even when the operating system points elsewhere, which means the tunnel client's policy may never be consulted for the requests you actually care about. Check the application that made the request, not only the system setting.

The identity of the replacement resolver is the first fact worth establishing. A public resolver that belongs to a provider you already trust is a different situation from an address supplied by the network you happen to be on. The address itself rarely tells you which of those you are looking at.

Who Receives the Query After the Switch

The recipient and the route are independent, and only their combination describes the exposure. A public resolver reached through the tunnel never sees your access network address, while the same resolver reached directly does. Both cases produce an answer, and a leak test that only reports the resolver address will describe them identically. Ask for the interface as well as the address when you read the result.

Internal names make the distinction concrete. A public resolver usually cannot answer a split-horizon name, so the query fails while the name has still been disclosed to a party that had no business seeing it. Availability and privacy therefore move together here rather than trading off.

A tunnel can also carry the query to a resolver that is not operated by the VPN provider, because the tunnel forwards rather than resolves. The forwarding host sees the plaintext query and then opens its own connection onward, which protects the next hop without protecting the first one.

Check the Route and the Recipient Together

Observe the packets rather than the configuration. Ask the system which resolver would be used, then confirm that the query actually left from the expected interface to the expected address.

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

If the capture shows the query leaving the physical interface while the tunnel is up, the fallback bypassed the tunnel regardless of what the resolver list says. If it appears on the tunnel interface, the question becomes who operates the far end and what it retains.

Repeat the check for one internal name and one public name. The internal query is where a fallback configuration usually reveals itself, because a resolver that cannot answer still receives the question.

Decide Whether the Fallback Should Be Allowed

If the requirement is that resolution stops when the preferred resolver is unavailable, configure an enforcement policy that fails closed and accept the consequence: names will not resolve during an outage. That is a deliberate availability trade rather than a malfunction, and the design should say so before the outage happens.

If the requirement is only that queries must not travel outside the tunnel, a public resolver reached through the tunnel can be acceptable provided the operator and its retention policy are understood. That acceptance is a judgement about a third party rather than a statement about cryptography, and it belongs to whoever owns the privacy claim. If internal names must keep working, the fallback has to be a resolver that holds the internal zones, which usually means the fallback target is a different server rather than a different address family.

Document the outcome as a sentence about behaviour: which resolver receives queries in normal operation, which one receives them after a failure, and whether internal names resolve in the second case. A leak test that eventually loads a page proves less than that sentence, because a page can load through a resolver that should never have been consulted.