VPN DNS Wrong? One Authoritative Server May Be Stale

Connect the VPN and one hostname resolves to yesterday's address, or to nothing at all. Disconnect and it works again. The reflex is to blame the resolver the tunnel pushed, but the more common cause is a published name server that stopped receiving zone updates. The new path simply reached a different authority than the one your cached answer came from.

The symptom changes with the resolver

A recursive resolver returns what an authority told it, then keeps that answer for the TTL. If the tunnel pushes a different resolver, or changes the path so the old one is no longer reachable, the client asks a different authority and gets a different answer. The domain did not change at that moment; your view of it did.

This is why the same name can work in one office and fail from a hotel, and why clearing a local cache only sometimes helps. Clearing the cache sends the question to the same authority again.

The distinguishing test is a direct query to each published server.

Query each authority directly

Start from the delegation rather than from a list you remember. Ask the parent for the NS set, then query each name in that set for the record you care about. Two queries against the same name at different authorities tell you immediately whether the zone is consistent.

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

Do the same for the zone apex NS records, because the parent delegation and the zone's own NS set can disagree after a migration. Serial numbers on the SOA are the next thing to compare, and a secondary that is far behind is a transfer problem rather than an answer problem.

Run those queries from the network that fails, not only from your desk.

Separate intended views from broken ones

Some domains deliberately answer differently by region or resolver group, and split-horizon setups are normal in enterprise networks.

The question is whether the difference is documented and stable. An unintended view looks different: one authority has a record the others never received, or is missing one they all share. The RFC 2182 selection and deployment guidance treats authoritative availability as a shared responsibility, which is the right frame here. Redundancy only exists if every published server can answer the intended data, not merely accept a connection on port 53.

A server that answers SERVFAIL is easier to diagnose than one that answers confidently and wrongly.

A migration exposes what a cache hid

During a provider move, two authoritative locations change: the parent delegation and the zone's own NS records. Both have to be updated, and both are cached for their TTLs. If an old server stays up and keeps serving the previous zone, clients whose resolvers ask it will keep getting the old answer long after the cutover looked complete.

That is exactly the state a long-lived cache conceals. The workstation that worked all week was talking to a resolver holding a fresh answer from the new authority, while the old one kept handing out stale data to everyone else.

Changing the resolver on a laptop fixes that laptop and nothing else.

Fix the zone, not the resolver

Identify which servers are meant to be authoritative for the zone, correct the managed zone or the delegation so every one of them serves the intended data, and keep the redundancy you planned. Deleting a name server because one VPN exit got an odd answer reduces availability and leaves the inconsistency in place.

Then re-run the direct queries from both networks and wait out the TTL on the record you changed.

Confirm the answer is stable from each authority, and write the intended view into the zone documentation so the next difference is easy to classify.