Why Windows sends your VPN names to a DNS server you never set

You set the DNS server on the VPN adapter, reconnected, and the private name still comes back from the office resolver that nobody configured on this laptop. That result looks like the setting was ignored, and in a sense it was, because the adapter list is a candidate set rather than a decision. Windows resolves names through a namespace policy that can name a different server for a specific suffix, and that policy is applied before the adapter setting is consulted. Finding the rule that won is a five-minute job once you know which table to read.

What you changed, and what actually decides

The DNS address on an adapter tells the client where that interface could send queries. The Name Resolution Policy Table tells the client where it must send queries for a given namespace, and it is evaluated per name, not per adapter. When a rule matches the suffix you typed, the rule's servers are used and the adapter list stops mattering for that lookup.

This is why two names on the same laptop can follow different paths at the same moment. A host under the corporate suffix follows its rule; a public name follows the default path, which usually means whichever adapter answers first.

How the table matches a name

Rules are keyed by namespace, and the most specific match wins. A rule for corp.example applies to vpn.corp.example and does not apply to example.net. A rule with the namespace . covers everything the other rules do not, which makes it the most dangerous entry on the list and the one worth checking when an unrelated site resolves through the tunnel.

A rule can also carry a comment, a policy that disables the entry, and security settings that have nothing to do with DNS addresses. A disabled rule stays visible in the configuration while having no effect, so an entry that looks right on paper can still be inert after a profile change.

Read the effective table, not the wish list

Configured rules and effective rules are two different questions. Get-DnsClientNrptRule lists what exists on the machine. Get-DnsClientNrptPolicy -Effective shows what the client will actually apply, with the values merged from policy and local settings.

Compare the suffix in that output with the name you are testing, character for character. A rule for corp.example does not capture a name ending in corp.example.com, and a trailing dot in one place and not the other is enough to change the match.

With no rule, Windows asks more than one adapter

When nothing in the table claims the name, the client can send the query out through several interfaces and take the first answer that arrives. The result is timing-dependent: the same name can resolve from the wired adapter on Monday and the tunnel on Tuesday, and nothing in either adapter's configuration explains the difference.

Two ways out exist. Add a rule for the namespace so the decision stops being a race, or turn the parallel behaviour off through the DNS client policy and accept the slower, deterministic resolution. The first is usually the better fit for a split-tunnel VPN, because it documents intent instead of relying on order.

Paths that skip the resolver entirely

A browser with secure DNS enabled resolves on its own and hands Windows only the address, so the rule table never sees the name. Clients built on runtimes with their own resolver can behave the same way. When a name resolves in one application and fails in another on the same machine, compare the two resolution paths before touching policy.

Also check whether the app is connecting to a cached address from an earlier session. Clear-DnsClientCache and then the same lookup gives a cleaner answer than inferring from a stale result.

Test with the name that failed

Resolve the exact hostname from the report, not a public speed-test domain, and note which server answered. Then change one thing: the rule, the adapter list, or the policy assignment, and repeat the identical lookup after a reconnect so the applied state is rebuilt.

If the name resolves and the service still refuses, stop editing DNS. The next useful step is the address and the route to it, because name resolution has already done its job.