NXDOMAIN Over a VPN Does Not Mean a Tunnel Outage

It is tempting to read one failed lookup as proof that the tunnel collapsed, especially when the name worked ten minutes earlier. The response says otherwise. NXDOMAIN is a completed DNS transaction in which a resolver stated that the queried name does not exist; a broken tunnel usually produces silence, a timeout, or a resolution attempt against the wrong server. The wireshark-free version of the argument is one query, one responder and one response code, and that triple is worth capturing before any configuration changes.

What the Response Actually Establishes

DNS separates outcomes that clients often collapse into one failure. A name that does not exist produces a negative answer with the NXDOMAIN code, while a name that exists but has no record of the requested type produces a successful response with an empty answer section. Both look like nothing useful to an application, and only one of them means the name is wrong.

That difference decides where the repair belongs. A missing AAAA record on a host that has an A record is not a missing host, and reissuing a certificate or rebuilding a tunnel to chase it wastes the one clue that was available. The distinction also sets the shape of the follow-up: a naming problem is fixed in the zone, and a type problem is fixed by asking for the right record or by accepting that the address family is simply absent.

The Myth: A Missing Private Name Means the Tunnel Failed

The myth survives because the two events so often arrive together. A client connects to the VPN, the operating system keeps a resolver it already trusted, and the internal name it now needs is asked of a server that has never heard of the private zone. That server answers honestly and negatively. The tunnel is carrying the packet; the answer is simply about a namespace the responder does not serve.

Split-horizon arrangements make this routine: the same zone name exists publicly and internally with different contents, and only the internal resolver knows the private records. Getting an authoritative-looking negative answer is therefore evidence about which resolver answered, not evidence about the state of the interface.

Two configuration details decide the outcome. The tunnel has to push or select the internal resolver, and the client has to apply that selection to the name being looked up. A per-domain rule that names a suffix slightly different from the record you typed will send the query to the public path, and the answer will be correct and useless.

Ask the Right Resolver With the Right Name

Record the responder before recording the verdict. A lookup that does not show which server answered cannot distinguish a policy problem from a namespace problem, and the two have unrelated fixes.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

The first two lines show what the local resolver decided and who it would ask. The +search lookup reproduces what an application does when it appends a search suffix, which is often the real query rather than the one typed into a diagnostic tool. The last line asks the internal server directly, bypassing client policy; if that succeeds while the plain lookup fails, the zone is fine and the routing of queries is not.

Negative Caching Explains the Delay After a Fix

Negative answers are cached by design, and RFC 2308 describes how the negative cache lifetime is derived from the zone's authority record. Correcting a record or a resolver rule therefore does not guarantee an immediate change on the client, and retrying a lookup that keeps returning the cached answer proves nothing new. Only a different responder, a different name or a flushed cache produces fresh evidence.

Flush the local cache, then repeat the same query against the same responder. On systems using the local resolver service that is one command; on others it is a service restart or a platform utility, and the specific tool matters less than repeating an identical test afterwards.

Separate the Name From the Path

Once the name resolves to the expected private address, DNS is finished as a subject and the application path becomes the next question. A host that answers lookups but refuses a connection has a different problem, and continuing to adjust resolvers after a correct answer is how an incident acquires three unrelated changes. Compare the resolved address against the one the service actually listens on before assuming the two agree.

Keep the transcript: the query, the responder, the code and the resolved address. That record is also what makes a later report verifiable, and it is the difference between a diagnosis and a story about a tunnel that seemed slow.