Azure DNS Private Resolver is a managed service that enables you to resolve DNS queries for private DNS zones across Azure and on-premises networks, simplifying hybrid network architectures and removing the need for custom DNS servers or DNS forwarders hosted on virtual machines. This service reduces operational complexity and provides scalable, secure name resolution for modern cloud environments.
Classic Architecture: Custom DNS in Azure
In the diagram above, an on-premises network connects to Azure via Site-to-Site VPN or ExpressRoute. DNS resolution is handled by a custom DNS instance deployed in Azure, which forwards queries for Azure Private DNS zones to the special Azure DNS address, 168.63.129.16. Clients on both on-premises and peered networks use this Azure-based DNS server for name resolution of Azure resources.
This setup is simple but requires managing a custom DNS server in Azure
The Azure DNS special IP is used for resolving resources registered in Private DNS zones
Maintenance and operational overhead remain, since you are responsible for patching and availability of the DNS server
On-Premises DNS with Azure-based DNS Forwarder
The second diagram is a close variation, replacing the custom DNS with a DNS Forwarder. The forwarder is deployed in Azure as a VM or domain controller. This means you can keep your main DNS infrastructure on-premises, while using an Azure-based forwarder to handle Azure-specific resolutions.
Maintenance cost is similar to that in the first architecture
The main advantage is consolidated management, as the core DNS remains in your data center
Streamlined Modern Architecture: Azure DNS Private Resolver
Deploying Azure DNS Private Resolver replaces the need for custom DNS or DNS forwarders running on VMs. It introduces an inbound endpoint deployed in a dedicated subnet (recommended size /24), enabling any network – on-premises or Azure – to resolve names registered in Azure Private DNS zones.
No need for VM-based DNS servers, reducing complexity and operational cost
Make sure the subnet hosting the inbound endpoint is dedicated and properly delegated to the DNS resolver resource
Hybrid Name Resolution: Adding an Outbound Subnet and Forward Rule Set
The final diagram builds on the simplified architecture by including an outbound endpoint and a forwarding rule set. This configuration lets Azure DNS Private Resolver forward queries for domains that reside outside Azure (such as other cloud providers or legacy environments) to external DNS services.
The outbound endpoint enables Azure resources to resolve non-Azure names when required
Both inbound and outbound subnets should be dedicated, and recommended being sized /24 to provide sufficient scale
Architectural Guidance and Best Practices
You should:
Prefer Azure DNS Private Resolver for native integration, scalability, and security within Azure; minimize reliance on VM-based DNS forwarders or custom DNS servers
Use dedicated subnets (/24 preferred) for both inbound and outbound endpoints, and delegate them specifically to Microsoft.Network/dnsResolvers
Link Private DNS Zones to the virtual networks that need to resolve those names
For on-premises resolution, configure conditional forwarders on your DNS infrastructure to point to the inbound endpoint IP of Azure DNS Private Resolver
Use forwarding rulesets to manage DNS resolution across hybrid and multi-cloud environments efficiently
Budgeting Considerations
Azure DNS Private Resolver uses a simple, transparent pricing model that often reduces total cost of ownership compared to running your own DNS servers or domain controllers on virtual machines. Azure charges per inbound endpoint, per outbound endpoint, and per ruleset, plus the standard zone and query charges for Azure DNS, with no extra cost for patching, scaling, or high availability of the resolver itself.
Microsoft’s documentation highlights that because the resolver is fully managed and multi-tenant, it typically runs at a fraction of the cost of traditional IaaS-based DNS solutions that require multiple VMs, operating system licenses, storage, backup, and lifecycle management.
In contrast, architectures based on custom DNS servers or domain controllers in Azure must account for the hourly VM cost, disks, backup, and any Windows Server or Active Directory licensing, and they still require operational processes for patching, monitoring, and troubleshooting.
When comparing options, Microsoft recommends using the Azure Pricing Calculator and the Azure DNS pricing page to model the resolver endpoints and rulesets versus the equivalent VM-based design. In many hybrid scenarios, especially where high availability or multiple regions are required, the Private Resolver provides a more predictable and often lower ongoing cost, while also simplifying management.
Azure DNS Private Resolver is a regional service, meaning each resolver is deployed within a specific Azure region and provides DNS resolution endpoints only within that region.
However, it is possible to use Azure DNS Private Resolver for cross-region scenarios by deploying resolver instances in each region where DNS resolution is required, and then configuring your networking and DNS architecture appropriately.
Deploy a Private DNS Resolver in each Azure region where you need local DNS resolution.
Link your Azure Private DNS zones, which are globally replicated resources, to virtual networks in each relevant region. This allows VMs and services in any region to resolve DNS names from the shared zone, minimizing the need for DNS queries to cross regional boundaries.
For hybrid and multi-region environments, conditional forwarders or failover can direct DNS queries to the nearest available resolver endpoint. On-premises or external DNS systems can be configured to forward requests to more than one resolver for redundancy.
Did you read this article because you’re knowledgeable about networking? Do you have the skills necessary to manage networks? We’re currently hiring for roles like this as well as other roles here at Würth IT Italy.
Scenario: Introduction Think of an organization that maintains most of its IT infrastructure on Azure. It applies a segmentation strategy by branch office, where the assets underlying each regional branch office are deployed to their specific landing zone subscription, i.e. Read More
Let's assume we have the following reference scenario, which we'll use just for simplicity: A fictitious commercial freight business moves large volumes of goods all over Europe. It has two legally registered offices, one in the Netherlands (Western Europe) and Read More
Managing user access in Atlassian Cloud can become complex, especially when integrating with Identity Providers (IDPs) for user provisioning via SCIM (System for Cross-domain Identity Management). A common challenge arises when users who were initially synchronized through your IDP become Read More
At SharpCoding 2025 in Rome – hosted at Microsoft’s headquarters – I had the pleasure of sharing our approach to simplifying deployments using Azure Container App Jobs. In my session, "Guided Deployments: Power Platform under Control with Azure DevOps," I Read More
When deploying new features, releasing your code into a production environment might not be as easy as it seems. To ensure the minimal amount of service disruption, we might want to easily roll back to a previous configuration or to Read More