Most hybrid Azure environments are quietly running a DNS architecture that was designed for a different era. A pair of Windows Server VMs acting as DNS forwarders, patched manually, sized conservatively, and sitting in the critical path of every single name resolution request in your environment. When they go down, and they will go down, nothing works. When you add a new Private Endpoint DNS zone, you update the forwarder config by hand. When you expand to a new region, you build another pair.
Azure DNS Private Resolver has been generally available since 2022, yet most enterprise Landing Zone deployments still haven’t made the switch. This tip walks through replacing VM-based conditional forwarders with Private Resolver inbound and outbound endpoints, including the Terraform configuration and the forwarding ruleset structure that handles hub-spoke at scale.
Why VM-Based Forwarders Are a Liability
The traditional pattern puts custom DNS VMs in the hub VNet. Spoke VNets point to the hub VMs for DNS. Those VMs forward requests for Azure private DNS zones to Azure’s recursive resolver (168.63.129.16), and forward on-premises domain queries back to on-prem DNS servers. It works, but it carries real operational cost.
Every Private Endpoint DNS zone (and there are now over 100 distinct ones across Azure services) requires a manual conditional forwarder entry on each DNS VM. Miss one, and private endpoint resolution silently falls back to public IPs, which breaks connectivity and can expose traffic unintentionally. Redundancy requires at least two VMs per region, with patching windows, monitoring, and capacity planning for what is essentially a plumbing service. The Azure Private Link and Private Endpoint architecture posts covers why getting private endpoint DNS right matters for zero-trust network design Getting forwarders wrong undermines the entire model.
Azure DNS Private Resolver removes all of that. It is fully managed, zone-redundant within a region, scales without configuration, and integrates natively with Azure Private DNS zones without requiring explicit conditional forwarder entries for each zone.
How Private Resolver Works
Private Resolver has two endpoint types that map directly to the two directions of hybrid DNS traffic.
An inbound endpoint sits inside a delegated subnet and receives DNS queries from outside Azure , typically from on-premises resolvers configured to forward your privatelink.* and internal Azure domains to the inbound endpoint IP. Your on-prem DNS server forwards privatelink.blob.core.windows.net to 10.0.1.4 (the inbound endpoint), and Azure resolves it correctly against your Private DNS zones.
An outbound endpoint sits in another delegated subnet and handles queries originating within Azure that need to reach on-premises or custom DNS servers. A DNS Forwarding Ruleset defines which domain suffixes route to which upstream resolvers : for example, corp.contoso.com forwards to your on-prem DNS servers. The ruleset can be linked to multiple VNets, which is the key architectural advantage for hub-spoke: one ruleset covers all spokes without per-VNet forwarder config.
Terraform Implementation
The Terraform below provisions a Private Resolver in a hub VNet, with inbound and outbound endpoints in dedicated delegated subnets, and a forwarding ruleset that routes corporate domain queries to on-premises DNS.
# Subnets must be delegated to Microsoft.Network/dnsResolvers
# Minimum /28 per endpoint subnet; /27 recommended for headroom
resource "azurerm_subnet" "dns_inbound" {
name = "snet-dns-inbound"
resource_group_name = var.resource_group_name
virtual_network_name = var.hub_vnet_name
address_prefixes = ["10.0.1.0/27"]
delegation {
name = "dns-resolver-inbound"
service_delegation {
name = "Microsoft.Network/dnsResolvers"
}
}
}
resource "azurerm_subnet" "dns_outbound" {
name = "snet-dns-outbound"
resource_group_name = var.resource_group_name
virtual_network_name = var.hub_vnet_name
address_prefixes = ["10.0.1.32/27"]
delegation {
name = "dns-resolver-outbound"
service_delegation {
name = "Microsoft.Network/dnsResolvers"
}
}
}
resource "azurerm_private_dns_resolver" "hub" {
name = "dnsresolver-hub-${var.location}"
resource_group_name = var.resource_group_name
location = var.location
virtual_network_id = var.hub_vnet_id
}
resource "azurerm_private_dns_resolver_inbound_endpoint" "hub" {
name = "inbound-${var.location}"
private_dns_resolver_id = azurerm_private_dns_resolver.hub.id
location = var.location
ip_configurations {
private_ip_allocation_method = "Dynamic"
subnet_id = azurerm_subnet.dns_inbound.id
}
}
resource "azurerm_private_dns_resolver_outbound_endpoint" "hub" {
name = "outbound-${var.location}"
private_dns_resolver_id = azurerm_private_dns_resolver.hub.id
location = var.location
subnet_id = azurerm_subnet.dns_outbound.id
}
# Forwarding ruleset links to spoke VNets; one ruleset serves all spokes
resource "azurerm_private_dns_resolver_dns_forwarding_ruleset" "corporate" {
name = "ruleset-corporate"
resource_group_name = var.resource_group_name
location = var.location
private_dns_resolver_outbound_endpoint_ids = [azurerm_private_dns_resolver_outbound_endpoint.hub.id]
}
# Forward corporate domain to on-premises DNS servers
resource "azurerm_private_dns_resolver_forwarding_rule" "corp" {
name = "rule-corp-contoso"
dns_forwarding_ruleset_id = azurerm_private_dns_resolver_dns_forwarding_ruleset.corporate.id
domain_name = "corp.contoso.com." # Note the trailing dot
enabled = true
target_dns_servers {
ip_address = "192.168.1.10" # On-premises primary DNS
port = 53
}
target_dns_servers {
ip_address = "192.168.1.11" # On-premises secondary DNS
port = 53
}
}
# Link the ruleset to each spoke VNet; replaces per-spoke forwarder config
resource "azurerm_private_dns_resolver_virtual_network_link" "spoke" {
for_each = var.spoke_vnet_ids
name = "link-${each.key}"
dns_forwarding_ruleset_id = azurerm_private_dns_resolver_dns_forwarding_ruleset.corporate.id
virtual_network_id = each.value
}
Once the resolver is deployed, update your on-premises DNS servers to forward your Azure private DNS zones to the inbound endpoint IP. The inbound endpoint’s dynamically assigned address is available via azurerm_private_dns_resolver_inbound_endpoint.hub.ip_configurations[0].private_ip_address.
Enterprise Considerations
Private Resolver pricing runs at approximately £0.55 per endpoint per hour in UK South, which works out to roughly £800 per year for a pair of inbound and outbound endpoints. That compares favourably to two B2s DNS VMs with their associated patching and monitoring overhead and eliminates the operational risk of a failed patching window taking down DNS.
For multi-region deployments, provision a resolver per region rather than routing DNS traffic across region boundaries. The forwarding ruleset can be replicated across regions with the same rule definitions, keeping latency predictable. The Azure Virtual WAN hub-spoke architecture has implications for where you place resolver endpoints : in VWAN deployments, endpoints belong in connected spoke VNets designated for shared services, not inside the VWAN hub itself, which does not support subnet delegation.
Restrict inbound endpoint subnet NSGs carefully: allow UDP/TCP 53 from your on-premises DNS server IP ranges only. Outbound endpoint subnets have no NSG support by design The delegation handles traffic control.
When to Keep VM-Based Forwarders
Private Resolver does not support DNS over HTTPS or DNS Security Extensions (DNSSEC) validation. If your compliance posture requires DNSSEC validation at the resolver level, custom DNS VMs remain the only option. Private Resolver also cannot serve authoritative responses It is a conditional forwarder replacement only. Environments requiring split-horizon authoritative DNS for internal zones still need Azure Private DNS zones or a custom authoritative server alongside the resolver.
For net-new Landing Zone deployments, Private Resolver should be the default. For existing environments with stable VM-based forwarders and no capacity issues, the migration is low-risk and worth scheduling within the next quarter before the next major Private Endpoint expansion adds another round of manual forwarder updates.
Key Takeaways
Private Resolver eliminates the operational burden of maintaining DNS forwarder VMs in hub-spoke architectures. Forwarding rulesets link to multiple VNets simultaneously, removing per-spoke configuration overhead as your estate grows. At under £800 per year per region for inbound and outbound endpoints, the cost case is clear. The only scenarios that justify keeping VM-based forwarders are DNSSEC validation requirements or authoritative DNS needs that Private Resolver cannot address.
Useful Links
- Azure DNS Private Resolver overview – Microsoft Learn
- Private Resolver pricing – Azure
- Configure DNS forwarding ruleset – Microsoft Learn
- Private Resolver and hub-spoke networking – Microsoft Learn
- azurerm_private_dns_resolver – Terraform Registry
- Azure Private DNS zone list for private endpoints – Microsoft Learn
- NSG support for Private Resolver subnets – Microsoft Learn
