In enterprise Windows networking, domain name resolution is frequently segmented across public internet resolvers, internal corporate Active Directory domain controllers, and private cloud virtual networks. Relying solely on static network adapter DNS addresses often causes DNS leakage or connection timeouts when resolving internal hosts over split-tunnel VPNs. To resolve this, Windows 11 incorporates the Name Resolution Policy Table (NRPT), a kernel-level rule table that intercepts DNS queries and routes them to designated nameservers based on specific domain namespaces.
In this guide, you will learn how to inspect, create, modify, and remove NRPT rules in Windows 11 using PowerShell DnsClient cmdlets.
Understanding the Name Resolution Policy Table (NRPT)
The NRPT operates directly within the Windows DNS Client service (Dnscache). Unlike traditional adapter-specific DNS server lists, the NRPT evaluates the fully qualified domain name (FQDN) of every outbound DNS request before dispatching packets onto the network wire.
When an application attempts to resolve an address (for example, server01.corp.contoso.com), the DNS Client queries the NRPT:
- Namespace Matching: If the requested domain matches a rule prefix (such as
.corp.contoso.com), Windows routes the query exclusively to the designated enterprise DNS servers defined in the rule. - DNSSEC Enforcement: NRPT rules can mandate cryptographic DNSSEC validation, rejecting unauthenticated or spoofed replies.
- DirectAccess and VPN Segregation: NRPT rules ensure internal traffic remains enclosed within secure VPN tunnels while general web traffic (such as
www.microsoft.com) resolves directly through the local internet service provider.
Inspecting Existing NRPT Rules in PowerShell
To audit existing policy rules on your Windows 11 device, launch an elevated PowerShell console (Run as Administrator) and execute Get-DnsClientNrptRule:
Get-DnsClientNrptRule | Format-List
To inspect active rules currently enforced by the DNS Client resolver (combining local registry policies with Group Policy Object distributions), use Get-DnsClientNrptPolicy:
Get-DnsClientNrptPolicy -Effective | Format-Table -Property Namespace, NameServers, DnsSecValidationRequired -AutoSize
If no rules are currently configured, the command returns empty, indicating that Windows 11 uses the default DNS servers assigned to the active physical or Wi-Fi network interface.
Creating a New NRPT Rule for a Domain Namespace
To direct all resolution requests for a specific corporate domain to dedicated internal DNS nameservers, use the Add-DnsClientNrptRule cmdlet.
For example, to route all queries targeting *.corp.internal to DNS servers 10.10.0.10 and 10.10.0.11:
Add-DnsClientNrptRule -Namespace ".corp.internal" -NameServers "10.10.0.10", "10.10.0.11" -Comment "Corporate Split-DNS Policy"
Notice the leading period in .corp.internal. The leading period acts as a wildcard, ensuring that all subdomains (such as git.corp.internal and db.prod.corp.internal) match the rule.
Verify that the rule is registered:
Get-DnsClientNrptRule | Where-Object { $_.Namespace -eq ".corp.internal" }
Enforcing DNSSEC Validation on Specific Namespaces
For high-security zero-trust domains, you can enforce DNSSEC cryptographic validation. If a matching DNS response lacks valid DNSSEC cryptographic signatures or fails authentication checks, Windows rejects the resolution.
To add an NRPT rule requiring strict DNSSEC validation:
Add-DnsClientNrptRule -Namespace ".secure.enterprise.com" -NameServers "172.16.5.1" -DnsSecValidationRequired $true -DnsSecQueryIPsecEncryption "None"
Confirm the security settings of the created rule:
Get-DnsClientNrptRule | Where-Object { $_.Namespace -eq ".secure.enterprise.com" } | Select-Object Namespace, DnsSecValidationRequired, NameServers
Modifying an Existing NRPT Rule
Each NRPT rule is tracked internally by a unique Globally Unique Identifier (GUID) stored in the Name property. When you need to update server IP addresses or enable new security flags, retrieve the rule object or use Set-DnsClientNrptRule:
# Retrieve the rule name identifier
$rule = Get-DnsClientNrptRule | Where-Object { $_.Namespace -eq ".corp.internal" }
# Update the target DNS servers and add DNSSEC validation
Set-DnsClientNrptRule -Name $rule.Name -NameServers "10.10.0.10", "10.10.0.12" -DnsSecValidationRequired $true
Confirm that the updated nameservers are applied:
Get-DnsClientNrptRule -Name $rule.Name | Format-List
Testing NRPT Resolution and Troubleshooting
Once NRPT rules are active, verify that hostname queries are routed to the designated nameservers without leaking to public resolvers.
Test name resolution using Resolve-DnsName:
Resolve-DnsName -Name "intranet.corp.internal" -DnsOnly
Examine the Server field in the output to confirm that 10.10.0.10 fulfilled the request.
If queries fail or resolve through public interfaces:
- Clear the Local DNS Cache: Flush the resolver cache to purge stale negative responses:
Clear-DnsClientCache - Inspect Group Policy Conflicts: If domain-level GPOs overwrite your local settings, check registry policy paths:
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig\*" - Verify Network Connectivity: Ensure that the designated nameserver IP is reachable over TCP/UDP port 53 via
Test-NetConnection:Test-NetConnection -ComputerName "10.10.0.10" -Port 53
Removing NRPT Rules
When decommissioning a network segment or reverting client computers to standard resolver configurations, delete the rules using Remove-DnsClientNrptRule:
# Remove a specific rule by namespace
$rule = Get-DnsClientNrptRule | Where-Object { $_.Namespace -eq ".corp.internal" }
Remove-DnsClientNrptRule -Name $rule.Name -Force
To purge all locally defined NRPT rules simultaneously:
Get-DnsClientNrptRule | ForEach-Object { Remove-DnsClientNrptRule -Name $_.Name -Force }
Flush the DNS cache after removing rules to restore standard system resolution immediately:
Clear-DnsClientCache