Why a DNS Country Label Does Not Prove a VPN Leak

Foreign-looking resolver addresses show up in DNS test results constantly, and the conclusion people draw is always the same: the queries must have escaped the tunnel. Sometimes they did. More often the report describes which recursive service answered and where a database thinks that address sits, which is a statement about infrastructure rather than about your packets. Separating the observation from the inference takes three facts: who replied, how the name travelled, and what policy you actually configured.

Read What the Test Actually Observed

Most test pages work the same way: they ask the client to resolve a unique hostname and then look up which resolver fetched it, or they simply echo the resolver address the client reports. That identifies a recursive service and, if the query carried client subnet information, a rough network location. It does not prove that the query left the device outside the tunnel, and it certainly does not prove that the same path was used for every name. A single observation of one lookup is being generalised into a claim about all traffic.

A test that shows the resolver address is more useful than a country badge, because an address can be compared with the resolver list the client actually received.

Anycast and Forwarding Explain Most Surprises

Large public resolvers announce the same address from many locations, and the network routes each query to whichever site is nearest in routing terms. A geolocation database then maps that address to a single location, which may be a corporate registration address on another continent or a data centre that is not the one answering. RFC 4786 covers operational practice for anycast services and the difficulty of associating such an address with one physical place. The map is a simplification of a routing decision, and it simplifies in the direction that produces alarming results.

Forwarding adds a second layer. A local stub resolver, a router or an ISP resolver may pass queries to an upstream service, and the name that appears in the test reflects the last operator in that chain rather than the first. Client subnet extensions can make an upstream answer tailored to your network while making the reported location look like somewhere you have never been.

A configured resolver can therefore be correct and still produce a foreign-looking result, and a resolver in your own country can still be the wrong one because it belongs to a party you did not choose.

Who Received the Name, and by Which Route

Two questions answer the practical part: which server does the client use, and is that server reached through the tunnel. Compare the resolver list with the address in the test result before drawing conclusions about routing, then check that the query to that address leaves through the tunnel interface. If the two addresses differ, the interesting finding is that something rewrote or bypassed the intended resolver, which is worth a closer look than the country name.

resolvectl query example.com
resolvectl status | grep -A3 'DNS Servers'
dig +short TXT whoami.akamai.net

The first command shows which server answered for a name, the second shows the configured list and its scope, and the third reports the resolver address as seen by a public service. When all three agree, the policy is doing what it was configured to do, whatever the country label says.

Compare Against the Policy You Chose

A VPN that pushes a resolver, a browser configured to use its own encrypted DNS, and an operating system that prefers one interface's settings can all be correct individually while conflicting collectively. Modern browsers may send queries over an encrypted transport to a provider chosen in the browser, which deliberately bypasses the system's resolver list. That is not a leak in the sense of a broken tunnel; it is a policy selected somewhere else, and finding where it was selected is the actual task.

Work devices add domain-specific rules: internal names must go to the organizational resolver while everything else follows the default. Replacing that arrangement because a test page showed an unexpected country is how internal names stop resolving for an entire team.

Keep Tests Narrow and Safe

Querying a public test service for an internal hostname discloses the name to a party with no business seeing it, and the answer tells you nothing that reading the resolver list locally would not.

Use names that reveal infrastructure instead, record the resolver address, the scope and the interface used, and compare that record with the documented intent. A map label is context for a conversation rather than a pass or fail result, and treating it as a verdict produces configuration churn in place of diagnosis.