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 the behavior changes again.
This article answers one question only:
How does DNS behave unexpectedly when traffic is split across multiple networks or trust boundaries?
The answer is not about DNS record types or query formats. It is about how DNS questions are routed when more than one network, resolver, or policy domain is present.
The baseline case: one network, one DNS path
In the simplest case, a host has one active network interface, one default route, and one set of DNS servers. The stub resolver sends every DNS query to the same recursive resolver, usually learned via DHCP or static configuration. Resolution behavior is predictable because there is only one namespace in play.
Once multiple networks exist simultaneously, that assumption breaks.
What “split DNS” means conceptually
Split DNS does not mean special records or alternate DNS syntax. It describes a situation where different DNS queries are intentionally sent to different resolvers.
The split is usually based on which network interface is considered active, whether a VPN tunnel is up, or which domain name is being queried. Each resolver may represent a different namespace, trust boundary, or visibility scope.
From the client’s perspective, DNS is no longer a single decision. It becomes a routing problem.
Why VPNs introduce multiple namespaces
A VPN almost always represents a separate administrative domain. That domain typically has internal DNS zones that should not be publicly resolvable, recursive resolvers with access to internal authoritative zones, and different filtering, logging, or visibility policies.
When the VPN connects, the system now has at least two DNS contexts: the local network DNS, often ISP or home router based, and the VPN-provided DNS, which can resolve internal names via private infrastructure.
The operating system must decide which DNS queries go where.
That decision is not defined by the DNS protocol itself. It is implemented by the OS stub resolver and the VPN client.
How DNS routing decisions are made
Different operating systems handle this differently, but the same high-level inputs usually exist.
Interface and routing priority
Many systems associate DNS servers with specific network interfaces. When multiple interfaces are active, the OS applies routing or priority rules to decide which interface is preferred for DNS.
This is why simply connecting a VPN can immediately change DNS behavior, even if no application settings were modified.
Tunnel state
VPN clients often modify DNS configuration dynamically by adding new resolvers, reordering existing resolvers, or installing routing or name-based rules. These changes usually occur when the tunnel transitions from down to up, or vice versa. DNS behavior can change mid-session as a result.
Destination domain
Some VPN configurations define domain-based rules. For example, queries for corp.example go to VPN DNS while all other queries go to local DNS.
This is split DNS in its most explicit form. It is commonly implemented using OS-specific mechanisms, such as Name Resolution Policy Table (NRPT) rules on Windows or scoped resolvers on macOS.
Why internal names resolve only when the VPN is up
Internal names usually exist only within private DNS zones. The public DNS hierarchy has no knowledge of them.
When the VPN is disconnected, queries for internal names are sent to public or ISP resolvers, and those resolvers return NXDOMAIN or no answer. When the VPN connects, the OS routes those same queries to internal resolvers, and the names now resolve successfully.
Nothing about the names themselves changed. Only the path the DNS questions took.
Why public names may resolve through private resolvers
This is one of the most surprising behaviors for users.
If a VPN-configured resolver becomes the system’s preferred DNS server, all queries may be routed through it, not just internal ones. That includes public domains.
This happens when the VPN client installs a default DNS resolver, domain-based exclusions are not configured, or the OS prioritizes the VPN interface for DNS.
From the client’s perspective, this is valid behavior. From the user’s perspective, it feels unexpected.
It is also why DNS visibility and filtering policies can change immediately when a VPN connects.
Why DNS behavior changes mid-session
DNS decisions are made per query, not per application session.
When a VPN connects or disconnects, resolver order may change, cached answers may remain until TTL expiration, and new queries may take a different path than earlier ones.
This leads to mixed behavior: existing connections continue using previously resolved addresses, new connections resolve names differently, and failures appear intermittent.
For instance, a user connects to a VPN, opens a new browser tab, and sees different resolution behavior than an already-open tab accessing the same internal service.
None of this violates DNS specifications. It reflects how stub resolvers and caches operate in real systems.
Policy-based DNS routing at a high level
Policy-based DNS routing means that DNS queries are dispatched according to rules, not just a single default.
Those rules may consider interface, tunnel state, domain suffix, or OS-specific resolution policies.
Importantly, this logic lives outside the DNS protocol. It is part of the client and operating system networking stack.
An additional layer: encrypted DNS in applications
Modern browsers and applications may use DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) with resolvers configured independently of the operating system.
When this happens, DNS queries may bypass OS-level resolver selection entirely, VPN-installed DNS policies may not apply, and an additional, application-controlled split namespace is introduced. This can result in DNS behavior that differs not only by network interface or tunnel state, but also by application. In these cases, DNS routing decisions are no longer centralized at the OS level.
Why this behavior feels unintuitive
Most people think of DNS as a lookup table. In reality, it behaves more like traffic routing: the same question can take different paths, different resolvers can give different answers, and the path can change while the system is running.
VPNs and encrypted DNS make this visible by introducing overlapping and sometimes competing DNS decision layers.
Summary
Split-network environments change how DNS works because queries are directed by policy, not sent down a single path. VPNs introduce additional namespaces and resolvers. Operating systems apply policy to decide where each query goes. Applications may apply their own DNS routing independently.
When multiple trust boundaries coexist, DNS stops being a single pipeline and becomes a decision engine.