Which Link Answers: Routing Domains for Split-Tunnel VPN DNS

Keep ordinary browsing on the local link while company names resolve through the DNS server the tunnel supplies. Turning off the VPN's default route gets you the first half and leaves the second half unbuilt. What follows is the missing setting, the punctuation that changes what it means, and the one command that shows which link actually answered. NetworkManager and systemd-resolved are assumed throughout, because that pair is where the confusion usually starts.

Step one: separate the route from the resolver

ipv4.never-default answers a routing question, stopping NetworkManager from installing this connection as the path for all IPv4 traffic. A DNS routing domain answers a different question: which link's name servers receive a query for a matching suffix. Neither one implies the other, and a profile can carry one for years while missing the other. Route-only means the tunnel carries company subnets and its resolver answers company names, with everything else left alone.

Set the route property alone and internal names fail, usually with a timeout that reads like a broken tunnel. Set the domain alone and you have quietly added a search suffix to every short name on the machine. Both mistakes send the ticket to the VPN server, which is rarely the part that is wrong.

Step two: add a routing-only domain to the profile

Assume the connection is called corp-vpn, the company suffix is internal.example, and the tunnel's resolver is already reachable. Read the current values first, because the commands below change properties that may already carry entries.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Substitute your own connection name and suffix, because the values above are illustrative. The plus sign matters more than it looks: with it the value is appended to the existing list, while without it the property is replaced and unrelated domains vanish from a profile that worked yesterday. The tilde changes behaviour rather than style, and the paragraph below covers what it selects. Keep the read before the write, so the replacement form never surprises you.

A leading tilde marks a routing-only domain, so matching queries go to this link's servers and the suffix is not appended to short names. Drop the tilde and the same string also becomes a search suffix, which is a different outcome that people rarely intend. Both settings above are IPv4, so a dual-stack profile needs ipv6.never-default and the same routing domain in ipv6.dns-search, or the IPv6 side keeps using the default route and internal names fail there.

Step three: ask resolvectl which link answered

Run resolvectl status and read each link's DNS servers and domains, then run resolvectl query host.internal.example against a real internal name you are permitted to query. The second command is the only direct evidence that the routing domain is doing its job, because it names the link that answered. A status listing alone proves configuration; the query proves resolution.

systemd-resolved selects the best matching routing domain, so a more specific domain on another link can still win the race. If the query comes back from a link you did not expect, read the domain lists before touching the VPN's DNS server. A root domain of ~. matches everything, and if it is already present your specific domain still wins for its own names while the link answers far more than you asked. Remove or narrow that root entry when the intent was company names only.

If the VPN link lists no DNS server at all, the client never registered one. A routing domain with no server behind it fails differently from a missing domain, so fix registration first.

Step four: when the name resolves but the service does not

A correct answer only proves that resolution worked, and the application still needs a route to the address it received. That route has to survive the split default you just configured, so check it before blaming DNS again. Then check reachability on the service's port, because a file share or directory service fails on resolution, routing or authentication and produces very similar messages in each case. Keep those three layers separate when you report the outcome, or the next person re-checks DNS that was already correct.

The Samba change that circulates alongside this question addresses the access layer, not the DNS choice. Applying it to a name-resolution fault is how a small problem acquires a second one.

Step five: do not replace the resolver to fix a missing domain

Advice that overwrites the resolver file or installs a different resolver manager solves a different problem. Those are system-integration changes with their own failure modes, and none of them adds a routing domain that was never configured. Establish which component owns name resolution on the machine before replacing it, because on a NetworkManager desktop with systemd-resolved that ownership is already defined. Fighting it is how a working setup turns into something nobody can reproduce.

Order of work: confirm the tunnel supplies a resolver, add the routing-only domain, reconnect through the profile controls, verify the answering link, then test the service on its port. That sequence leaves a result you can hand to the next person without a second interview.