Azure DNS Private Resolver

Azure DNS Private Resolver is a managed service that provides DNS resolution for Azure virtual networks (VNets) and hybrid networks. Before this service, if you needed to resolve hostnames across peered VNets or between Azure and on-premises, you had to deploy your own DNS servers (e.g., Windows Server with DNS role) or use Azure-provided DNS (168.63.129.16), which only resolved names within a single VNet. The Private Resolver eliminates the need for custom DNS infrastructure by offering a scalable, highly available, and secure DNS resolution service.

The Private Resolver operates as a regional service that you provision inside a VNet. It consists of two types of endpoints: - Inbound Endpoint: An inbound endpoint receives DNS queries from on-premises networks via Azure ExpressRoute or VPN. It exposes one or more private IP addresses from the VNet's subnet. On-premises DNS servers can forward queries to these IPs to resolve Azure private zones and custom domains. - Outbound Endpoint: An outbound endpoint sends DNS queries from Azure resources to on-premises DNS servers or other external DNS servers. It uses a dedicated subnet (called the "outbound endpoint subnet") to source traffic. Rules defined in a DNS forwarding ruleset control where queries are forwarded.

When a resource in a VNet (e.g., a VM) performs a DNS lookup, the query first goes to the Azure-provided DNS (168.63.129.16). If the name is not in the VNet's private zone or Azure's public DNS, the query is forwarded to the Private Resolver's outbound endpoint. The outbound endpoint checks the forwarding ruleset: if a rule matches the query domain, the query is forwarded to the specified target DNS servers (e.g., on-premises DNS). Otherwise, the query is sent to Azure's public DNS.

- Domain name (e.g., contoso.com) - Target DNS servers (IP addresses and port, default 53) - Forwarding state (enabled/disabled) - Default TTL: DNS responses from the Private Resolver are cached according to the TTL in the response. The service itself does not impose its own TTL. - Scalability: Each inbound endpoint can handle up to 10,000 queries per second (QPS). Outbound endpoints have similar limits. - High Availability: The service is zone-redundant by default in regions that support Availability Zones. You can also deploy multiple endpoints in different subnets or VNets.

To create a Private Resolver using Azure CLI:

# Create a resource group
az group create --name MyRG --location eastus

# Create a VNet with subnets for endpoints
az network vnet create --name MyVNet --resource-group MyRG --address-prefix 10.0.0.0/16 --subnet-name inbound-subnet --subnet-prefix 10.0.1.0/28
az network vnet subnet create --name outbound-subnet --resource-group MyRG --vnet-name MyVNet --address-prefix 10.0.2.0/28

# Create the Private Resolver
az network private-resolver create --name MyResolver --resource-group MyRG --location eastus --id /subscriptions/.../resourceGroups/MyRG/providers/Microsoft.Network/virtualNetworks/MyVNet

# Create inbound endpoint
az network private-resolver inbound-endpoint create --name MyInbound --resource-group MyRG --resolver-name MyResolver --location eastus --ip-configurations private-ip-address=10.0.1.4 private-ip-allocation-method=Static

# Create outbound endpoint
az network private-resolver outbound-endpoint create --name MyOutbound --resource-group MyRG --resolver-name MyResolver --location eastus --subnet /subscriptions/.../resourceGroups/MyRG/providers/Microsoft.Network/virtualNetworks/MyVNet/subnets/outbound-subnet

# Create a forwarding ruleset and link to VNets
az network private-resolver dns-forwarding-ruleset create --name MyRuleset --resource-group MyRG --location eastus --outbound-endpoints [{"id":"/subscriptions/.../outboundEndpoints/MyOutbound"}]
az network private-resolver dns-forwarding-ruleset link create --name MyLink --resource-group MyRG --ruleset-name MyRuleset --virtual-network /subscriptions/.../virtualNetworks/MyVNet

# Add a forwarding rule
az network private-resolver dns-forwarding-ruleset rule create --name MyRule --resource-group MyRG --ruleset-name MyRuleset --domain-name contoso.com. --target-dns-servers [{"ip-address":"192.168.1.10","port":53}] --forwarding-state Enabled

Verification:

# Test DNS resolution from a VM in the VNet
nslookup vm01.contoso.com
# The response should come from the on-premises DNS server if the rule matches.

Scenario 1: Hybrid DNS Resolution for a Multi-Site Enterprise

A large enterprise has an on-premises data center with Active Directory (AD) DNS servers (192.168.1.10 and 192.168.1.11) and multiple Azure VNets hosting IaaS workloads. They need Azure VMs to resolve on-premises hostnames (e.g., 'file-server.contoso.com') and on-premises clients to resolve Azure VM names (e.g., 'web-vm.contoso.com'). They deploy an Azure DNS Private Resolver in a hub VNet with both inbound and outbound endpoints. The outbound endpoint is configured with a forwarding ruleset that sends queries for 'contoso.com' to the on-premises DNS servers. The inbound endpoint IPs (10.0.1.4 and 10.0.1.5) are added as conditional forwarders on the on-premises DNS servers for 'contoso.com' (Azure private zone). This creates a full bidirectional resolution. In production, they monitor query rates and scale by adding more IPs to the inbound endpoint or deploying additional resolvers in spoke VNets. A common misconfiguration is forgetting to allow UDP/53 traffic on NSGs for the outbound endpoint subnet, causing queries to time out.

Scenario 2: Isolated Dev/Test Environments with Custom DNS

A software company runs multiple isolated dev/test environments in separate VNets. Each environment uses a custom DNS suffix (e.g., 'dev.contoso.com', 'test.contoso.com'). They want each VNet to resolve its own private zone but also have a central 'shared.contoso.com' zone. They deploy a single Private Resolver in a management VNet with an outbound endpoint. They create separate forwarding rulesets for each environment linked to the respective VNet. Each ruleset has rules for the environment-specific domain pointing to a dedicated DNS server (e.g., a VM running BIND) and a catch-all rule for 'contoso.com' pointing to the central DNS server. This avoids the need to deploy a resolver per VNet. However, if the central DNS server goes down, all 'contoso.com' queries fail. They mitigate this by deploying redundant DNS servers and using multiple target IPs in the rule.

Scenario 3: Mergers and Acquisitions – DNS Consolidation

After an acquisition, two companies need to integrate their DNS namespaces. Company A uses 'acompany.com' and Company B uses 'bcompany.com'. Both have on-premises DNS and Azure VNets. They deploy a Private Resolver in a shared VNet with inbound and outbound endpoints. On-premises DNS servers of both companies forward queries for the other company's domain to the inbound endpoint. The forwarding ruleset sends queries for 'acompany.com' to Company A's DNS and 'bcompany.com' to Company B's DNS. This allows seamless name resolution without changing existing DNS infrastructure. Performance is critical: if the inbound endpoint is overloaded, queries from on-premises may fail. They scale by adding more IPs to the inbound endpoint and using DNS server-level load balancing.