Two DNS Servers on One Adapter Do Not Split Namespaces

Listing two resolvers on one adapter looks like a way to send one domain to one server and another domain to the other, and nothing about the resolver list works that way. Windows resolves by name, and the decision about which server to ask comes from policy objects rather than from an ordered address list. The mental model to replace is the queue: there is no first server for domain A and second server for domain B. There is a per-namespace rule set that names the servers explicitly, and once those rules exist the adapter list stops being interesting.

The Myth: Two Addresses Split Two Domains

The belief survives because it works by accident when one server happens to answer everything and the second is only a fallback. A client asks the first server, that server forwards or recurses, and the answer arrives; nobody notices which resolver actually held the zone. The illusion breaks the moment the two namespaces live in separate private zones with no forwarding between them, because the first server then answers authoritatively that the name does not exist. A negative answer from the first server is not a fallback trigger, since the client received a definitive response rather than a failure.

An ordered list has no concept of a domain, so it cannot express the intent. What the list really controls is which server is asked first and which one is tried second, and both of those answers apply to every name equally.

What Windows Actually Uses to Choose

The Name Resolution Policy Table matches a name against configured namespaces and selects the servers and options for that match. Rules can be configured locally, delivered by Group Policy, or supplied by a VPN profile, and the effective policy is a combination rather than a single list. That is why the first diagnostic is always the effective state: a locally created rule that loses to a managed policy produces a lab that behaves nothing like its configuration suggests. Rules are also matched by specificity, so a broad namespace entry can overshadow a narrow one in ways that are invisible in a list of configured items. Reading the effective order is the only way to see which rule wins.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

The first command lists what is configured on the machine; the second shows what the client will actually apply, including entries that came from elsewhere. If the effective output contains managed namespaces, the owner of that policy is the correct place to request the change, not the local rule list. Both commands only read state, so running them before anyone agrees on the change costs nothing.

One Rule Per Namespace, Keep the Object

With the effective state understood, create one rule per namespace and preserve the object each command returns. Display names are labels for humans, and the unique identifier in the returned object is the reliable deletion target afterwards. Write both identifiers into the same change note that records the namespaces and resolvers, because the session that created them will not be the session that cleans up.

$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers

The leading dot marks a suffix match, so the rule covers app.svc.internal.example and anything else beneath it. The two addresses here belong to this lab's own routing plan; a rule does not create a zone, install a route or authorise the application that eventually connects, and the Add-DnsClientNrptRule reference documents exactly which parameters do what.

Note what these commands do not do: they are machine-wide, they are not scoped to a VPN session, and they survive closing the window. A lab that forgets this leaves policy behind after the tunnel is gone.

Prove the Client Chose the Server

Asking a specific server whether it knows a name proves that the server can answer, which is not the same claim as the client choosing that server. The test that matters resolves a real name through the ordinary client path and then confirms which resolver handled it, ideally while the tunnel that supplies the route is up. If the tunnel is down, a correctly scoped rule still points at an unreachable server, which is a routing problem rather than a policy problem. Test both states so the two can be told apart later.

Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile

Watch for cached answers from the period before the rules existed, and watch for applications that bypass the system resolver entirely with their own encrypted DNS. Search suffixes are another separate feature: a rule can choose a resolver for a full name without teaching Windows to expand a bare hostname into that namespace.

Remove Exactly What You Created

Cleanup is where a lab becomes a cautionary tale. Deleting every rule on the machine is fast and removes policy somebody else depends on, so use the identifiers captured when the rules were created, and re-read the effective state afterwards to confirm the machine returned to where it started. If the session that created them is gone, the change note is the only place the identifiers exist. That is the reason for writing them down before the first command runs, not after.

Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective

For a deployment rather than a lab, the lifetime question matters as much as the rule. A VPN profile can carry the namespace rules and choose whether they persist beyond the connection; a rule that persists while the resolver is unreachable leaves clients preferring a dead server, and a connection-scoped rule disappears when the tunnel does. Decide which of those behaviours the service needs, mark who owns the rule, and leave the split of authority documented next to the profile rather than in someone's memory of a lab.