Two VPNs, One Resolver: Whichever Wrote Last Wins

Two VPN clients are connected, one for work and one for a lab network, and internal names resolve only for the client that connected last. That pattern looks like a bug in one of the clients. It is usually the predictable result of two programs writing the same resolver configuration with no agreement about who owns which name.

The myth: the newest VPN owns DNS

There is no general rule that the most recent connection wins. What happens depends on the platform mechanism and on how each client writes it. A client that replaces a resolver file produces one outcome; a client that adds a per-link domain produces another; a client that does nothing leaves the previous state intact.

So the observed behavior is a property of the two implementations, not a documented priority. Reasoning about it from launch order alone will be right sometimes and wrong in ways that are hard to reproduce. Write the mapping down instead. A design that lives in two clients is not a design.

Map namespaces to resolvers

List the private suffixes and the resolver each network requires, then decide where public names should go. That list is the design. Without it, the clients are making the decision by accident.

A platform that supports per-link DNS or routing domains can express the split deliberately: one domain goes to one link, another domain to the other, and everything else follows an explicit default. Two flat scripts overwriting the same file cannot preserve that design, because each one believes it owns the whole configuration.

On Windows, the name resolution policy table can direct suffixes to specific servers, and a VPN client may install rules there. Check the policy rather than the adapter list, because the adapter list is not what resolves the name.

Keep a bootstrap path

Each client must locate its own endpoint before it can use the service that endpoint provides. If the endpoint hostname can only be resolved through the tunnel, and the tunnel needs the hostname resolved, you have a circular dependency that appears as a connection timeout. Keep one bootstrap path outside both tunnels. It costs nothing until the day it saves the connection.

Look at the path to each resolver, not only the name configured for it. A resolver that is reachable only through the other tunnel behaves like one that is missing, and the symptom is a timeout rather than a routing error.

Overlapping addresses are not a DNS problem

Two private networks using the same address range cannot be fixed by DNS order. If both tunnels claim 10.0.0.0/8, a name that resolves correctly still points at an address the host cannot route to the right tunnel. That needs an address-level solution such as distinct ranges, a namespace, or translation, not another resolver setting. Deciding this early prevents a long detour through DNS configuration that was never going to work.

Compare the address assignments of both tunnels before blaming name resolution. When both peers push the same prefix, the host keeps one route for it, and a name resolved through the second tunnel still lands on an address the first tunnel owns. Distinct ranges, a namespace per network, or translation are the fixes; after each client connects, confirm the route table shows the path you intended.

Prove it with real applications

Pick two hosts that exist only inside their own namespace and one public name, then resolve each through the client that should own it. A correct answer from the expected resolver does not prove the application reaches the host, because the route to that address can still fail. Follow each lookup with a connection test from the program the user will actually run.

A client with its own encrypted DNS option can bypass the policy you just verified, so check that setting as part of the review. Then reconnect both clients in the order the vendor supports and repeat the lookups; if the answers swap when the order changes, a competing writer still owns part of the configuration. Find which component installs the rule - the client, the OS profile or a management agent - before editing anything. Record the order and the owners so the next person does not rediscover them.