VPN DNS Report: What to Include So It Reproduces

DNS is broken is a conclusion, and it is not one a helper can act on. The useful part of a report is the shape of the failure: which name, through which resolver, with which response. Three details turn a complaint into something reproducible, and all three are safe to share once the private parts are relabelled. What follows is the minimum a VPN DNS report needs before anyone can help.

A Category of Name, Not a Verdict

Start with the name itself and classify it: public, internal, short, fully qualified, or served by one specific suffix. An internal name that fails while public names resolve points at resolver selection rather than at reachability. Every name failing points at the path to the resolver, which is a different investigation with different evidence. The category carries the diagnosis, and the exact string can be redacted.

Say whether the failure needs the tunnel to be up, or happens after it disconnects. A name that only breaks while the VPN is active implicates the per-link configuration, while one that breaks after disconnect implicates leftover state. Reports usually omit this and then wonder why the first suggestion does not help.

Record the Resolver Path

A query sent to an explicitly chosen server and an application's ordinary lookup are different experiments. State which one produced the failure, because a manual query to a working server proves only that the server works. The commands below separate the system path from a direct question.

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

The status output names the per-link servers and the routing domains, which is where split DNS is decided. The getent call follows the same path the application does, including the nsswitch order. The direct query bypasses both and tests one server in isolation. Report which of the three failed and which succeeded, and the reader no longer has to guess at the path.

State the Controlled Comparison

Change one variable and say what changed. Public names resolving while internal ones fail is a selection problem, every name timing out is a path problem, and a private name that resolves to a public address is a leak into the wrong resolver. Two of those three have nothing to do with whether the tunnel is up. A report claiming all queries are broken usually contains a comparison that was never run.

Separate resolution from delivery. When the name resolves and the site still fails, the DNS stage succeeded and the report should say so, because the next step is a route or a listener rather than a resolver. That single distinction saves a round of questions more often than any log excerpt.

Redact the Namespace, Keep the Relationships

Internal names can be replaced, as long as the replacements preserve structure. Map each distinct server and suffix to a stable label, and keep that mapping out of the shared copy. Replacing every internal host with the same placeholder destroys exactly the evidence the report needs, because the reader can no longer see that one suffix resolved and another did not. The same rule applies to addresses: keep the prefix relationships and change the host bits if policy requires it.

Send the record through the verified channel and leave out what diagnosis never needs. Passwords, private keys and unrelated company names are not part of a DNS question. What the reader needs is the failing category, the resolver path, the exact error and the one comparison you ran.