What Your VPN's DNS Setting Actually Changes

Most VPN clients have a DNS section with two or three options and very little explanation: use the provider’s DNS, use custom servers, or leave the system settings alone. The choice decides which server receives the list of hostnames you look up, and whether that list travels inside the tunnel or beside it.

It is a small setting with a large effect, and the default is not the same across clients.

The options and what they do

“Use VPN DNS” or “automatic”. The client replaces your device’s resolver settings with one the provider operates, reachable through the tunnel. Lookups go inside the encrypted path, and the provider’s resolver answers them. This is the option that makes the VPN’s coverage complete, and it is the right default for most people.

“Custom DNS”. You supply resolver addresses and the client points the tunnel’s adapter at them. Whether those lookups travel through the tunnel depends on the address you gave: a public resolver on the internet will be reached through the tunnel, so the query is encrypted in transit but answered by a third party rather than your VPN provider. A resolver on your own network cannot be reached through the tunnel at all, which produces confusing partial failures.

“System DNS” or “do not change”. The client leaves your existing settings untouched. Your lookups go to whatever your router advertised — normally your internet provider’s resolver — in the clear, outside the tunnel. Your traffic is protected and your hostname list is not. This is a leak by configuration, and the reason it exists as an option at all is that some corporate and local-network setups depend on internal name resolution that a tunnel resolver cannot provide.

“Prevent DNS leaks” or “DNS leak protection”. Usually a separate toggle rather than a mode. It adds enforcement: firewall rules blocking lookups to anything except the tunnel’s resolver, so the operating system cannot fall back to another one. Without it, setting the tunnel resolver is a request rather than a guarantee.

Why setting a resolver is not enough on its own

Operating systems do not treat resolver settings as exclusive. They hold them per network interface, and depending on the platform and version they may query several in parallel and take the first answer, or fall back to another interface’s resolver when one is slow to respond.

So a client can correctly configure the tunnel adapter’s resolver and still see queries going out on the physical adapter to your provider. Nothing is misconfigured in the ordinary sense — the operating system is behaving as designed. That mechanism is behind a large share of the cases in what a DNS leak is.

This is why leak protection is implemented with firewall rules rather than just settings. Blocking the alternative path is the only reliable way to make the tunnel’s resolver the one that gets used.

The application layer can override all of it

Browsers with their own encrypted DNS enabled do not use the system resolver. They send lookups to a resolver of their own choosing, over an encrypted connection, ignoring whatever the VPN client configured.

The traffic still goes through the tunnel, so your provider cannot read the queries. But your VPN provider’s resolver is bypassed, and the browser’s chosen resolver receives your hostname list instead. Whether that bothers you depends on which party you would rather have it — the tradeoff laid out in DNS over HTTPS versus a VPN.

What it definitely does is make leak tests confusing. A test run in that browser reports the browser’s resolver, which is neither your provider’s nor your VPN’s, and looks like a misconfiguration when it is a deliberate feature. If you want the VPN’s resolver used consistently, turn the browser’s secure DNS off.

Cases where “system DNS” is the correct answer

A tunnel resolver cannot resolve names that only exist on a local network. Internal hostnames at a workplace, a router’s admin name, or devices advertised by local discovery are not in public DNS. If the client forces all lookups through the tunnel, those names stop resolving.

Options, in rough order of preference:

• Split DNS, if the client supports it: send specific domain suffixes to a local resolver and everything else through the tunnel. This is the clean solution and business-oriented clients usually have it.
• Split tunnelling to keep the relevant application outside the tunnel entirely, along with its resolution.
• System DNS, accepting that your hostname list goes to the local network’s resolver.

The last one is a real tradeoff and worth making knowingly rather than because a default was left in place.

Verifying the setting does what you chose

Check the resolver in use, not just the exit address. They are separate tests and one passing tells you nothing about the other.

The sequence that works:

1. Connect the VPN.
2. Confirm the exit address belongs to the provider — the check in what is my VPN IP address.
3. Run a DNS-specific test and note which resolvers it reports.
4. Compare against what you expected: the provider’s, your custom choice, or your internet provider’s.

If step four shows your internet provider while you selected the tunnel’s resolver, you have a leak — turn on leak protection, check the browser’s secure DNS setting, and retest. The broader method is in how to check for a VPN leak.

A note on speed

Resolver choice affects how quickly pages start loading, more than how fast they transfer. A resolver at the end of a tunnel is further away than your provider’s, so cold lookups take longer. Cached ones are unaffected.

The effect is usually small and easy to mistake for the tunnel being slow in general, which is a different thing with different causes — worth separating before concluding that the VPN slows your connection. If page loads feel sluggish but transfers are fine once started, resolution is the more likely culprit.

What to set

For most people: the provider’s DNS, with leak protection on, and the browser’s own secure DNS off. That keeps lookups and traffic on the same path, with one party seeing both, which is the arrangement a VPN is supposed to produce.

Deviate deliberately: custom resolvers if you have a specific operator you prefer, split DNS if you need local names, system DNS only when something genuinely requires it and you have accepted what it exposes.