When a VPN connects, DNS often feels like it starts behaving randomly. Internal names suddenly work. Public names resolve through unfamiliar resolvers. Existing connections keep working while new ones fail. Disconnect the VPN and everything changes again.
None of this is about record types or query formats. It’s about how DNS questions are routed once more than one network, resolver, or policy domain is in play.
The baseline case: one network, one DNS path
In the simplest case, a host has one active interface, one default route, and one set of DNS servers. The stub resolver sends every query down the same path, to resolvers learned from DHCP or static configuration, and behavior is predictable because there’s only one path to reason about.
Once multiple networks exist simultaneously, that assumption breaks.
Split DNS is a routing decision
Split DNS involves no special records and no alternate syntax. It describes a situation where different DNS queries are intentionally sent to different resolvers, based on which interface is active, whether a tunnel is up, or which domain is being asked about. Each resolver may represent a different namespace, trust boundary, or visibility scope.
From the client’s perspective, DNS stops being a single decision and becomes a routing problem.
Why VPNs introduce multiple namespaces
A VPN typically brings a separate administrative domain: internal DNS zones that must not be publicly resolvable, recursive resolvers with access to those zones, and its own filtering, logging, and visibility policies.
The moment the tunnel comes up, the system holds at least two DNS contexts, the local network’s DNS and the VPN’s, and the operating system must decide which queries go where. The DNS protocol has nothing to say about that decision. It belongs to the OS stub resolver and the VPN client.
How DNS routing decisions are made
Different operating systems handle this differently, but the same inputs recur.
Interface and routing priority
Many systems associate DNS servers with specific interfaces, and apply priority rules when several are active. This is why merely connecting a VPN changes DNS behavior with no application setting touched.
Tunnel state
VPN clients rewrite DNS configuration dynamically: adding resolvers, reordering existing ones, installing routing or name-based rules. The rewrites fire on tunnel transitions, which is exactly why DNS behavior can flip mid-session.
Destination domain
Some configurations define domain-based rules: queries for corp.example go to VPN DNS, everything else goes local. This is split DNS in its most explicit form, implemented with OS mechanisms such as NRPT rules on Windows or scoped resolvers on macOS.
Why internal names resolve only when the VPN is up
Internal names exist only in private zones. The public DNS hierarchy has never heard of them. With the tunnel down, queries for those names go to public or ISP resolvers and come back NXDOMAIN. With the tunnel up, the same queries route to internal resolvers and succeed.
Nothing about the names changed, only the path the questions took.
Why public names may resolve through private resolvers
The reverse surprise catches even experienced users. If a VPN-configured resolver becomes the system’s preferred DNS server, all queries may route through it, public domains included. It happens when the VPN client installs a default resolver, when domain-based exclusions are missing, or when the OS simply prioritizes the VPN interface for DNS.
This is valid behavior from the client’s side, but the VPN resolver now sees DNS queries for browsing that has nothing to do with the VPN. It’s also why DNS filtering and logging coverage can change the instant a tunnel connects.
Why DNS behavior changes mid-session
DNS decisions are made per query, not per application session. A tunnel transition changes resolver policy for new lookups, while established connections stay open without consulting DNS at all and cached answers keep serving until their TTLs expire.
The result reads as intermittent failure. An already-open browser tab keeps working against an internal service while a freshly opened tab, resolving the same name, fails or lands somewhere else. No specification is being violated. Stub resolvers and caches are each doing exactly what they do.
Policy-based DNS routing
Policy-based DNS routing means queries are dispatched by rules rather than a single default: rules about interface, tunnel state, domain suffix, or OS resolution policy.
All of that logic lives outside the DNS protocol, in the client and OS networking stack.
An additional layer: encrypted DNS in applications
Browsers and applications increasingly bring their own DNS-over-HTTPS or DNS-over-TLS resolvers, configured independently of the operating system. Those queries can bypass OS resolver selection entirely, ignore VPN-installed DNS policy, and introduce one more resolution path, this one controlled by the application.
At that point DNS behavior can also differ by application, and no single layer holds the full picture.
Why this behavior feels unintuitive
Most people think of DNS as a lookup table. It behaves more like traffic routing. The same question takes different paths, different resolvers give different answers, and the paths change while the system runs. VPNs and encrypted DNS simply make the routing visible by stacking competing decision layers on top of each other.
Summary
Split-network environments change DNS because queries are directed by policy, not sent down a single path. VPNs add namespaces and resolvers. Operating systems decide where each query goes. Applications increasingly route their own.
When multiple trust boundaries coexist, DNS stops being a single pipeline and becomes a decision engine.