DNSSEC vs a VPN: which one hides your DNS queries?

Two mechanisms get credited with the same job and neither performs it. DNSSEC answers whether the data you received really came from the zone that publishes it, and a VPN decides which path your packets take. Neither of them hides the name you asked for in every case, and the settings that look like they should are usually about transport or routing rather than about validation. Naming the layer first turns a vague privacy question into a specific one.

Three claims that get merged into one

Authenticity is the claim that the answer is the one the zone published and has not been altered in flight. Confidentiality is the claim that nobody on the path can read the query or the answer. Routing is the claim that the packets follow a path you chose, which is what a tunnel provides.

DNSSEC addresses the first and says nothing about the other two. DoT and DoH address the second for the hop to the resolver. A VPN addresses the third and may also affect the second, but only as a side effect of where the traffic goes.

Application traffic is a fourth case: HTTPS protects and authenticates the web exchange between your client and the site, and no DNS layer substitutes for it.

What signature validation can and cannot do

A validating resolver checks the chain of signatures from the zone up to a configured trust anchor, then hands back an answer with the authenticated-data flag set when the check succeeds. That flag is evidence about the data, not about the connection or the destination's intentions.

It cannot stop a legitimate zone owner from publishing authentic records for a service you should not trust. A correctly signed answer from a compromised domain is still correctly signed, and DNSSEC has no opinion about whether that domain deserves your credentials.

It also does not hide anything. The query and the answer cross the network in a form a resolver and any observer on that path can read, unless some other layer protects the transport. A signed answer and a private answer are different properties, and a deployment can have either one alone. Test both if either matters to you.

Where confidentiality actually comes from

Encrypted resolver transport wraps the DNS exchange in TLS, so the resolver still sees the question but the path between you and it does not. That moves trust rather than removing it: you are trusting the resolver more and the local network less.

A VPN can carry queries to a resolver on the far side, which changes both the path and the resolver that sees them. That is a routing decision with a privacy consequence, and on a managed network the internal resolver may be the only one that can answer internal names.

The combination people actually want is usually three things at once: validation on, encrypted transport to a resolver they chose, and application TLS on the destination. Each is independent, and skipping one leaves a different gap.

Check validation and transport separately

Two tests settle most confusion. The first asks whether the resolver validated the answer; the second asks whether the transport was protected. They fail in different ways and neither implies the other.

These commands print the flags from a validating query, repeat the query with checking disabled, and run local validation with delv:

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

An answer with the authenticated-data flag and a signature present shows validation at that resolver. A validation failure with delv shows a broken chain somewhere between the zone and the trust anchor, which is a publishing problem rather than a tunnel problem. A timeout with no flags at all is a transport or reachability problem, and treating it as a signature failure sends you to the wrong layer.

What to do when a VPN breaks lookups

If lookups worked before the tunnel and stop after it, compare the resolver each path uses. Split tunnelling, an internal resolver reachable only through the tunnel, and a client that rewrites resolver settings all change the answer without touching DNSSEC.

Disabling validation globally is the wrong first move, because it removes the only mechanism that reports tampering and does not fix a resolver that cannot be reached. Narrow the fault first: resolution, transport, validation, then policy. Only the third belongs to DNSSEC, and only the second belongs to encrypted transport.