Split Horizon DNS: Why the VPN Resolves Differently

The report is always the same shape. In the office, files.company.com opens instantly. On the VPN, it times out, or worse, it opens the public website instead of the file server. Both machines are joined to the same domain and neither has a problem the user can describe.

The ideaWhat split horizon DNS is

Split horizon DNS, sometimes called split brain, means one domain name has two sets of records: one served to queries from inside the network, another served to everyone else. The internal view points at private addresses. The external view points at whatever the public internet should reach, which is often nothing at all.

It exists for a good reason. Internal services live on private addresses, those addresses must never appear in public DNS, and staff should be able to use the same name from anywhere. Publishing 10.0.5.20 for your file server tells the whole internet how your network is numbered, and it does not work from outside anyway.

The failureWhy the VPN breaks it

A machine in the office gets its DNS servers from DHCP, and they are the internal ones. It asks them, it gets the private address, everything resolves.

A machine on the VPN has two possible resolvers and the tunnel decides which it uses. If the VPN does not push the internal DNS servers, or pushes them alongside a public resolver, the operating system is free to ask either one.

Windows in particular sends the query to whichever interface it considers primary, and that decision is made on interface metrics rather than on which network holds the answer.

So the same laptop resolves correctly on Monday and incorrectly on Tuesday, having changed nothing, because a metric changed when it joined a different wifi network first.

DiagnosisTwo commands that end the argument

Do not test with a browser. A browser has its own cache, and increasingly its own resolver over HTTPS, so it can be right when the machine is wrong and wrong when the machine is right.

Read the server line in the first answer. If it names a public resolver, the diagnosis is finished: the query is leaving the tunnel. If it names the internal server and the answer is still wrong, the record itself is wrong and this is not a VPN problem.

RepairFixing it properly

There is a fix that works and a fix that appears to work, and telling them apart saves a return visit.

The fix that works is pushing the internal DNS servers and the internal search domain to VPN clients, and making sure nothing else is offered alongside them for the internal zone.

On a full tunnel VPN this is easy, because all traffic goes down the tunnel anyway. On a split tunnel it needs care, because the client keeps its local resolver for everything else and something has to decide which queries go where.

The fix that appears to work is editing the hosts file on the affected laptop. It resolves the ticket in two minutes and creates a machine that will fail confusingly the day the server is renumbered. If you do it, write it down.

On Windows, the durable answer for split tunnel VPNs is the Name Resolution Policy Table, which routes queries for a named suffix to a named server regardless of interface metrics. It is the one mechanism that makes the behavior deterministic rather than dependent on which network the laptop saw first.

The durable fixMaking it deterministic on Windows

A policy rule takes the decision away from interface metrics entirely. It says that queries for one namespace go to one set of servers, whatever the machine thinks the primary interface is this morning.

The leading dot matters. A namespace written as .company.com matches the domain and everything under it; written without it, it matches one name and nothing else, which is a rule that appears to do nothing for every host the reader actually cares about.

Add it by hand on one laptop to prove the behavior, then deploy it from Group Policy under Computer Configuration, Windows Settings, Name Resolution Policy, so it arrives on machines that never come back to the office.

A rule set by hand is a rule that exists on the one machine somebody tested, which is the same failure as the hosts file with more steps.

Mixed fleetEvery platform, and the cache that hides the fix

The mechanism has a different name everywhere, and the commands that matter are the same three: show the resolver order, send one suffix somewhere specific, and empty the cache.

The cache is the reason a correct fix gets rolled back. A machine that asked the wrong resolver has the wrong answer stored, and a name that failed to resolve is stored too: negative answers are cached for a period the zone itself sets, and it is often long enough to outlast the person testing.

So the fix goes in, the name still fails, and somebody concludes the fix did not work.

Flush before every retest, and check what is actually held rather than trusting that it cleared. On Windows Get-DnsClientCache lists the entries including the negative ones, which is also the fastest way to prove to somebody else that the machine never asked the server they think it asked.

The new oneEncrypted DNS, which bypasses all of it

Browsers and operating systems increasingly send DNS over HTTPS to a resolver of their own choosing. That resolver has no idea your internal zone exists, and it will never return a private address for it.

The symptom is precise and worth recognizing: the name resolves correctly at the command line and fails in one browser. Nothing about the network changed. The browser simply asked somebody else.

The answer is policy rather than plumbing. Every major browser can be told to leave encrypted DNS off for managed machines, and every major operating system honors a setting for it. On a network with internal names, that setting belongs in the standard build.

1. Run nslookup and read the server line first

   The name it resolved to matters less than which server answered. A public resolver in that line is the whole diagnosis.

2. Query the internal server by address directly

   If the internal server returns the right record, the zone is fine and the problem is resolver selection on the client.

3. Push the internal DNS servers and the search suffix to VPN clients

   On a full tunnel this is enough. On a split tunnel, add a rule that sends queries for the internal suffix to the internal server regardless of interface metrics.

4. Turn off encrypted DNS in the managed browser build

   A browser resolving over HTTPS to a public resolver will never see your internal zone, and the symptom looks like a network fault rather than a browser setting.

FAQQuestions from the comments