Azure DNS Private Resolver: Hybrid DNS Runbook

Azure DNS Private Resolver gives Azure admins a managed way to resolve DNS between virtual networks, Azure Private DNS zones, on-premises networks and other private environments, without running DNS forwarder VMs across the hybrid boundary. Fewer servers to patch, and fewer DNS servers everyone is afraid to reboot.

This runbook covers the components, the two main hub-and-spoke designs, the rollout order, and the failure patterns to test before production, focusing on Azure workloads resolving on-premises names and on-premises clients resolving Azure Private DNS records.

Azure DNS Private Resolver in one minute

A private resolver is deployed into one Azure virtual network, and its components have different jobs:

• Inbound endpoint: a private IP that on-premises DNS servers or other private networks can query. It resolves through Azure DNS and answers for Private DNS zones linked to the resolver VNet.
• Outbound endpoint: the managed egress path for forwarding queries to on-premises, another cloud or a custom DNS service.
• DNS forwarding ruleset: suffix-based forwarding rules. When several suffixes match, the longest match wins.
• Ruleset VNet link: makes the ruleset apply to a VNet. Microsoft notes the linked VNet doesn’t need to be peered with the resolver VNet just for ruleset-based resolution.

Choose the architecture first

Microsoft documents two hub-and-spoke patterns. The right one depends on whether spokes keep Azure-provided DNS or send all DNS to a central inbound endpoint.

A safe deployment sequence

1. Confirm region, network and address constraints

Put the resolver in the same region as its VNet and check Azure DNS regional availability. Microsoft also lists constraints: a resolver references one VNet, multiple resolvers can’t share a VNet, and IPv6-enabled endpoint subnets, VNet encryption and ExpressRoute FastPath aren’t supported.

Each endpoint needs its own subnet, delegated only to Microsoft.Network/dnsResolvers, sized between /28 and /24. Nothing else goes in those subnets.

2. Deploy only the endpoints you need

Create an inbound endpoint when another private network must query Azure DNS, and an outbound endpoint when Azure must forward namespaces elsewhere. Many hybrid setups need both, but let requirements decide.

An inbound endpoint can use a static or dynamic private IP. Dynamic allocation normally takes the fifth available address and generally stays stable unless the endpoint is reprovisioned. For on-premises conditional forwarders, a deliberately chosen static address makes ownership clearer. Either way, document it as a dependency.

3. Link the right Private DNS zones

Link the resolver VNet to each Private DNS zone the inbound endpoint should resolve; it can’t discover zones on its own. Then configure an on-premises conditional forwarder for the Azure namespace, targeting the inbound endpoint IP, and make sure DNS traffic is allowed across VPN or ExpressRoute.

4. Build outbound rules from the most specific suffix

Each rule specifies a dot-terminated namespace (for example corp.contoso.com.), one or more target DNS servers, a port, and UDP or TCP. The longest matching suffix wins, so secure.corp.contoso.com. beats corp.contoso.com..

Avoid a wildcard . rule unless the target resolves public names and you’ve tested the dependency; Microsoft warns some Azure services need public resolution. Never use 168.63.129.16 as a rule target; the service rejects it.

5. Link the ruleset to consumer VNets

In a distributed design, link the ruleset to each VNet that should use it. Links are regional but can cross subscriptions. Keep an inventory, because a perfect rule does nothing for an unlinked VNet.

Loop warning: if a rule forwards a private zone to the resolver’s own inbound endpoint, don’t link that ruleset to the VNet containing the inbound endpoint. The query will loop back on itself.

Azure DNS Private Resolver validation runbook

Test one direction at a time and record the query source and resolver used. A lookup from an admin laptop proves little about a workload VNet.

• Azure to on-premises: query an on-premises record from every linked workload VNet.
• On-premises to Azure: query an Azure private-zone record through the conditional forwarder.
• Negative response: query a nonexistent record and confirm NXDOMAIN.
• Public DNS: check public dependencies, especially after adding a wildcard rule.
• Failure path: make a target DNS server unavailable and watch client timeouts and retries.
• Configuration recovery: prove the resolver, endpoints, rules and links can be redeployed from code.

Use Resolve-DnsName or nslookup on Windows, or dig on Linux, naming the server when you need to isolate a path. Capture the query name and type, the client network, the answering server, the response code and address, the elapsed time, and the rule or zone link you expected to handle it.

Troubleshooting by symptom

Reliability: managed isn’t design-free

Azure DNS Private Resolver is automatically zone-redundant in regions with availability zones, but it’s still a single-region service. For regional resilience, Microsoft recommends resolvers in separate regions with forwarding designed for failover.

The service is stateless, so your recoverable asset is configuration: resolver, subnets, endpoints, rulesets, rules and links. Keep them in Bicep, Terraform or ARM and test redeployment. Microsoft also advises clients to retry transient failures, typically with two-to-five-second timeouts, and to pick TTLs that balance query volume against failover speed. Pair the design with Azure Service Health alerts.

Service limits for design reviews

• 15 private resolvers per subscription.
• 5 inbound and 5 outbound endpoints per resolver.
• 1,000 forwarding rules and 500 VNet links per ruleset.
• 2 outbound endpoints per ruleset and 2 rulesets per outbound endpoint.
• 6 target DNS servers per rule.
• 10,000 queries per second per endpoint.

These were Microsoft’s published limits as of September 2026. Limits change and the portal can lag, so recheck the official overview before a large rollout.

Recommendation

Start with one hub resolver and a narrow pilot. Use distributed ruleset links when spokes can keep Azure DNS and only need selected namespaces forwarded; use centralized custom DNS when policy requires all spoke DNS to pass through the hub, and accept the larger failure domain. Keep rules specific, avoid wildcards without a documented reason, prevent loops, and manage it all as code. Related: Azure AI Foundry private endpoints, which depend on exactly this kind of private DNS.

Last reviewed: October 2026

Sources

• Azure DNS Private Resolver overview (Microsoft Learn)
• Private Resolver endpoints and rulesets (Microsoft Learn)
• Hybrid DNS between Azure and on-premises (Microsoft Learn)
• Private Resolver architecture (Microsoft Learn)
• Create Azure DNS Private Resolver in the portal (Microsoft Learn)
• Reliability in Azure DNS Private Resolver (Microsoft Learn)