DNS over TLS vs VPN: Key Differences

DNS over TLS and a VPN are both described with the word "encrypted", and both appear in privacy checklists. That similarity hides a large difference in scope. DNS over TLS secures a single conversation, the one where your device asks a resolver to turn a name into an address. A VPN secures every conversation your device has until it reaches the VPN server. If you treat them as substitutes you will either overspend effort on one or leave a gap that the other does not fill.

This article follows a single lookup hop by hop, so you can see exactly where each tool applies. It also covers how DoT behaves when it fails, what changes when it runs with a VPN, and a short procedure for checking your own setup. The sibling topic, DNS over HTTPS vs VPN, compares the web-flavoured cousin; this piece stays with TLS on its own port and with the network-level questions around it.

What DNS over TLS secures: one hop

When you open a website, your device first needs the address behind the name. This lookup, defined in RFC 1035, traditionally travels in plain text over port 53. Anyone on the path between your device and the resolver can read the names you ask for and can often alter the answers.

DNS over TLS, specified in RFC 7858, wraps that same query in a TLS session. The query is identical; only the packaging changes. Three things follow:

• The names you look up are hidden from observers between you and the resolver. The local network sees that you are talking to a resolver, and how much, but not which names.
• Tampering becomes much harder. TLS authenticates the resolver and detects modification of the answers in transit.
• Nothing else changes. The resolver itself still sees every name you ask for. Your device still connects directly to the website's address afterwards, in the open as far as that address goes, and the website still sees your real IP address.

DoT therefore protects the content of one hop. It does not hide you from the resolver, does not hide the destination address, and does not touch any traffic other than DNS. For the basic picture of how names are resolved, see how DNS works.

Anatomy of one DoT lookup

A single encrypted lookup follows a short sequence.

1. Your device, or a home router that forwards for it, opens a TCP connection to the resolver on port 853.
2. A TLS handshake runs, using TLS 1.3 where both sides support it. The resolver presents a certificate.
3. If you configured a hostname for the resolver, your device checks that the certificate matches that name. If you only configured an address, there may be no strong name check.
4. The DNS question goes through the encrypted session and the answer comes back the same way.
5. The connection is often kept open for reuse, so later lookups skip the handshake and are quicker.

Two points matter in practice. The dedicated port makes DoT easy to recognise and easy to block, which is both its operational strength (administrators can manage it) and its weakness (a network can simply not allow it). And whether the certificate is checked decides whether DoT resists an impostor resolver, or merely hides queries from passive onlookers.

Strict and opportunistic modes

RFC 7858 describes two usage profiles, and the difference changes what happens when something fails.

Behaviour	Strict	Opportunistic
Requires a successful TLS connection	Yes	No
Checks the resolver's identity	Yes, by hostname	Often not
If port 853 is blocked	Lookups fail	Falls back to plain DNS
Protects against passive observers	Yes	Usually, unless it falls back
Protects against an active impostor	Yes	Not reliably
Risk	Names stop resolving on restrictive networks	A silent downgrade you may never notice

Neither is better in every case. Strict gives a clear promise and a visible failure. Opportunistic gives convenience and a quiet loss of protection when a network interferes. If you choose a strict mode, expect to troubleshoot occasional "the internet is broken" moments on hotel and airport networks; if you choose an opportunistic one, do not assume the protection is always on.

What a VPN protects that DoT cannot

A VPN differs from DoT on four counts.

• Scope. The tunnel carries everything your device sends: web requests, app traffic, DNS, and more. DoT carries only DNS.
• Destination addresses. With a VPN on, the local network sees only an encrypted connection to the VPN server, not the websites you open. With DoT alone, the network still sees every destination IP address you connect to.
• The address websites see. A VPN replaces your IP address with the VPN's exit address. DoT leaves your IP untouched.
• Where trust moves. A VPN shifts trust from your local network to the VPN operator, who can see where your traffic goes. DoT shifts the trust for names to your chosen resolver. For what an operator can and cannot see, read what a VPN provider can see.

Neither tool encrypts what you read on a page, which is HTTPS's job, and neither makes you anonymous.

Who sees what, point by point

Imagine four setups for the same lookup and visit. Following the path shows how each tool changes the picture.

Observer	Plain DNS, no VPN	DoT only	VPN only	VPN plus DoT
Wi-Fi owner: names you look up	Sees them	Hidden	Hidden, inside tunnel	Hidden
Wi-Fi owner: sites you connect to	Sees the addresses	Sees the addresses	Sees only the VPN server	Sees only the VPN server
Your internet provider: names	Sees them	Hidden	Hidden	Hidden
DNS resolver: names you ask for	Sees them	Sees them	Sees them (the VPN's choice of resolver)	Sees them
DNS resolver: who is asking	Your IP	Your IP	The VPN's address	The VPN's address or yours, depending on routing
Website: your IP address	Yours	Yours	VPN exit	VPN exit
VPN operator	Not involved	Not involved	Sees traffic and may see lookups	Sees traffic, lookups may be encrypted past the exit

Notice two things. First, in the VPN-only column the resolver's identity depends on who runs it. Many VPN services run their own resolvers; if so, the VPN operator sees both your traffic and your lookups. Second, in the DoT-only column the observer does not stop seeing you; it only loses the names. This is a modest gain that matters most on shared networks and with providers that sell or analyse lookup logs.

Running both: three outcomes

Combining DoT and a VPN can give three outcomes, and a test is the only way to know which you have.

1. DNS goes through the tunnel. The VPN app sends all lookups, including DoT sessions, inside the tunnel. The local network cannot see them at all. This is the common, intended case.
2. DoT bypasses the tunnel. An operating system or router configured for DoT sends its encrypted lookups straight to its chosen resolver, outside the VPN. The lookups are still encrypted, so a passive observer cannot read the names, but the resolver you set sees your real address and a DNS leak test will show an unexpected resolver. This is not the same as a plain-text leak, but it is not what you meant either. What is a DNS leak explains the difference.
3. DoT is blocked inside the tunnel or on the network. Strict mode fails and names do not resolve until you change something. An opportunistic mode quietly falls back to the VPN's resolver, which is acceptable.

None of these outcomes is a mistake in itself; they are results of configuration. What matters is that you know which one applies, so test it rather than assume.

Where DoT still earns its place when you use a VPN

It is easy to think the VPN makes DoT redundant. Often it does for traffic inside the tunnel, but there are cases where DoT is still useful.

• When the VPN is off. At home you might not run a VPN all day. DoT on the device or router keeps your lookups out of your provider's easy view.
• For devices that cannot run a VPN app. A router that forwards DNS over DoT covers a smart TV, speaker or console without any client software.
• Between the VPN server and its upstream resolver. A well-run service can use encrypted DNS upstream so the lookups are not exposed on the operator's own path. As a customer you cannot verify this from the outside; ask the provider what it states in writing.
• As a reminder of layers. If a VPN session drops for a moment, encrypted DNS still protects the lookups made in that gap, though it will not hide the destinations your device then contacts.

Checking your own setup

A short test takes less than ten minutes.

1. Note your starting point. With the VPN off, run a DNS leak test page and write down the resolver it reports.
2. Turn on the VPN and run the test again. The resolver should change to one belonging to the VPN, or to your configured DoT resolver, but should no longer be your provider's default.
3. Compare with your intention. If you expected the VPN's resolver but see your configured DoT resolver, it means DoT bypasses the tunnel. Decide whether you accept that or change the setting.
4. Try a restrictive network. On a hotel or guest network, watch what happens in strict mode. If lookups fail, switch to the network's own or mobile data for that moment.
5. Test a reconnect. Drop the connection and check that lookups continue to behave as you expect.

Our help article on how to check if your VPN is working lists the other checks to run alongside this one.

Troubleshooting when DoT and a VPN disagree

• Names do not resolve after turning on the VPN. The DoT resolver may be unreachable from inside the tunnel. Switch DoT to automatic or off for the moment and see whether lookups return.
• Lookups are slow. Each new TLS connection adds a handshake. A resolver far from you, or a tunnel with high delay, makes it worse. Try another resolver or stay on the VPN's own.
• A captive portal does not appear. Public networks need a plain DNS lookup to show their sign-in page. A strict DoT setting can prevent it. Turn the setting off briefly, sign in, then turn it back on and connect the VPN.
• The leak test shows two different resolvers. One may be the VPN's and the other your DoT choice. Decide which you want and remove the other.
• Everything works except one app. Some apps ship their own resolver and ignore system settings. That is a per-app matter.

Three short scenarios

A family with a shared router. The parents configure the router to forward lookups over DoT. The household's smart TV and speaker are covered with no apps, and the internet provider can no longer read the names. The children's phones also run a VPN on public Wi-Fi, which hides destinations on those networks.

A student on campus Wi-Fi. She sets her laptop to strict DoT. On the campus guest network, port 853 is blocked and nothing loads. She notices it right away, uses her phone's mobile data for that session, and keeps the DoT setting for her home network.

A remote worker in a cafe. He starts the VPN and runs a leak test. The resolver shown is his DoT choice, not the VPN's. He decides he is comfortable with that because it is a resolver he trusts, but he writes down what he saw so he can recheck after updates.

Summary

DNS over TLS secures one hop: your device or router asking one resolver for addresses. It hides the names from the network in between and makes tampering harder, but the resolver still sees the names, the sites still see your IP, and the destination addresses stay visible. A VPN secures everything your device sends to the VPN server and replaces the address websites see, while moving trust to its operator. They work together well when DNS goes through the tunnel and can surprise you when DoT bypasses it, so test the real behaviour. Treat DoT as a useful extra layer, not a replacement for a VPN, and the other way round.

If you want to try a VPN pass for everyday use, you can look at the options on the pricing page.