Private DNS vs VPN: What Each One Actually Covers

Your phone has Private DNS set to a provider hostname and a VPN app running at the same time. It is reasonable to assume one of them is now in charge of name lookups. Neither is, in the way that sentence implies, and the fastest way to see why is to follow a single request from the moment you tap a link.

These two features sit at different points in the same journey. Private DNS encrypts the question you ask a resolver. A VPN changes the route the answer's connection takes.

So walk it through in order, on a device where both are enabled, and note what each layer can still see.

Step one: the lookup leaves the app

You tap a link. Before anything connects, the app needs an address for that hostname. On Android the relevant screen is Settings, Network and internet, Private DNS. Picking Private DNS provider hostname puts the device in strict mode: it performs DNS over TLS to that hostname on port 853, and if the encrypted exchange fails, the lookup fails rather than silently falling back to plaintext on port 53.

That is a meaningful difference from Automatic, which uses opportunistic encryption and will happily use an unencrypted resolver when the network interferes. If your goal is that lookups are never in the clear, strict mode with a provider hostname is the setting that matches it.

Here is the first thing the walkthrough exposes: the lookup is protected against the local network, and the resolver still learns the name. Encryption covers the hop. The operator of that resolver sees the query because answering it is the job.

Step two: the connection takes a different route

The resolver returns an address and the app connects to it. This step is not affected by how the lookup was encrypted. Without a tunnel, the connection leaves your normal public address, and the destination IP and the TLS handshake usually make the hostname visible to the network anyway, encrypted DNS or not.

Turn the VPN on and this is the step that changes. Traffic matching the client's routing policy goes through the tunnel, the local network sees a connection to the VPN endpoint, and the site generally sees the exit address. Name resolution may travel inside the tunnel too, depending on what the client pushes.

That separation is the whole comparison in one sentence. DNS encryption answers who can read the question. A VPN answers where the conversation goes.

Step three: inside the tunnel, DNS becomes a policy question

Now the two features interact, and the browser is the usual source of surprise. A browser with its own secure DNS setting may send lookups to its chosen resolver over HTTPS instead of asking the operating system. Android's Private DNS setting does not reach into that decision.

In Firefox the switch is under Settings, Privacy and Security, Enable secure DNS. In Chrome it is Settings, Privacy and security, Use secure DNS. Both can be set to a specific provider or left off, and when they are on, the tunnel's DNS configuration is bypassed for those lookups even though the page traffic still uses the tunnel.

If the VPN pushes its own resolver and the browser insists on its own, you get a split: names resolve, pages load, and the lookups that were supposed to go through the tunnel went out directly. A resolver address that differs from the VPN endpoint is not proof of a leak by itself, but a lookup path that contradicts your stated intent is worth fixing.

Step four: internal names are where it breaks

Connect to a work VPN and open an intranet host. If the browser's secure DNS is on and pointing at a public resolver, that name does not exist as far as the browser is concerned. The tunnel is up, everything else works, and one hostname fails with an error that looks like the site is down.

The same failure appears in reverse on Android. Strict Private DNS with a public provider will not resolve names that only the internal resolver knows, and strict mode has no fallback. Splitting a phone's DNS between a public encrypted resolver and a corporate resolver is not a setting; it is a routing policy question that has to be answered by whoever runs the VPN.

Check this before blaming the tunnel: query the internal name, then the same name with the browser's secure DNS disabled. If it resolves, the resolver selection was the problem, not the connection.

What the walkthrough tells you to change

Four screens carry almost all of it. Look at them in this order and write down what each says, because the answer is usually visible in the combination:

1. Android Settings, Network and internet, Private DNS: Automatic or a provider hostname, and which hostname.
2. The browser's secure DNS setting: off, or pinned to a specific resolver.
3. The VPN client's DNS policy: does it push a resolver, and does split tunnelling exclude anything that still needs names?
4. An internal hostname test with the tunnel up, run twice, once with browser DNS on and once with it off.

Then match the fix to the requirement rather than the other way round. If the requirement is that lookups leave encrypted and go to a resolver you chose, set strict Private DNS and make the browser agree with it. If the requirement is that traffic exits somewhere else, configure the tunnel and stop expecting a DNS setting to move your address.

And keep the limits in view. Neither feature makes a hostile destination safe, and neither removes an identity you signed in with. Encryption changes who can read the question; the tunnel changes where the connection goes; nothing in either one anonymises the account.