VPN and DNS Security: What Is Protected?

Before your phone can load a single page, it has to answer a plain question: what is the address of this website? That question, and the answer to it, is the Domain Name System, or DNS. Because DNS happens before the page loads, it is easy to forget about, and it is one of the places where privacy quietly leaks. A VPN is often described as "encrypting everything", but what does that mean for DNS specifically? Who can still see your lookups when a VPN is on? And how can you tell if something is wrong?

This article follows a single DNS request from start to finish, first without a VPN and then with one. You will see which parts are protected, which are not, how leaks happen, and a short test routine for your own devices. It is general educational information and does not promise protection in every network or device.

What a DNS request contains

DNS translates names such as example.com into numeric IP addresses. The Cloudflare explainer on DNS is a good plain overview, and the original concepts are described in RFC 1034. Our own piece on how DNS works goes deeper into the full chain.

A request typically reveals:

• The domain name you want, such as a bank, a clinic, a news site or a forum. This is the most important part for privacy because it describes your interests.
• The type of record you are asking for, for example the address of a site or its mail server.
• Your IP address, because the answer has to come back to you.
• The time, since the resolver sees when the request arrived.

Normally DNS requests travel in plain, unencrypted form, usually over UDP port 53. Anyone on the path who can capture traffic can read them. That is why DNS has become a favourite target for both curious network owners and attackers.

The journey of a lookup without a VPN

Imagine you open a news website on a café network.

1. Your phone asks the café router: "what is the address of the news site?"
2. The router forwards the question to a resolver, usually the one assigned by the internet provider unless you changed it.
3. The resolver answers, or asks further servers if it does not know.
4. Your phone receives the address and connects to the site.

Several parties can see the question: the café network owner, the router, the internet provider that runs the resolver, and anyone sniffing the network. None of them need to see the page itself to know which site you wanted. In addition, an attacker who controls the router can answer the question with a wrong address, which is the basis of DNS hijacking. Read more on DNS hijacking for how that works.

The journey of a lookup with a VPN

Now repeat the scene with a VPN switched on.

1. Your device wants to look up the news site. The VPN app has told the operating system to send traffic, including DNS, through the encrypted tunnel.
2. The question is encrypted and travels to the VPN server. The café router sees only encrypted data going to one address.
3. The VPN server passes the question to a DNS resolver, typically one operated by or for the provider.
4. The answer comes back through the tunnel, and your device connects to the site, also through the tunnel.

What changed? The café network owner, the router and the internet provider can no longer read the question or alter the answer in transit. What did not change? The resolver still sees the question, and the destination website still sees a connection from the VPN server. You have moved the trust from the local network to the VPN provider. That is the correct way to describe a VPN: it relocates visibility, it does not erase it. For a longer look at what the provider can learn, see what a VPN provider can see.

What is protected and what is not

Aspect of DNS	Without VPN	With a working VPN
Local network can read lookups	Yes	No, they are encrypted
Internet provider can read lookups	Yes, if it runs the resolver or sees plain DNS	No, it sees an encrypted tunnel
Router can change the answers	Yes	Much harder, because the answer returns inside the tunnel
The resolver sees the domain names	Yes (the provider's resolver)	Yes (the VPN's resolver)
The destination site sees your real IP	Yes	No, it sees the VPN server's address
Whether a site is genuine	Not checked	Not checked
Leaks caused by device settings	Not applicable	Possible if misconfigured

The table shows the main lesson: a VPN protects DNS from the people between you and the VPN server, and trusts the VPN's resolver instead.

How DNS leaks happen

A DNS leak occurs when some lookups travel outside the tunnel even though the VPN appears connected. Our dedicated article on DNS leaks explains the symptom; here are the common mechanisms.

• Operating system behaviour. Some systems send DNS to several resolvers at once and accept the fastest reply. If one of those resolvers is outside the tunnel, a copy of your request leaks.
• Browser settings. A browser may use its own encrypted DNS service rather than the system one, so lookups skip the VPN's resolver. This is not necessarily a problem, but you should know who the resolver is. See VPN and browser DNS.
• IPv6. If the tunnel handles only IPv4, IPv6 lookups and traffic may go around it. Check what an IP leak is.
• Split tunneling. Apps you exclude from the tunnel use your normal resolver by design. That is expected, but be aware of which apps those are.
• Reconnection gaps. For a moment after the VPN drops, the system may resume normal DNS before the tunnel returns.
• Manual DNS settings. A fixed DNS server set on your device or router can override what the VPN gives you.

A worked example: coffee shop, three outcomes

Take Nattha, who reads work email and a few news sites in a café. We follow the same hour in three setups.

No VPN. The café Wi-Fi sends her lookups to the internet provider's resolver. The café owner's router can log every domain. A forced sign-in page appears first, which is normal, and she types her email address into it, not noticing that the network is unfamiliar.

VPN on, but leaking. She connects the VPN and the app shows green. A leak test shows resolvers belonging to the café's internet provider. A setting in her browser or a manually fixed DNS address is overriding the VPN. Her page content is encrypted, but the list of domains is visible.

VPN on, no leak. The same test shows resolvers belonging to the VPN service. The café network sees only the encrypted tunnel. The domains are known to the VPN's resolver, which is the trust she chose.

The only difference between the second and third setups is a configuration detail. That is why testing matters more than assuming.

How to test your own setup in five minutes

1. Disconnect the VPN and open a DNS leak test page. Note the resolver names and the organisation they belong to. This is your normal baseline.
2. Connect the VPN, wait a few seconds and reload the test. The resolver list should change to something associated with the VPN service, not your internet provider.
3. Repeat in the browser you use daily. If it has its own secure-DNS option, note whether the results differ.
4. Run the test on mobile data and on Wi-Fi. Some leaks show up on one network and not the other.
5. Check IPv6. If a test shows an IPv6 address that belongs to your provider, the tunnel is not covering IPv6.
6. Do a reconnect check. Turn Wi-Fi off and on and run the test again straight afterwards.
7. Write down what you find. If leaks persist, our help guide on checking if your VPN is working shows how to go further, and the Windows and Android guides explain system settings.

If the results change, the DNS part of your setup is doing what it should.

DNS over HTTPS, DNS over TLS and a VPN

Encrypted DNS protocols such as DNS over HTTPS (RFC 8484) and DNS over TLS (RFC 7858) hide the lookup from the local network without a VPN. They solve the same visibility problem for DNS only, and they move trust to the encrypted-DNS provider. They do not hide the address of the site you connect to afterwards. A VPN covers the whole connection. If you want a detailed comparison, our article on DNS over HTTPS vs VPN walks through when each is enough and when both together make sense.

Limits to keep in mind

• A VPN does not decide whether a site is real. A convincing fake shop will resolve like any other.
• The VPN's resolver can still see your lookups, so the provider's honesty matters.
• If a device already has malware, DNS settings can be altered by it.
• A VPN does not remove tracking by the sites you log in to.
• Public Wi-Fi sign-in pages sometimes need the normal DNS to work before the VPN can connect, so a brief non-VPN moment is expected. After sign-in, connect and re-test.
• Corporate and school networks may require their own DNS and may not allow a VPN to override it.

A short checklist to keep

• Connect the VPN before opening mail or banking on shared networks.
• Run a leak test after installing, after big operating-system updates and after changing browsers.
• Do not set a manual DNS address on your device unless you know why.
• Keep IPv6 in mind when testing.
• Use HTTPS sites and check the address bar. DNS protection does not replace that.
• Update the VPN app and the system regularly.

With XPASS you sign in to the free VPNclient app using the username and password from your My Pass page. The download page lists the apps, and the app's default settings are the sensible place to start.

Summary

DNS is the question your device asks before every visit, and it is normally asked in the open. A working VPN carries that question inside its tunnel, so the local network and your internet provider cannot read or tamper with it, while the VPN's own resolver can. Leaks happen when a setting sends lookups around the tunnel, and a five-minute test shows whether yours does. Keep your expectations realistic: DNS protection reduces exposure, it does not decide which sites are trustworthy.

If a simple prepaid way to add this protection fits your needs, you can look at the pricing page at your own pace.