Did the VPN Fix DNS, or Just Reuse a Cached Answer?

Opening a page seconds after the tunnel comes up is not proof that DNS now works, though the ticket usually says so. Nothing in that observation required a lookup: the name may have been resolved before the change and reused from a cache the tunnel never touched. Two different tests produce the same screen.

Compare what each test actually exercised before you credit the change.

A Page Load Is Not a Lookup

Every layer between the application and the resolver is allowed to remember an answer for its lifetime. The operating system keeps one, the browser keeps its own, and an application with a long-lived connection may never resolve anything again during the session. A load that succeeds after a tunnel change can therefore be a demonstration of memory rather than of routing. The absence of a failure is not the presence of a lookup.

That distinction changes what you should test next. If the goal is to show that the new resolver answers, you need a query that cannot be served from a cache you have not cleared.

Reading a cached success as proof that a previously unreachable server recovered is the most expensive version of this mistake, because it closes the incident on a false premise.

Count the Caches Before You Conclude

Four are worth naming: the application's own resolution, the operating system's client cache, the browser's internal state, and whatever recursive resolver the query eventually reaches. Each has a separate lifetime and a separate way to be cleared. Clearing one and testing another is how people conclude that flushing did nothing. One flush command never settles the question.

Negative answers get cached too. A name that was reported as missing can stay missing after the network is corrected, which reads as a broken tunnel when it is a TTL that has not expired. The DNS specification describes how this data is meant to be held and reused.

Record the Event, Not the Impression

Write down which of three things changed: the record, the path to the resolver, or a client setting. A record edit propagates on its own schedule, a route change takes effect on reconnect, and a browser setting applies to that browser alone. Collapsing them into a single before-and-after produces a timeline nobody can audit.

Note the time, the resolver in use and the answer received, including the case where the answer is a negative one. That is a fact someone else can check.

Run the Comparison the Same Way Twice

Clear the cache you intend to test, keep the original observation, and then query in a way that bypasses as much memory as possible. Naming the resolver explicitly tells you what that resolver knows; it does not tell you which resolver the application would have chosen.

resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example

On Windows, the client-cache flush clears the DNS client cache and nothing else. It does not describe a browser's private state and does not flush an upstream server, so a test built on it can only be interpreted narrowly. Say which cache you cleared whenever you report the result.

Then retest the actual application with a fresh request and the intended resolver policy active. A result produced under a different policy does not transfer.