This chapter covers the Azure DNS Private Resolver, a fully managed service for resolving DNS names in hybrid and multi-network Azure environments. For the AZ-305 exam, understanding the private resolver is critical because it enables private DNS resolution across virtual networks and on-premises without deploying custom DNS servers, aligning with the 'Design for identity, security, and compliance' domain. Approximately 5-10% of exam questions touch on DNS resolution strategies, with the private resolver being a key component for scenarios involving hub-spoke topologies and hybrid connectivity.
Jump to a section
Imagine a large corporation with a private telephone switchboard (PBX) that connects internal extensions and also routes calls to and from the public telephone network. Each employee has an internal extension (private IP address) that is not reachable directly from outside. When an employee calls an external number, the switchboard temporarily assigns a public trunk line and logs the mapping. For incoming calls, the switchboard knows which extension to route to based on a directory (DNS zone). Now, suppose the company acquires a remote branch office that also has its own private switchboard. To allow employees to call each other by extension, the two switchboards must be linked via a dedicated trunk line (virtual network link). The Azure DNS Private Resolver works similarly: it is a cloud-based switchboard that can resolve DNS names across peered virtual networks and on-premises networks via conditional forwarding. It replaces the need for a manually managed DNS server in a hub VNet. The resolver listens on a private IP address (inbound endpoint), forwards queries to on-premises DNS servers (outbound endpoint with rules), and caches results to reduce latency. Just as a PBX can have multiple trunks to different carriers, a private resolver can have multiple outbound endpoints for different forwarding rules.
What is Azure DNS Private Resolver?
Azure DNS Private Resolver is a fully managed, serverless service that provides DNS resolution for Azure virtual networks (VNets) and on-premises networks. It eliminates the need to deploy and manage custom DNS server VMs (like Windows Server DNS or BIND) in a hub VNet. The resolver supports two main functions: inbound DNS resolution (resolving names from on-premises to Azure private DNS zones) and outbound DNS resolution (resolving names from Azure to on-premises DNS servers). It is designed to work with Azure Private DNS Zones and conditional forwarding rules.
Why It Exists
Before the private resolver, hybrid DNS scenarios required deploying a DNS server VM in a hub VNet, configuring forwarding, and managing high availability. This introduced complexity, cost, and maintenance overhead. The private resolver provides a native, scalable, and highly available alternative. It is particularly useful for:
Hub-spoke topologies where spoke VNets need to resolve names in private DNS zones linked to the hub.
Hybrid networks where Azure resources need to resolve on-premises hostnames via Active Directory or other internal DNS.
Multi-region deployments where consistent DNS resolution is required across regions.
How It Works Internally
The private resolver operates at the network layer, intercepting DNS queries (UDP/TCP port 53) from Azure resources. It consists of two endpoint types: - Inbound endpoint: A private IP address within a subnet of a VNet. On-premises DNS servers forward queries for Azure private zones to this IP. The resolver then queries the appropriate Azure Private DNS Zone and returns the answer. - Outbound endpoint: A subnet in the VNet from which the resolver sends DNS queries to on-premises DNS servers. You define DNS forwarding rulesets that specify which domains to forward and to which target DNS servers.
When an Azure VM in a spoke VNet (with DNS configured to use Azure default) attempts to resolve a name in an on-premises domain (e.g., ad.contoso.com), the query goes to Azure DNS (168.63.129.16). Azure DNS checks its private zones; if no match, it forwards to the private resolver's inbound endpoint if configured. The resolver then checks its forwarding rules; if a rule matches, it forwards the query to the specified on-premises DNS server. The response flows back through the same path.
Key Components and Defaults
Private Resolver Resource: Created in a region, associated with a VNet.
Inbound Endpoint: Requires a dedicated subnet (minimum /28) in the VNet. The IP address is assigned from the subnet. Default TTL for cached responses is 60 seconds (configurable).
Outbound Endpoint: Also requires a dedicated subnet (minimum /28). This subnet is used for outbound traffic to on-premises DNS.
DNS Forwarding Ruleset: Contains rules that map domain names to target DNS servers. A ruleset can be linked to one or more VNets (up to 50 VNets per ruleset). Rules are evaluated in order; the first match wins. Default rule (catch-all) forwards all unmatched domains to Azure DNS.
Virtual Network Links: Link a ruleset to a VNet. A VNet can have multiple rulesets linked, but only one ruleset can be the default.
Resolution Policies: Define how inbound queries are handled. Not commonly used.
Configuration and Verification
To create a private resolver via Azure CLI:
az network private-resolver create --resource-group myRG --name myResolver --location eastus --virtual-network myVNet
az network private-resolver inbound-endpoint create --resource-group myRG --resolver-name myResolver --name myInboundEP --ip-configurations private-ip-address=10.0.0.10 private-ip-allocation-method=Static subnet=/subscriptions/.../subnets/myInboundSubnet
az network private-resolver outbound-endpoint create --resource-group myRG --resolver-name myResolver --name myOutboundEP --subnet /subscriptions/.../subnets/myOutboundSubnet
az network private-resolver dns-forwarding-ruleset create --resource-group myRG --name myRuleset --outbound-endpoints myOutboundEP
az network private-resolver dns-forwarding-ruleset rule create --resource-group myRG --ruleset-name myRuleset --name myRule --domain-name contoso.com --target-dns-servers 192.168.1.10 192.168.1.11
az network private-resolver dns-forwarding-ruleset vnet-link create --resource-group myRG --ruleset-name myRuleset --name myLink --virtual-network mySpokeVNetVerification: Use nslookup from an Azure VM in a linked VNet to resolve an on-premises hostname. The query should be answered by the on-premises DNS server.
Interaction with Related Technologies
Azure Private DNS Zones: The resolver can resolve names in private zones linked to the resolver's VNet. It does not replace private DNS zones; it complements them.
Azure DNS: The resolver works with Azure's default DNS (168.63.129.16). Queries not matching private zones or forwarding rules are resolved by Azure DNS.
VPN Gateway / ExpressRoute: The resolver relies on network connectivity (VPN or ExpressRoute) to reach on-premises DNS servers. It does not provide connectivity itself.
Azure Firewall: Can be used to filter DNS traffic if required, but not necessary for resolution.
Performance and Scale
The private resolver is highly available by default (Microsoft manages redundancy within the region). There is no capacity planning needed; it scales automatically. However, consider:
Each inbound/outbound endpoint requires a subnet with at least 16 IPs (/28).
Maximum 1000 DNS queries per second per endpoint (soft limit, can be increased via support).
Latency: typically 1-10 ms for Azure-to-Azure, 10-50 ms for hybrid (depending on connectivity).
Security Considerations
Use Network Security Groups (NSGs) on endpoint subnets to restrict access. For inbound, allow UDP/TCP 53 only from on-premises DNS servers. For outbound, allow UDP/TCP 53 to on-premises DNS servers.
Private endpoints for Azure Private DNS Zones are not required; the resolver can access them natively.
Consider using Azure Policy to enforce the use of private resolvers across subscriptions.
Common Pitfalls
Forgetting to link the forwarding ruleset to the spoke VNet(s). Without the link, the spoke VNet's DNS queries are not forwarded.
Using overlapping IP address spaces between VNets and on-premises. The resolver uses IP addresses from the endpoint subnets; ensure no conflicts.
Misconfiguring the inbound endpoint IP as the DNS server on on-premises DNS forwarders. The inbound IP must be reachable from on-premises via VPN/ExpressRoute.
Exam Relevance
For AZ-305, you need to know when to use a private resolver versus a custom DNS server. The exam tests your ability to design DNS resolution for hybrid and multi-region scenarios. Key decision factors: cost, management overhead, scalability, and integration with Azure Private DNS Zones. The private resolver is the preferred choice for new designs unless specific requirements (e.g., custom DNS logging, DNSSEC) necessitate a VM-based solution.
Create Private Resolver Resource
First, create the private resolver resource in the target region and associate it with a VNet (typically the hub VNet in a hub-spoke topology). This resource is the logical container for endpoints. At this stage, no DNS functionality is active. The resolver's name and location are specified. The VNet association means the resolver will be able to access private DNS zones linked to that VNet. The Azure CLI command `az network private-resolver create` creates the resource. The resource does not consume any IP addresses yet.
Provision Inbound Endpoint
Create an inbound endpoint in a dedicated subnet (minimum /28) within the resolver's VNet. This endpoint gets a private IP address from the subnet. On-premises DNS servers will forward queries for Azure private zones to this IP. The inbound endpoint listens on UDP/TCP port 53. The IP address must be static and reachable from on-premises via VPN or ExpressRoute. The subnet must not have any other resources. The Azure CLI command `az network private-resolver inbound-endpoint create` creates it.
Provision Outbound Endpoint
Create an outbound endpoint in another dedicated subnet (minimum /28) within the same VNet. This subnet is used as the source IP range for outbound DNS queries to on-premises. The outbound endpoint itself does not have an IP address; it defines the subnet from which queries are sourced. The subnet must be different from the inbound endpoint subnet. The Azure CLI command `az network private-resolver outbound-endpoint create` creates it.
Create DNS Forwarding Ruleset
Create a DNS forwarding ruleset that references the outbound endpoint. The ruleset contains rules that map domain names (e.g., contoso.com) to target DNS server IP addresses (e.g., on-premises DNS servers). Rules are evaluated in order; the first match wins. A default rule (catch-all) can be added to forward all unmatched queries to Azure DNS. The ruleset can be linked to multiple VNets. The Azure CLI command `az network private-resolver dns-forwarding-ruleset create` creates it, and `az network private-resolver dns-forwarding-ruleset rule create` adds rules.
Link Ruleset to Spoke VNets
Create virtual network links between the forwarding ruleset and each spoke VNet that needs to resolve on-premises names. This link associates the ruleset with the VNet, enabling DNS forwarding for resources in that VNet. Without the link, the ruleset is not applied. A VNet can have multiple ruleset links, but only one default ruleset. The Azure CLI command `az network private-resolver dns-forwarding-ruleset vnet-link create` creates the link.
Configure On-Premises DNS Forwarding
On the on-premises DNS servers, configure conditional forwarding for Azure private DNS zones (e.g., privatelink.blob.core.windows.net) to the inbound endpoint IP address. This ensures that on-premises clients can resolve Azure private endpoints. The forwarder must be reachable over the VPN/ExpressRoute connection. The on-premises DNS server sends a query to the inbound endpoint, which then queries the Azure Private DNS Zone and returns the private IP address. Without this step, on-premises clients cannot resolve Azure private resources.
Scenario 1: Hub-Spoke Hybrid DNS Resolution
A large enterprise has a hub VNet in Azure connected to on-premises via ExpressRoute. They have multiple spoke VNets for different departments (finance, HR, IT). Each spoke VNet has private endpoints for Azure services (e.g., Storage Account, SQL Database). The on-premises network uses Active Directory DNS (ad.contoso.com). The goal is for Azure VMs in spokes to resolve on-premises hostnames (e.g., fileserver.ad.contoso.com) and for on-premises clients to resolve Azure private endpoint names (e.g., mystorage.privatelink.blob.core.windows.net).
Solution: Deploy a private resolver in the hub VNet with inbound and outbound endpoints. Create a forwarding ruleset with a rule for 'ad.contoso.com' pointing to the on-premises DNS servers. Link the ruleset to each spoke VNet. On on-premises DNS, create conditional forwarders for 'privatelink.blob.core.windows.net' and other private zones pointing to the resolver's inbound IP. This setup avoids deploying any DNS VMs.
Performance: With ExpressRoute, latency is ~5ms. The resolver handles thousands of queries per second. In production, they observed 99.99% availability.
Scenario 2: Multi-Region Disaster Recovery
A company runs a critical application in two Azure regions (East US and West US) with active-passive configuration. They have a private DNS zone 'app.internal' with records pointing to the active region's private endpoints. They need DNS resolution to automatically point to the healthy region. They also have an on-premises site that must resolve 'app.internal' to the active region.
Solution: Deploy a private resolver in each region's hub VNet. In the primary region, the resolver's inbound endpoint is used by on-premises. In the secondary region, a separate inbound endpoint. On-premises DNS forwards 'app.internal' to both inbound endpoints (primary first, secondary as backup). The private DNS zone 'app.internal' is linked to both hub VNets. During failover, they update the private zone records to point to the secondary region's endpoints. The resolver automatically returns the updated records.
Common Failure: Misconfigured Subnet Size
An engineer creates an inbound endpoint with a /28 subnet (16 IPs). Later, they try to add a second inbound endpoint in the same subnet, but fail because the subnet is too small (requires at least 16 IPs per endpoint). The rule: each inbound/outbound endpoint requires its own subnet of at least /28. They must create separate subnets for each endpoint. This is a common exam trap.
AZ-305 Objective Coverage
This topic aligns with objective 4.2: Design for hybrid networking. Specifically, the exam tests your ability to choose between Azure DNS Private Resolver and custom DNS servers for hybrid DNS resolution. You must understand when to use each. The private resolver is the recommended approach for most scenarios due to lower management overhead.
Common Wrong Answers
'Deploy a DNS server VM in the hub VNet' – This is often the default answer for candidates familiar with traditional networking. However, the exam expects you to prefer the private resolver because it is fully managed and scales automatically. Only choose a DNS VM if there is a specific requirement like DNSSEC or custom logging.
'Use Azure DNS (168.63.129.16) directly for on-premises resolution' – Azure DNS cannot resolve on-premises private names. The private resolver is needed to forward queries to on-premises DNS servers.
'Create a private DNS zone with the same name as the on-premises domain' – This would shadow the on-premises domain and cause resolution failures. Private DNS zones are for Azure private IPs only.
'Use Azure Firewall as DNS proxy' – While Azure Firewall can act as a DNS proxy, it is not a replacement for the private resolver. The private resolver is purpose-built for hybrid DNS.
Specific Numbers and Terms
Minimum subnet size for endpoints: /28 (16 IPs).
Maximum VNet links per ruleset: 50.
Default TTL for cached responses: 60 seconds.
Protocol: UDP and TCP port 53.
Inbound endpoint IP must be static.
The private resolver is a regional resource (not global).
Edge Cases
Cross-region resolution: The private resolver is regional. If you need resolution across regions, you must deploy a resolver in each region or use VNet peering with DNS forwarding.
Multiple on-premises sites: Create multiple forwarding rules with different target DNS servers for different domains.
DNSSEC: The private resolver does not support DNSSEC validation. If required, use a custom DNS server.
How to Eliminate Wrong Answers
If the question mentions 'managed service' or 'no maintenance', eliminate DNS VM options.
If the question mentions 'resolve on-premises names from Azure', look for 'private resolver' or 'DNS forwarding'.
If the question mentions 'resolve Azure private endpoints from on-premises', the answer involves inbound endpoint and conditional forwarding.
Beware of answers that suggest using Azure DNS (168.63.129.16) for hybrid resolution – it is only for Azure-internal queries.
Azure DNS Private Resolver is a fully managed service for hybrid DNS resolution, eliminating the need for custom DNS VMs.
Inbound endpoint receives queries from on-premises; outbound endpoint sends queries to on-premises; each requires a dedicated /28 subnet.
DNS forwarding rulesets map domain names to target DNS servers; rulesets must be linked to VNets to take effect.
The resolver works with Azure Private DNS Zones and Azure default DNS (168.63.129.16).
On-premises DNS servers must be configured to forward Azure private zones to the inbound endpoint IP.
The resolver does not support DNSSEC; use a custom DNS VM if DNSSEC is required.
Maximum 50 VNet links per ruleset; default TTL for cached responses is 60 seconds.
The resolver is regional; for cross-region resolution, deploy in each region or use VNet peering with forwarding.
These come up on the exam all the time. Here's how to tell them apart.
Azure DNS Private Resolver
Fully managed, no maintenance required
Auto-scales to handle high query volumes
Supports inbound and outbound forwarding natively
Regional resource, not global
No support for DNSSEC or custom logging
Custom DNS Server VM (Windows Server/BIND)
Requires manual deployment, patching, and HA configuration
Manual scaling with VM sizes and load balancing
Requires manual configuration of forwarding and conditional forwarding
Can be deployed globally with multiple VMs
Full control over DNS features (DNSSEC, logging, zones)
Mistake
The private resolver replaces Azure DNS (168.63.129.16).
Correct
The private resolver works alongside Azure DNS. Azure DNS still handles queries for public domains and private zones not covered by forwarding rules. The resolver only intercepts queries that match forwarding rules or are forwarded from on-premises.
Mistake
The inbound endpoint can be used for outbound resolution as well.
Correct
Inbound and outbound endpoints are separate. The inbound endpoint receives queries from on-premises; the outbound endpoint sends queries to on-premises. They cannot be combined into one endpoint.
Mistake
You can use the same subnet for both inbound and outbound endpoints.
Correct
Each endpoint requires its own dedicated subnet. They cannot share a subnet. Each subnet must be at least /28.
Mistake
The private resolver can resolve on-premises names without a VPN/ExpressRoute.
Correct
The resolver itself does not provide connectivity. It relies on existing network connectivity (VPN or ExpressRoute) to reach on-premises DNS servers. Without connectivity, outbound forwarding fails.
Mistake
Linking a forwarding ruleset to a VNet automatically enables DNS resolution for all VMs.
Correct
VMs must use Azure default DNS (168.63.129.16) as their DNS server. If a VM is configured with a custom DNS server, the forwarding ruleset is bypassed.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes. The private resolver can resolve names in private DNS zones that are linked to the VNet where the resolver is deployed. When a query comes from on-premises to the inbound endpoint, the resolver checks the private DNS zones and returns the private IP address. Similarly, for outbound queries, if the domain matches a private zone linked to the VNet, the resolver resolves it locally before any forwarding rules.
No. Typically, you deploy one resolver in a hub VNet and link its forwarding ruleset to multiple spoke VNets. Each spoke VNet does not need its own resolver. However, if you have isolated VNets without peering, you may need separate resolvers. The resolver is regional; for multi-region, deploy one per region.
If a spoke VNet is not linked to any forwarding ruleset, its DNS queries are handled by Azure default DNS (168.63.129.16) as usual. The private resolver only processes queries from VNets that have a ruleset link. Thus, you must explicitly link the ruleset to each spoke VNet that needs hybrid resolution.
No. The private resolver requires network connectivity between Azure and on-premises (via VPN Gateway or ExpressRoute) to forward queries to on-premises DNS servers. Without this connectivity, outbound forwarding will fail. The resolver itself does not provide connectivity.
The private resolver will retry the query to the specified target DNS servers. If all targets are unreachable, the query times out and the resolver returns a failure response (SERVFAIL). The resolver does not fall back to Azure DNS for that domain. To improve resilience, specify multiple target DNS servers in the forwarding rule.
Yes, the private resolver is available in all public Azure regions. However, it is a regional resource, so you must deploy it in the region where your hub VNet resides. It is not available in national clouds (Azure Government, China) as of now, but check the latest documentation.
You can monitor the private resolver using Azure Monitor metrics (e.g., queries per second, success rate) and logs (DNS query logs). You can also set up alerts for high query failure rates. Additionally, diagnostics logs can be sent to Log Analytics for detailed analysis.
You've just covered Azure DNS Private Resolver Design — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?