Preventing DNS Split-Brain in Hybrid Azure/AD

A hybrid identity environment running Active Directory Domain Services alongside Azure Private DNS zones will inevitably encounter DNS split-brain the moment a device roams between the corporate LAN, a site-to-site VPN, and the public internet. The symptom is deceptively simple: the same FQDN resolves to two different IP addresses depending on which resolver answers the query, one from an internal AD-integrated zone, one from a public authoritative zone or an Azure Private DNS zone linked to a different VNet. The result is broken Kerberos SPN validation, TLS SAN mismatches on internal load balancers, and intermittent connectivity that is almost impossible to reproduce in a lab because it is entirely dependent on network path. This article details how to eliminate DNS split-brain deterministically using the Windows Name Resolution Policy Table (NRPT), rather than relying on brittle conditional forwarders or hosts-file hacks.

#The Problem: Namespace Collision in Hybrid Resolution Paths

In a typical hybrid estate, an organisation owns a namespace such as corp.example.com. On-premises AD DS hosts an authoritative, AD-integrated zone for that namespace. Azure Private DNS then hosts a linked zone for the same or an overlapping namespace to support Private Endpoints and Private Link resource resolution inside a VNet. When a domain-joined laptop is on the corporate network, it queries the on-prem DNS server and receives the correct internal record. When that same laptop connects over a split-tunnel VPN or via Always On VPN with force-tunnelling disabled, the client’s default adapter may send the query to a public resolver (ISP DNS, DoH endpoint, or public DNS-over-HTTPS) instead of the internal DNS server, returning either an NXDOMAIN or a public-facing IP that bypasses the private endpoint entirely.

This is DNS split-brain in its purest form: authoritative divergence based on query origin rather than record staleness. Standard remediation, adding conditional forwarders on every resolver in the path, does not scale once you introduce Azure Private DNS Resolver, ExpressRoute private peering, and multiple VNets with independent DNS configurations. The client, not the server infrastructure, needs to make the routing decision before the query ever leaves the stack.

#Architectural Breakdown: How NRPT Intercepts the Resolver Pipeline

The NRPT sits inside the Windows DNS Client service (Dnscache) and is evaluated before the standard resolver cache and before the request is handed to the configured DNS servers on the active network adapter. Originally shipped for DirectAccess to route corporate namespace queries through the IPsec tunnel, NRPT is now the correct mechanism for enforcing deterministic resolution in any hybrid Azure/Windows topology, VPN or otherwise.

Each NRPT rule is a tuple of:

• Namespace match — an FQDN, a domain suffix (with or without wildcard), or a subnet (for reverse lookups).
• DNS server list — the specific resolver(s) authoritative for that namespace, e.g. an Azure Private DNS Resolver inbound endpoint IP.
• Security flags — optional DNSSEC validation requirement or IPsec/DoH enforcement.

#Rule Precedence and the Longest-Match Algorithm

NRPT uses a longest-suffix-match algorithm identical in principle to CIDR routing table lookups. A rule for .corp.example.com will lose precedence to a more specific rule for privatelink.corp.example.com if both exist. This is the exact mechanism you exploit to solve split-brain: you carve out the Private Link and Private Endpoint sub-namespaces into their own NRPT rules pointing at the Azure Private DNS Resolver, while the broader corporate suffix continues to route to on-prem domain controllers. Anything outside the matched namespaces falls through to the adapter’s standard DNS configuration, meaning NRPT is additive and non-destructive to normal internet resolution.

#Implementation Logic: Building a Deterministic NRPT Policy

#Step 1: Audit the Overlapping Namespace

Before writing a single rule, enumerate every zone that currently answers for your corporate namespace: the AD-integrated zone, any Azure Private DNS zones linked to VNets, and public zones in Azure DNS or a third-party registrar. Use Resolve-DnsName against each authoritative server directly to map which records diverge. Any FQDN returning different A/AAAA records depending on the queried server is a candidate for an explicit NRPT rule.

#Step 2: Define Authoritative Boundaries

Assign a single authoritative resolver per sub-namespace. Do not attempt to load-balance a namespace across two different authoritative sources, that reintroduces the split-brain condition at the NRPT layer itself. If privatelink.corp.example.com is authoritative only in Azure Private DNS, every client, regardless of network path, must be forced to query the Azure Private DNS Resolver’s inbound endpoint for that suffix.

#Step 3: Push Rules via Group Policy

NRPT rules are distributed via the Name Resolution Policy GPO node (Computer Configuration Policies Windows Settings Name Resolution Policy), which writes to the registry under HKLMSOFTWAREPoliciesMicrosoftWindows NTDNSClientDnsPolicyConfig. For fleets already managed via Intune or hybrid MDM, the same policy can be delivered as a custom OMA-URI, but GPO remains the more auditable path for domain-joined estates and is what we will use here. For broader context on how these resolution boundaries fit into wider connectivity design, see our overview of architectural patterns for hybrid cloud infrastructure.

#Code and Configuration

The fastest way to prototype and validate rules before committing them to a GPO is directly on a test workstation using the DnsClientNrptRule cmdlets.

1# Force the Private Link sub-namespace to the Azure Private DNS Resolver
2# inbound endpoint, overriding whatever the active adapter would otherwise use.
3New-DnsClientNrptRule -Namespace ".privatelink.corp.example.com" `
4  -NameServers "10.20.0.4","10.20.0.5" `
5  -Comment "Authoritative Azure Private DNS Resolver - Private Link zone"
6
7# Force the broader corporate suffix back to on-prem domain controllers
8# for any client not currently on the corporate LAN (e.g. Always On VPN).
9New-DnsClientNrptRule -Namespace ".corp.example.com" `
10  -NameServers "192.168.10.10","192.168.10.11" `
11  -Comment "Authoritative AD-integrated zone"
12
13# Verify the resulting policy table and confirm longest-match ordering
14Get-DnsClientNrptPolicy | Format-Table Namespace, NameServers -AutoSize

Once validated, export the same logic into a GPO for fleet-wide enforcement. The underlying policy is stored as a set of registry multi-string values, but administrators should always author it through the GPMC Name Resolution Policy Table editor rather than hand-editing the registry, since the client parses a specific delimited format that is not officially documented for manual construction. The GPO-backed equivalent, expressed as the logical rule set applied via Set-GPRegistryValue for automation pipelines, looks like this:

1# Automating NRPT deployment across a GPO using a CI pipeline
2$GpoName = "NRPT-Hybrid-Split-Brain-Fix"
3New-GPO -Name $GpoName | New-GPLink -Target "OU=Workstations,DC=corp,DC=example,DC=com"
4
5Import-Module GroupPolicy
6Set-GPRegistryValue -Name $GpoName `
7  -Key "HKLMSOFTWAREPoliciesMicrosoftWindows NTDNSClientDnsPolicyConfigPrivateLinkRule" `
8  -ValueName "Namespace" -Type MultiString -Value ".privatelink.corp.example.com"
9
10Set-GPRegistryValue -Name $GpoName `
11  -Key "HKLMSOFTWAREPoliciesMicrosoftWindows NTDNSClientDnsPolicyConfigPrivateLinkRule" `
12  -ValueName "GenericDNSServers" -Type MultiString -Value "10.20.0.4;10.20.0.5"

On the Azure side, the resolver endpoint that NRPT clients target must be provisioned with an inbound endpoint on a delegated subnet, documented in detail in the official Azure DNS Private Resolver reference architecture. A minimal provisioning script:

1az network private-dns-resolver create 
2  --name "pdr-corp-hybrid" 
3  --resource-group "rg-network-core" 
4  --location "uksouth" 
5  --vnet-id "/subscriptions/xxxx/resourceGroups/rg-network-core/providers/Microsoft.Network/virtualNetworks/vnet-hub"
6
7az network private-dns-resolver inbound-endpoint create 
8  --resolver-name "pdr-corp-hybrid" 
9  --resource-group "rg-network-core" 
10  --name "inbound-ep-01" 
11  --ip-configurations "[{'privateIpAddress':'10.20.0.4','privateIpAllocationMethod':'Static','subnet':{'id':'/subscriptions/xxxx/resourceGroups/rg-network-core/providers/Microsoft.Network/virtualNetworks/vnet-hub/subnets/snet-dns-in'}}]"

#Avoiding DNS Split-Brain Under NRPT Rule Shadowing

The single most common cause of NRPT deployments failing to actually resolve DNS split-brain is rule shadowing, where an administrator adds a new, more specific namespace rule but forgets that an existing DirectAccess or legacy Always On VPN policy already claims a broader suffix with a different priority weighting. Because Windows silently applies longest-match without logging a conflict warning, the symptom presents as “the fix works on some machines but not others” depending on GPO processing order and cached policy state. Always audit the full effective NRPT table with Get-DnsClientNrptPolicy after every GPO change, on a genuinely representative device, not just the domain controller.

#Failure Modes and Edge Cases

NRPT is not a silver bullet, and several failure modes recur across production hybrid estates:

• Group Policy propagation lag. NRPT changes require a background gpupdate cycle (default 90–120 minutes) or an explicit gpupdate /force. During the propagation window, a subset of the fleet remains in split-brain, which can be mistaken for a failed fix rather than expected eventual consistency.
• IPv6/IPv4 rule asymmetry. If a namespace rule specifies only IPv4 name servers but the client prefers an IPv6 path (Happy Eyeballs / RFC 6555 behaviour), the query may bypass the intended resolver entirely on dual-stack networks. Always populate NRPT rules with dual-stack resolver addresses where the Private DNS Resolver supports it.
• DNS-over-HTTPS bypass. If a browser or the OS-level DoH policy is configured independently of NRPT (e.g. Chrome’s built-in secure DNS), queries can bypass the NRPT pipeline entirely, reintroducing split-brain at the application layer even though the OS resolver is correctly configured. NRPT must be paired with DoH policy enforcement (DohPolicy registry key) to be authoritative.
• Legacy DirectAccess coexistence. Estates transitioning from DirectAccess to Always On VPN frequently retain orphaned DirectAccess NRPT GPOs. These take precedence based on suffix specificity, not deployment recency, and will silently override new rules unless explicitly unlinked.
• Split-tunnel VPN egress. Even with correct NRPT rules, if the VPN adapter’s metric is lower priority than a Wi-Fi adapter also carrying a default route, some resolvers may receive the query on the wrong interface before NRPT evaluation completes on certain legacy builds pre-Windows 10 1903. Interface metric hygiene is a prerequisite, not optional.

#Scaling and Security Trade-offs

NRPT-based elimination of DNS split-brain carries clear architectural trade-offs against alternative approaches such as conditional forwarding or full DNS-over-VPN tunnelling:

• Management overhead vs. determinism: NRPT requires per-namespace GPO maintenance and is more labour-intensive to audit than a single conditional forwarder, but it guarantees deterministic client-side routing regardless of which resolver would otherwise have answered.
• Multi-forest complexity: In multi-forest or multi-tenant AD environments, NRPT rules must be scoped per-OU with WMI filters to avoid cross-forest namespace bleed; this adds GPO processing overhead on large estates (>5,000 endpoints) that should be benchmarked before rollout.
• DNSSEC enforcement: NRPT rules can mandate DNSSEC validation per namespace, which conditional forwarders on standard DNS servers cannot enforce at the client. This closes a spoofing vector for the internal namespace but requires the authoritative zone to actually be signed.
• Resolver consolidation: Routing Private Link namespaces exclusively through the Azure Private DNS Resolver reduces the blast radius of a misconfigured on-prem forwarder, but creates a hard dependency on the resolver’s inbound endpoint availability; deploy it across Availability Zones with a minimum of two IP configurations for resilience.
• Client-side attack surface: Because NRPT lives in the client registry, it is a target for privilege-escalation tampering on unmanaged or jailbroken endpoints; pair the GPO with Credential Guard and registry ACL hardening on the DnsPolicyConfig key to prevent local rule injection.