Split DNS over OpenVPN: what a routing domain must do on each OS

Every split-DNS request starts with the same sentence: company names go to company DNS, everything else keeps working. Turning that sentence into a configuration means answering three questions per operating system, and the answers use different mechanisms on each one. Profiles that work on a Linux laptop often fail on Windows for reasons that have nothing to do with the tunnel. The gap is usually a resolver setting mistaken for a route.

Name the policy first, then pick the platform primitive that expresses it.

Three settings that are easy to confuse

A search suffix expands a short name: typing files becomes files.corp.example when the resolver tries suffixes in order. A routing domain selects which resolver answers queries inside a namespace. An IP route only makes the chosen resolver reachable. Those three live in different layers, and swapping one for another produces a configuration that looks right and resolves nothing.

The confusion has a cost: adding a search suffix sends every short name to the work resolver, including names that belong elsewhere. Selecting a routing domain keeps unrelated queries on the local resolver while still sending *.corp.example through the tunnel.

Linux: a route-only domain, not a search suffix

On systemd-resolved, a domain prefixed with a tilde is a route-only domain, which means queries for that namespace go to the linked resolver without also becoming a search suffix. resolvectl domain tun0 '~corp.example' sets that, and resolvectl dns tun0 10.8.0.1 names the server. Both settings belong to the interface, so they disappear with it. The tilde is the part people omit, and without it short names start resolving through the work resolver.

Do not also install the same domain as a global search suffix. The two settings are not redundant; one routes and the other rewrites what you typed.

Windows needs a namespace policy, not a suffix

Windows keeps split-DNS policy in the Name Resolution Policy Table, not in the adapter's DNS suffix. A rule maps a namespace to specific servers: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. Setting the suffix alone changes what short names look like; it does not direct the query to a different server.

Check the effective policy with Get-DnsClientNrptPolicy after connecting, because a rule from an earlier connection can outlive the tunnel. Remove rules by name when the tunnel goes down, and keep the display name stable so cleanup targets the right entry.

Keep one resolver owner per platform

A desktop manager, an OpenVPN up script and a local resolver daemon can all try to write the same configuration. When they disagree, the last writer wins and the result depends on teardown order. Pick one component to own resolver state, let the others report rather than write, and test a reconnect: the policy should survive it without duplicating rules. Test a disconnect too, since leftover state is what makes the next connection behave differently.

Applications that ship their own encrypted resolver ignore the operating system's policy entirely. That is a property of the application, not a defect in the tunnel.

Verify the result, not the profile text

Resolve one name that should go through the tunnel and one that should not, on each platform, and confirm which server answered. resolvectl query host.corp.example and Resolve-DnsName host.corp.example both report the server that responded. Repeat after a reconnect. Then confirm the tunnel's resolver is reachable at the address the profile pushes, because a correct policy pointing at an unreachable server fails the same way as no policy at all.

Record the intended behaviour in the profile's notes: which suffix routes, which server answers it, and what happens to everything else. The next platform you support will need that sentence more than it needs the config file.