DNS over TLS plus a VPN: which part is protected

DNS over TLS encrypts the exchange between a client and the resolver it chose, and the resolver still reads the name. That sentence settles most of the confusion around DoT plus a VPN. The tunnel decides which path the encrypted query takes, while the resolver still learns what was asked. Neither mechanism substitutes for the other, and neither makes the other redundant.

Four checks decide whether the arrangement you have is the one you think you have.

Check 1: what the encryption covers

DoT wraps the DNS exchange in TLS, so an observer on the path sees a connection to an address and port rather than a name in a query. The resolver itself decrypts and answers. Compare it with DNS over HTTPS: both encrypt, and they use different transports, so a network that permits web traffic does not automatically permit a DoT connection.

That distinction matters when a captive portal or a filtering middlebox allows 443 and blocks 853. The tool that worked there is not evidence that the other one will.

Check 2: which route the query takes

The route is a client policy question. A DoT resolver can be reached through the tunnel, outside it, or by a path that changes with the network. Which one happens depends on routes and on whether the client protects its own DNS socket. A tunnel that captures all traffic will usually take the query with it, whatever the resolver address says.

Seeing a third-party resolver address in a test does not prove a bypass, and seeing encryption does not prove the intended recipient. Read the resolver and the path separately, then decide whether the pair is what you designed.

Check 3: internal names

An organization that publishes internal names needs a resolver holding those records. A public DoT service does not know your private namespace, and pointing the client at one guarantees those names fail. This is the most common practical regression when someone enables encrypted DNS on a managed device.

Keep the internal resolver for internal suffixes and encrypt that hop if policy requires it, instead of replacing it with a public provider.

Check 4: failure behaviour

A strict resolver setting with no reachable resolver produces a name resolution failure while the tunnel stays up. Look at the platform mode and its documented fallback rather than touching keys or certificates.

A fallback that silently uses plaintext DNS is a policy decision, not a convenience. Decide whether failure should be visible or should degrade to something weaker, and write the answer down.

Trust the certificate, not the answer

Use the provider hostname and verification configuration documented for the service. Disabling TLS checks so an unfamiliar resolver will answer gives you an encrypted channel to an unverified endpoint, which is worse than the plaintext query it replaced in one specific way: it looks safe. The DNS over TLS specification sets out the authentication expectation behind that check.

An answer from a resolver you cannot authenticate is a claim, not a result.

What this leaves unexplained

DoT does not hide the name from the resolver, does not hide the connection's destination address from the network, and does not decide whether the query travelled through the tunnel. Those are three separate questions with three separate answers.

Write the resolver identity, the transit path and the internal-name policy down as three lines. The next DNS question you get will be one of them.