Windows NRPT Split-DNS: Inspect Effective Name Resolution Policy

The Windows Name Resolution Policy Table (NRPT) lets the DNS Client apply namespace-specific behavior to queries. It is commonly used with enterprise VPN profiles and DirectAccess-style deployments to send selected internal names to designated DNS servers or apply policy to a namespace while ordinary names continue to use interface configuration. When split DNS breaks, a connected VPN and a populated adapter DNS list do not prove that the intended namespace policy is active.

NRPT is evaluated by the Windows DNS Client path. Applications that use their own DNS implementation can bypass it. Microsoft specifically notes that nslookup does not use the Windows DNS API for this policy path and recommends Resolve-DnsName to test NRPT behavior. That difference explains many misleading reports: the built-in client works while a troubleshooting command appears to use another resolver, or the reverse.

Separate NRPT from interface DNS configuration

Interface DNS settings describe resolver addresses and suffixes associated with network interfaces. NRPT is a namespace policy that can add behavior for matching names. VPN profile routes decide which network paths carry traffic; NRPT decides how Windows DNS should treat queries for configured namespaces. These are independent controls. A query can select the expected DNS server but fail because the route to it is missing, or route correctly while the wrong resolver is selected.

An NRPT rule represents a namespace and associated settings. Before sending a query, the DNS client checks policy for the query name; response processing can also be subject to policy. If there is no applicable NRPT rule, ordinary interface resolver and suffix behavior applies. Domain-name entries can be fully qualified names or suffixes. In VPN profile configuration, a leading period is used to express a suffix rule, so .corp.example is not a cosmetic spelling difference from corp.example.

Policy may come from Group Policy, a VPN profile provisioned through the VPNv2 Configuration Service Provider, or another supported management mechanism. A user-scoped profile and an all-user/device profile can have different behavior. A policy delivered by MDM may not be visible in the same management surface as a local VPN profile. Identify the authoritative source and its scope before editing local state; otherwise, a refresh can overwrite the local repair or leave two owners fighting over the same namespace.

Capture effective policy before making changes

Collect the effective NRPT table, relevant namespace entries, adapter DNS configuration, VPN profile scope, and current connection state. Save the output before clearing caches or reconnecting. Use the same user context that reports the failure and note whether the machine is connected to the VPN or corporate network.

$namespace = '.corp.example'

Get-DnsClientNrptPolicy -Effective |
    Format-List Namespace, NameServers, DirectAccessDnsServers,
        DnsSecValidationRequired, QueryPolicy

Get-DnsClientNrptPolicy -Effective -Namespace $namespace | Format-List *
Get-DnsClientServerAddress | Format-Table InterfaceAlias, AddressFamily, ServerAddresses -AutoSize
Get-NetIPConfiguration | Format-List InterfaceAlias, InterfaceIndex, IPv4Address,
    IPv6Address, DNSServer, NetProfile

Get-VpnConnection -ErrorAction SilentlyContinue |
    Select-Object Name, ServerAddress, ConnectionStatus, SplitTunneling, DnsSuffix
Get-VpnConnection -AllUserConnection -ErrorAction SilentlyContinue |
    Select-Object Name, ServerAddress, ConnectionStatus, SplitTunneling, DnsSuffix

Get-DnsClientNrptPolicy -Effective asks Windows for the current effective policy; do not confuse it with a configuration file or the rules that a management system intends to deploy. The namespace-filtered query narrows output to the suffix being tested. Compare configured DNS servers to the intended internal resolvers and check their IP routes and interface association. An NRPT rule can be present even when the VPN tunnel is disconnected, depending on the profile and management design; verify effective state during the failure, not only after reconnecting.

For Group Policy evidence, collect gpresult from the affected device/user scope and inspect the configured Name Resolution Policy under the applied policy set. For an MDM-delivered VPN profile, export the relevant management configuration through the approved device-management process and compare its DomainNameInformationList entries with the effective policy. Avoid editing the registry directly; the registry is implementation state, not the supported control plane for a centrally managed profile.

Test with a Windows DNS API client

Use fully qualified internal and public names, and query without a -Server override so the Windows DNS Client can apply policy. Resolve-DnsName can show the response and resolver behavior. Query one name inside the intended suffix, one sibling or parent name, and one public name to detect an overly broad rule.

$tests = @(
    'files.corp.example',
    'corp.example',
    'www.example.net'
)

foreach ($name in $tests) {
    Write-Host "=== $name ==="
    Resolve-DnsName -Name $name -Type A -DnsOnly -ErrorAction Continue
}

Get-DnsClientCache |
    Where-Object { $_.Entry -like '*.corp.example' } |
    Select-Object Entry, Type, Data, Status, TimeToLive

Do not add -Server to the diagnostic query unless intentionally testing a particular DNS server directly; a direct-server test is a different question than whether NRPT selects and uses the expected resolver. Likewise, comparing nslookup with Resolve-DnsName can demonstrate client-path differences, but the former is not the acceptance test for NRPT. If an application embeds a resolver, test its documented resolver behavior separately.

Use packet capture, firewall logs, or DNS server query logs to confirm the request reached the expected server and the response returned. A successful Resolve-DnsName result alone may have come from cache. Capture cache state and perform a targeted cache flush only when appropriate and approved, then repeat the same query. Flushing all DNS cache entries changes diagnostic state and may increase resolver traffic; it is not a harmless first step on a busy endpoint.

Trace common split-DNS failure patterns

If internal names resolve to public addresses, inspect the matching effective NRPT rule, configured name-server list, suffix spelling, VPN profile scope, and the path to the internal resolver. Confirm that the queried FQDN actually matches the intended namespace. A short name can undergo suffix search behavior and produce different queries than the fully qualified name; test each explicitly.

If internal queries time out only while on VPN, confirm the tunnel’s route to the policy DNS servers, interface status, resolver reachability, and VPN connection state. Check address-family differences as well; IPv4 can work while IPv6 chooses a different route or resolver. Compare the DNS server returned by policy with the routes and firewall rules that should permit it. Do not switch every interface to the internal DNS server just to make one suffix work, because that changes public and local name behavior as well.

If the policy query returns the right answer but one application fails, determine whether that program calls the Windows DNS API, has a browser secure-DNS feature, uses DNS over HTTPS, has an embedded resolver, or caches answers independently. A browser’s encrypted DNS setting can intentionally use a resolver outside OS policy. Treat that as an application policy boundary and coordinate with the application/security owner instead of assuming NRPT is broken.

If one user is affected while another on the same machine is not, compare per-user and all-user VPN profiles, user policy, logon state, and the user’s effective NRPT table. If every device is affected after a policy change, compare the deployed profile or GPO version and management sync time. A local registry edit on one device can temporarily mask central policy drift, but will not correct the source of truth.

If public names fail while internal names work, test whether a broad namespace rule captures too much, whether DNS server reachability is asymmetric, and whether policy-specific validation or response processing is involved. Compare a public FQDN with a private suffix and inspect the exact effective namespace output. Avoid assuming that the “first DNS server” shown in an adapter GUI is the server for every query; NRPT can choose behavior by name.

Update policy through its owning control plane

For a VPNv2 profile, the DomainNameInformationList contains namespace rules and associated DNS servers. The domain name can be an FQDN or a suffix; VPN profile CSP documentation defines the syntax and scope. Update the profile through the MDM solution or a supported profile-management method. For Group Policy-managed NRPT, edit and deploy the owning policy. Avoid configuring overlapping rules through multiple independent sources unless their interaction has been deliberately designed and tested.

Before rollout, export current profile and policy state, list namespaces, name servers, security/validation flags, scope, and change owner. Pilot the policy on a test device with both VPN connected and disconnected states. Test name matching at the suffix root, subdomain, sibling domain, short name, and public namespace. Verify that routes reach the chosen resolver and that the application’s DNS stack obeys the intended OS policy.

Be careful with DNS security behavior. NRPT can include validation or IPsec-related policy fields for specific deployments. Do not disable DNSSEC validation, IPsec protection, or secure-query requirements as a generic way to get an answer. Determine which rule sets the requirement, which resolver supports it, and whether the server response satisfies the policy. A security-policy failure can look like ordinary resolution failure while indicating that the configured trust requirement is doing its job.

After deployment, compare the effective table with the intended profile and run the same test script. Record policy version, device sync time, connection state, name, query type, answer, and resolver evidence. If the effective policy does not change, troubleshoot management delivery and scope before editing the endpoint manually.

NRPT incident checklist

Capture effective NRPT, VPN scope/state, interface DNS, routes, and policy source before flushing caches.
Test fully qualified internal and public names with Resolve-DnsName and no explicit server override.
Remember that applications with custom DNS and nslookup may bypass the Windows NRPT path.
Separate namespace match, resolver selection, network reachability, answer, and application cache.
Change rules through the GPO or MDM/VPN profile that owns them; avoid direct registry repair.
Pilot suffix boundaries, IPv4/IPv6, VPN connected/disconnected, and rollback behavior.

NRPT makes Windows DNS behavior depend on the name being queried, not just the interface’s resolver list. Accurate diagnosis starts with the effective rule for that exact namespace and a test client that uses the Windows DNS API, then separates policy from routing, server reachability, cache, and application-specific resolution.

Related:

Sources: