Where DNS Goes When You Combine Tor and a VPN

Two privacy tools are running, one page will not load, and a resolver test says something outside the browser received a name. Before that becomes a leak report, name the exchange it came from. A Tor plus VPN setup contains at least three different name lookups with three different owners, and walking through them in the order they happen is the quickest way to see which one is misbehaving.

Name Each Exchange Before You Call It a Leak

The first exchange resolves the VPN endpoint itself, and it happens before any protection exists. The second resolves a destination for Tor Browser, which can hand the name to the proxy instead of resolving it locally. The third covers everything else on the machine, including update checks, mail clients and the operating system's own service lookups. Only the first of those can happen without the other two being involved.

Each of those can follow a different path, and a single browser-based test observes only its own request. Treating one result as the state of all three is where most confusion starts.

Write down which names belong to which layer before you change anything. Private organizational names, a public destination and the tunnel endpoint itself do not carry the same requirement, and a policy that treats them as one category will break something.

The Bootstrap Lookup Happens Before the Tunnel

A client configured with a hostname has to resolve that name to open the tunnel, and at that moment the tunnel does not exist to carry the query. Whatever resolver the operating system offers on the current network answers it, which may be a captive portal, a hotel resolver or a public one. That is not a leak in the tunnel, because there is no tunnel yet.

Changing the browser's secure DNS setting does not touch this lookup either, since it belongs to a service that runs outside the browser and starts before any page is opened. If the endpoint name fails to resolve, no amount of in-tunnel policy will help, because the failure occurs one stage earlier than everything the configuration describes.

This is the one place where using a literal address for the endpoint, if the provider supports it, removes a dependency instead of adding one. It also removes the ability to follow a provider that rotates addresses, so the trade is real and should be decided rather than discovered.

The Browser and the Rest of the Machine Differ

Tor's SOCKS interface supports passing a destination hostname through to the proxy, which means the remote end performs the resolution and the local machine never asks. A generic application that supports a proxy may resolve the name locally first and then connect to the address it obtained, which produces a local query for a destination the user believed was proxied. The two applications can therefore leak in different places while sharing one proxy setting. Nothing in a shared proxy address tells you which of the two behaviours is in use.

Browsers add another layer when secure DNS is enabled, because the browser can choose its own provider and bypass the system resolver entirely. The tunnel client, meanwhile, may push a resolver through the tunnel for the whole machine. Those two settings can both be correct and still describe different behaviour for different programs.

Check the program that made the request rather than extrapolating from one test page. The distinction between a query carried inside the tunnel and one that never reached Tor is exactly the distinction a single resolver address cannot show.

Check Each Program, Then Compare With Intent

Run the observations separately: what the system would use, what the browser is configured to use, and whether the SOCKS connection carries a name or an address. That last one is the difference between remote and local resolution, and the SOCKS extension specification describes how a hostname is passed rather than resolved first.

resolvectl status | grep -E "Current DNS Server|DNS Servers"
ss -tnp '( dport = :9050 )'
dig +short dev.internal.example
getent hosts vpn-endpoint.example.net

Then compare what you observed with what you intended. A public name resolved through the tunnel by a resolver you chose is not the same finding as a private name handed to a public resolver during a fallback, and only the second one usually needs action. The first is a configuration working as designed, even if it looks unfamiliar in a report.

Record the exceptions you accept, including the bootstrap lookup that cannot be protected. An exception written down is a design decision, while the same exception discovered later looks like a defect. The person who finds it will treat it as one, and you will spend the meeting explaining why it is not.