Does Your VPN Encrypt DNS, or Just the Next Hop?

Enabling encrypted DNS on the VPN server is often described as closing a leak, and that description hides which connection changed. The client-to-resolver hop and the resolver-to-upstream hop are separate connections with separate owners. Encrypting one of them leaves the other exactly as it was.

Write down who receives the query at each stage before you touch a configuration file.

Two Arrangements Look Alike on a Settings Page

In the first arrangement the device runs DNS over TLS itself, and the tunnel simply carries that connection to a resolver you chose. The TLS session terminates at the resolver, which means the resolver sees the query and the VPN exit sees ciphertext it cannot read. In the second arrangement the device sends ordinary DNS through the tunnel to a forwarder on the VPN host, and that forwarder opens its own encrypted connection to an upstream resolver. Both look like "encrypted DNS with a VPN" in a feature list, and they place the readable query in different buildings.

The difference is measurable rather than philosophical. Look for the TLS session on the client, or look for it on the server, and you learn which arrangement you actually have.

Map the Resolver Chain Before You Change It

Count the resolvers on the path and name the role of each one. A forwarding component hands a request to another resolver, while a recursive resolver does the work of finding an answer and may talk to authoritative servers directly. Those roles are defined separately for exactly this reason, and the RFC 9076 resolver definitions are worth reading before you assume a single upstream destination exists. A host that runs its own recursive resolver has no single "upstream" to encrypt, which invalidates the whole plan.

Then ask which component the client is configured to use. A DNS address pushed by the VPN profile tells you where queries go, not which process answers them.

Note the failure behaviour too. If the encrypted upstream becomes unreachable, does the forwarder fail closed, fall back to plaintext, or fall back to a different resolver? That decision belongs in the record, because it changes the privacy guarantee at the moment the tunnel is least healthy.

Verify Which Hop Is Encrypted

Start on the client and confirm whether it holds a TLS session to port 853. A query that resolves correctly through port 53 proves nothing about encryption.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Then move to the VPN host and look for the outbound encrypted connection that the forwarder opened. The socket table tells you whether an upstream TLS session exists, and which process owns it:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

If the client shows a TLS session and the server shows none, you are in the first arrangement and the server cannot read queries it forwards at the IP layer. If the server shows the TLS session and the client shows plain port 53 traffic inside the tunnel, you are in the second arrangement: the onward hop is protected, and the forwarder still reads every name the device asks for. That second result is not a failure, but calling it end-to-end encryption is wrong.

Record the Owner and the Failure Behaviour

Ownership decides what you are allowed to promise. The device owner controls a client-side encrypted connection, while the VPN administrator controls the onward connection its forwarder creates. Anyone who operates neither can only describe the path.

Before enabling anything, check internal naming. Sending organizational names to a public resolver is not an equivalent design, and a split-horizon zone that only exists inside the network will not resolve upstream at all. Test one internal name and one public name after the change, and keep the result with the configuration change. If the encrypted path breaks resolution for internal hosts, the fix is a scoped resolver rule rather than a wider tunnel.

Finish by writing one sentence per hop: which component received the query, whether that hop was encrypted, and who can read the name. When the sentence for the VPN host still says it can read queries, the documentation should say so, because a diagram that claims otherwise will be trusted by someone who never ran the commands.