DNS Resolver Logs vs VPN Connection Logs: What Each Holds

A DNS resolver log and a VPN connection log are both network records, both useful, and not interchangeable. The resolver receives names it was asked to answer. The VPN endpoint handles tunnel connections and records whatever its implementation chose to record about them. They can sit in the same building, be operated by the same team and be covered by the same privacy notice, and they still describe different events with different identifiers and different retention. Reading one as if it were the other is how investigations go sideways.

Two logs, two events

A resolver entry answers a question about naming: this client asked for this name at this time, and the answer was this. A VPN entry answers a question about connectivity: this peer established or lost a tunnel, was assigned this address, and transferred roughly this much data before it went away. Neither is a record of what the user did inside an HTTPS session, and neither substitutes for the other.

The distinction has a practical consequence for promises. A statement that a VPN provider does not log tunnel activity says nothing about the resolver it hands out, and a resolver's retention policy says nothing about who connected to the tunnel. Each claim belongs to its own operator and its own system.

Follow the query before reading either log

A query reaches a resolver only if the path actually asks it. An application can use the operating system's resolver, run its own encrypted DNS client, or read a cached answer and never send anything. So a resolver log that shows nothing is not evidence that a name was never used; it is evidence that this resolver was not asked.

resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager

That last command reads the local resolver's own journal, which is not the same as the upstream server's log. If your queries leave through DNS over HTTPS to a provider, the local stub may show nothing while the provider has the complete record, and the provider is a different operator with a different policy.

What each record can and cannot show

Joining them is where the real work is, and joining them is not always possible. A resolver that logs client addresses can be compared with a VPN that assigns addresses from a known pool, and that comparison produces a plausible link between a queried name and a tunnel, which remains a link between two records rather than a record of a person.

Encrypted DNS changes the transport, not the visibility at the endpoint. The resolver still receives the question it answers, as RFC 8484 makes clear, and retention at that resolver is a policy decision rather than a property of the protocol.

Where split DNS and caches confuse the story

Multiple resolvers are normal. A split-DNS design sends internal names to an internal server and everything else to a public one, so a single investigation may involve two logs that were never meant to be combined and two retention settings that were never meant to be compared. Seeing queries at both is evidence that the design works, not evidence of a leak.

Caches cut the other way. A popular name may be answered from cache for hours, so the resolver's record shows the first query and then nothing, while the user's application keeps resolving the same name happily. An absence of entries after a certain time does not mean nobody used the name after that time.

Background traffic is the third distortion. A phone that resolves a telemetry name at boot, a browser that resolves a search suggestion domain, and an updater that checks in hourly all appear in a resolver log alongside the name you actually care about. Volume in that log is not attention, and counting queries is not counting visits. A resolver log is a record of questions, and questions are cheap to generate.

Ask the retention questions separately

For each system, ask three questions: who collects, what is collected, and how long it is kept. Then ask who can read it and under what process. The RFC 8484 discussion of DNS over HTTPS is a good reminder that encrypted transport does not remove the endpoint, and an operator's own documentation is the only reliable statement about what that endpoint keeps.

When a claim about privacy is made about "the VPN", split it into components before accepting it: the tunnel operator, the resolver the tunnel hands out, any upstream resolver those queries reach, and the applications on the device. Each has its own answer, and a claim that is accurate for one is routinely repeated as if it covered all four.

For troubleshooting, use the same split. Ask which application made the query and which resolver answered it, then look at the log that actually owns that event. Guessing from the other log saves a minute and costs an afternoon.