Azure DNS Private Resolver - Complete Implementation Guide

Table of Contents

1. Overview and Architecture

Azure DNS Private Resolver is a cloud-native DNS service that enables you to query Azure DNS private zones from on-premises networks and query on-premises DNS servers from Azure virtual networks. It acts as a bridge between your on-premises DNS infrastructure and Azure Private DNS zones.

graph TB subgraph "On-Premises Network" OnPremClient[On-Premises Client] OnPremDNS[On-Premises DNS Server] end subgraph "Azure Virtual Network" subgraph "DNS Private Resolver" InboundEndpoint[Inbound Endpoint
10.0.1.4] OutboundEndpoint[Outbound Endpoint
10.0.2.4] end subgraph "Private DNS Zone" PrivateZone[contoso.local] ARecord[VM1.contoso.local] end AzureVM[Azure VM] end OnPremClient -->|DNS Query for
VM1.contoso.local| OnPremDNS OnPremDNS -->|Forward to Azure| InboundEndpoint InboundEndpoint -->|Query Private Zone| PrivateZone PrivateZone -->|Return Answer| InboundEndpoint InboundEndpoint -->|Response| OnPremDNS OnPremDNS -->|Response| OnPremClient AzureVM -->|DNS Query for
onprem.company.com| OutboundEndpoint OutboundEndpoint -->|Forward to On-Premises| OnPremDNS OnPremDNS -->|Response| OutboundEndpoint OutboundEndpoint -->|Response| AzureVM

Architecture Explanation:

This diagram shows the bi-directional DNS resolution capability of Azure DNS Private Resolver:

  • Inbound Endpoint: Receives DNS queries from on-premises networks and resolves them using Azure Private DNS zones
  • Outbound Endpoint: Forwards DNS queries from Azure VMs to on-premises DNS servers
  • Private DNS Zone: Contains DNS records for Azure resources that need to be resolved from on-premises
  • Bi-directional Flow: Enables seamless DNS resolution in both directions across the hybrid network

2. Core Components

graph TD subgraph "DNS Private Resolver Components" Resolver[DNS Private Resolver] subgraph "Inbound Configuration" InboundEndpoint[Inbound Endpoint] InboundSubnet[Inbound Subnet
Delegated to Microsoft.Network/dnsResolvers] end subgraph "Outbound Configuration" OutboundEndpoint[Outbound Endpoint] OutboundSubnet[Outbound Subnet
Delegated to Microsoft.Network/dnsResolvers] ForwardingRules[DNS Forwarding Rules] end subgraph "Associated Resources" VNet[Virtual Network] PrivateDNSZone[Private DNS Zone] RuleSet[DNS Forwarding Ruleset] end end Resolver --> InboundEndpoint Resolver --> OutboundEndpoint InboundEndpoint --> InboundSubnet OutboundEndpoint --> OutboundSubnet OutboundEndpoint --> ForwardingRules ForwardingRules --> RuleSet VNet --> InboundSubnet VNet --> OutboundSubnet VNet --> PrivateDNSZone style Resolver fill:#e1f5fe style InboundEndpoint fill:#f3e5f5 style OutboundEndpoint fill:#e8f5e8 style ForwardingRules fill:#fff3e0

Component Breakdown:

The DNS Private Resolver consists of several interconnected components:

  • DNS Private Resolver: The main service that orchestrates DNS resolution
  • Inbound Endpoint: Receives DNS queries from external sources (on-premises)
  • Outbound Endpoint: Sends DNS queries to external DNS servers
  • Delegated Subnets: Special subnets delegated to Microsoft.Network/dnsResolvers service
  • DNS Forwarding Ruleset: Defines which domains should be forwarded to specific DNS servers

3. Traffic Flow Diagrams

3.1 Inbound DNS Resolution Flow

sequenceDiagram participant OnPrem as On-Premises Client participant OnPremDNS as On-Premises DNS participant Firewall as Firewall/Router participant InboundEP as Inbound Endpoint participant PrivateZone as Private DNS Zone participant AzureVM as Azure VM OnPrem->>OnPremDNS: 1. Query: vm1.contoso.local OnPremDNS->>OnPremDNS: 2. Check local cache/records OnPremDNS->>Firewall: 3. Forward to Azure (conditional forwarder) Firewall->>InboundEP: 4. DNS Query (Port 53) InboundEP->>PrivateZone: 5. Query Private DNS Zone PrivateZone->>InboundEP: 6. Return IP Address InboundEP->>Firewall: 7. DNS Response Firewall->>OnPremDNS: 8. Response OnPremDNS->>OnPrem: 9. Final Response OnPrem->>AzureVM: 10. Connect using resolved IP

Inbound Flow Explanation:

This sequence shows how on-premises clients resolve Azure private resources:

  1. Initial Query: Client requests resolution for an Azure private resource
  2. Local Check: On-premises DNS server checks its local records first
  3. Conditional Forwarding: DNS server forwards the query to Azure based on configured conditional forwarders
  4. Network Transit: Query travels through network infrastructure (firewall/VPN/ExpressRoute)
  5. Azure Resolution: Inbound endpoint queries the appropriate Private DNS Zone
  6. Response Chain: Answer travels back through the same path
  7. Connection: Client can now connect to the Azure resource using the resolved IP

3.2 Outbound DNS Resolution Flow

sequenceDiagram participant AzureVM as Azure VM participant VNetDNS as VNet DNS Settings participant OutboundEP as Outbound Endpoint participant ForwardingRules as Forwarding Rules participant Firewall as Firewall/Router participant OnPremDNS as On-Premises DNS participant OnPremServer as On-Premises Server AzureVM->>VNetDNS: 1. Query: server1.corp.local VNetDNS->>OutboundEP: 2. Forward to Outbound Endpoint OutboundEP->>ForwardingRules: 3. Check forwarding rules ForwardingRules->>OutboundEP: 4. Route to on-premises DNS OutboundEP->>Firewall: 5. DNS Query (Port 53) Firewall->>OnPremDNS: 6. Forward to on-premises OnPremDNS->>OnPremDNS: 7. Resolve locally OnPremDNS->>Firewall: 8. DNS Response Firewall->>OutboundEP: 9. Response OutboundEP->>VNetDNS: 10. Response VNetDNS->>AzureVM: 11. Final Response AzureVM->>OnPremServer: 12. Connect using resolved IP

Outbound Flow Explanation:

This sequence demonstrates how Azure VMs resolve on-premises resources:

  1. Azure VM Query: VM requests resolution for an on-premises resource
  2. VNet DNS Processing: VNet DNS settings route the query to the outbound endpoint
  3. Rule Evaluation: Forwarding rules determine the appropriate target DNS server
  4. External Forwarding: Query is sent to the designated on-premises DNS server
  5. On-premises Resolution: On-premises DNS server resolves the query locally
  6. Response Return: Answer travels back through the established path
  7. Resource Access: Azure VM can now access the on-premises resource

3.3 Complete Network Architecture

graph TB subgraph "On-Premises Network" OnPremClient[Client Workstation] OnPremDNS[DNS Server
192.168.1.10] OnPremServer[Application Server
server1.corp.local] end subgraph "Network Connectivity" VPN[VPN Gateway] ExpressRoute[ExpressRoute] Firewall[Firewall/Router] end subgraph "Azure Virtual Network - Hub" subgraph "DNS Private Resolver" InboundEP[Inbound Endpoint
10.0.1.4] OutboundEP[Outbound Endpoint
10.0.2.4] end subgraph "Subnets" InboundSubnet[Inbound Subnet
10.0.1.0/28] OutboundSubnet[Outbound Subnet
10.0.2.0/28] VMSubnet[VM Subnet
10.0.3.0/24] end end subgraph "Azure Virtual Network - Spoke" SpokeVM[Spoke VM
10.1.1.4] SpokeSubnet[Spoke Subnet
10.1.1.0/24] end subgraph "DNS Zones" PrivateZone[Private DNS Zone
contoso.local] ForwardingRuleset[Forwarding Ruleset
corp.local → 192.168.1.10] end %% Connections OnPremClient --> OnPremDNS OnPremDNS --> Firewall Firewall --> VPN Firewall --> ExpressRoute VPN --> InboundEP ExpressRoute --> InboundEP InboundEP --> PrivateZone OutboundEP --> ForwardingRuleset ForwardingRuleset --> Firewall VMSubnet --> OutboundEP SpokeVM --> OutboundEP style InboundEP fill:#e8f5e8 style OutboundEP fill:#fff3e0 style PrivateZone fill:#f3e5f5 style ForwardingRuleset fill:#e1f5fe

Complete Architecture Explanation:

This comprehensive diagram shows how DNS Private Resolver integrates into a typical hybrid network architecture:

  • Hub-Spoke Topology: Central DNS resolver serves multiple spoke VNets
  • Connectivity Options: Supports both VPN and ExpressRoute connections
  • Subnet Delegation: Dedicated subnets for inbound and outbound endpoints
  • DNS Zones: Private DNS zones for Azure resources and forwarding rules for on-premises
  • Centralized Management: Single resolver can serve multiple VNets and on-premises networks

4. Implementation Sequence

graph TD A[1. Create DNS Private Resolver] --> B[2. Create Inbound Endpoint] B --> C[3. Create Outbound Endpoint] C --> D[4. Create DNS Forwarding Ruleset] D --> E[5. Create Forwarding Rules] E --> F[6. Link Ruleset to VNet] F --> G[7. Configure On-Premises DNS] G --> H[8. Test Resolution] subgraph "Prerequisites" P1[Virtual Network with delegated subnets] P2[Resource Group] P3[Proper permissions] end subgraph "Validation Steps" V1[Test inbound resolution] V2[Test outbound resolution] V3[Verify forwarding rules] end P1 --> A P2 --> A P3 --> A H --> V1 H --> V2 H --> V3 style A fill:#e8f5e8 style B fill:#f3e5f5 style C fill:#fff3e0 style D fill:#e1f5fe

Implementation Sequence Explanation:

The implementation must follow this specific order due to dependencies:

  1. Prerequisites: Ensure VNet with properly delegated subnets exists
  2. Core Service: Create the DNS Private Resolver first
  3. Endpoints: Create inbound and outbound endpoints in delegated subnets
  4. Forwarding Logic: Create ruleset and rules for outbound resolution
  5. VNet Association: Link the ruleset to target VNets
  6. On-Premises Config: Configure conditional forwarders on-premises
  7. Testing: Validate both inbound and outbound resolution

5. Configuration Commands

Note: This guide assumes you already have a Virtual Network with properly configured subnets. The subnet delegation commands are covered in other networking guides.

5.1 Create DNS Private Resolver

az dns-resolver create \ --name "dns-resolver-hub" \ --resource-group "rg-dns-resolver" \ --virtual-network "/subscriptions/{subscription-id}/resourceGroups/rg-dns-resolver/providers/Microsoft.Network/virtualNetworks/vnet-hub" \ --location "eastus" \ --tags Environment=Production Purpose=DNS-Resolution

DNS Private Resolver Configuration Parameters:

  • --name: Unique name for the DNS resolver within the resource group
  • --resource-group: Resource group where the resolver will be created
  • --virtual-network: Full resource ID of the VNet where resolver will be deployed
  • --location: Azure region (must match the VNet location)
  • --tags: Optional tags for resource management and billing

Alternative Options:

  • You can use resource names instead of full IDs if resources are in the same subscription
  • Additional tags can be added for cost center, owner, or environment classification
Step 1: The DNS Private Resolver is the foundational service that will host your inbound and outbound endpoints. It must be created first as all other components depend on it. The resolver automatically inherits the VNet's location and cannot be moved after creation.

5.2 Create Inbound Endpoint

az dns-resolver inbound-endpoint create \ --dns-resolver-name "dns-resolver-hub" \ --name "inbound-endpoint-hub" \ --resource-group "rg-dns-resolver" \ --ip-configurations subnet="/subscriptions/{subscription-id}/resourceGroups/rg-dns-resolver/providers/Microsoft.Network/virtualNetworks/vnet-hub/subnets/subnet-dns-inbound" \ --location "eastus" \ --tags Purpose=InboundDNS

Inbound Endpoint Configuration Parameters:

  • --dns-resolver-name: Name of the parent DNS resolver
  • --name: Name for the inbound endpoint
  • --ip-configurations: Subnet where the endpoint will be deployed (must be delegated to Microsoft.Network/dnsResolvers)
  • --location: Must match the DNS resolver location

Alternative Options:

  • Static IP: Add `private-ip-address="10.0.1.4"` to assign a specific IP
  • Multiple IPs: You can configure multiple IP configurations for high availability
Step 2: The inbound endpoint receives DNS queries from external sources (on-premises networks). It requires a subnet that has been delegated to Microsoft.Network/dnsResolvers. The endpoint will automatically receive an IP address from the subnet range, which becomes the target for conditional forwarders configured on-premises.

5.3 Create Outbound Endpoint

az dns-resolver outbound-endpoint create \ --dns-resolver-name "dns-resolver-hub" \ --name "outbound-endpoint-hub" \ --resource-group "rg-dns-resolver" \ --subnet "/subscriptions/{subscription-id}/resourceGroups/rg-dns-resolver/providers/Microsoft.Network/virtualNetworks/vnet-hub/subnets/subnet-dns-outbound" \ --location "eastus" \ --tags Purpose=OutboundDNS

Outbound Endpoint Configuration Parameters:

  • --dns-resolver-name: Name of the parent DNS resolver
  • --name: Name for the outbound endpoint
  • --subnet: Subnet for the outbound endpoint (must be delegated and different from inbound)
  • --location: Must match the DNS resolver location

Alternative Options:

  • The outbound endpoint automatically handles load balancing across multiple target DNS servers
  • You can create multiple outbound endpoints for different forwarding scenarios
Step 3: The outbound endpoint sends DNS queries to external DNS servers based on forwarding rules. It requires its own dedicated subnet, separate from the inbound endpoint. This endpoint will be the source of DNS queries sent to on-premises DNS servers.

5.4 Create DNS Forwarding Ruleset

az dns-resolver forwarding-ruleset create \ --name "ruleset-onprem-forwarding" \ --resource-group "rg-dns-resolver" \ --outbound-endpoints "/subscriptions/{subscription-id}/resourceGroups/rg-dns-resolver/providers/Microsoft.Network/dnsResolvers/dns-resolver-hub/outboundEndpoints/outbound-endpoint-hub" \ --location "eastus" \ --tags Purpose=ForwardingRules Environment=Production

DNS Forwarding Ruleset Configuration Parameters:

  • --name: Name for the forwarding ruleset
  • --resource-group: Resource group for the ruleset
  • --outbound-endpoints: Full resource ID of the outbound endpoint that will process the forwarding
  • --location: Must match the DNS resolver location

Alternative Options:

  • One ruleset can contain multiple forwarding rules for different domains
  • Multiple outbound endpoints can be associated with a single ruleset for high availability
Step 4: The forwarding ruleset is a container that holds multiple forwarding rules. It's associated with one or more outbound endpoints and defines the overall forwarding behavior. The ruleset can be linked to multiple VNets to apply the same forwarding logic across your network.

5.5 Create Forwarding Rules

az dns-resolver forwarding-rule create \ --name "rule-corp-domain" \ --resource-group "rg-dns-resolver" \ --ruleset-name "ruleset-onprem-forwarding" \ --domain-name "corp.local." \ --forwarding-rule-state "Enabled" \ --target-dns-servers ip-address="192.168.1.10" port=53 \ --target-dns-servers ip-address="192.168.1.11" port=53

Forwarding Rule Configuration Parameters:

  • --name: Name for the specific forwarding rule
  • --ruleset-name: Name of the parent ruleset
  • --domain-name: Domain to forward (must end with a dot for absolute domain)
  • --forwarding-rule-state: "Enabled" or "Disabled"
  • --target-dns-servers: DNS servers to forward queries to (supports multiple servers)

Alternative Options:

  • Port: Default is 53, but can be changed for non-standard DNS servers
  • Multiple Rules: Create separate rules for different domains (e.g., corp.local, dev.local)
  • Wildcard Domains: Use parent domains to catch all subdomains
Step 5: Individual forwarding rules define specific domains and their target DNS servers. Each rule can have multiple target servers for redundancy. The domain name must be an absolute domain (ending with a dot) and can include wildcards. Rules are processed in order of specificity.

5.6 Additional Forwarding Rules (Examples)

az dns-resolver forwarding-rule create \ --name "rule-dev-domain" \ --resource-group "rg-dns-resolver" \ --ruleset-name "ruleset-onprem-forwarding" \ --domain-name "dev.corp.local." \ --forwarding-rule-state "Enabled" \ --target-dns-servers ip-address="192.168.2.10" port=53
az dns-resolver forwarding-rule create \ --name "rule-reverse-lookup" \ --resource-group "rg-dns-resolver" \ --ruleset-name "ruleset-onprem-forwarding" \ --domain-name "1.168.192.in-addr.arpa." \ --forwarding-rule-state "Enabled" \ --target-dns-servers ip-address="192.168.1.10" port=53

Additional Rule Examples:

  • Subdomain Rules: More specific rules (dev.corp.local) take precedence over general rules (corp.local)
  • Reverse Lookup Rules: Enable reverse DNS resolution for on-premises IP ranges
  • Different DNS Servers: Different domains can forward to different DNS servers

5.7 Link Ruleset to Virtual Networks

az dns-resolver vnet-link create \ --name "link-hub-vnet" \ --resource-group "rg-dns-resolver" \ --ruleset-name "ruleset-onprem-forwarding" \ --virtual-network "/subscriptions/{subscription-id}/resourceGroups/rg-dns-resolver/providers/Microsoft.Network/virtualNetworks/vnet-hub"
az dns-resolver vnet-link create \ --name "link-spoke-vnet" \ --resource-group "rg-dns-resolver" \ --ruleset-name "ruleset-onprem-forwarding" \ --virtual-network "/subscriptions/{subscription-id}/resourceGroups/rg-spoke/providers/Microsoft.Network/virtualNetworks/vnet-spoke"

VNet Link Configuration Parameters:

  • --name: Name for the VNet link
  • --ruleset-name: Name of the ruleset to link
  • --virtual-network: Full resource ID of the VNet to link

Alternative Options:

  • One ruleset can be linked to multiple VNets
  • Each VNet can only be linked to one ruleset at a time
  • Links can be created across different resource groups and subscriptions
Step 6: VNet links apply the forwarding rules to specific virtual networks. Any VM in a linked VNet will use the outbound endpoint for DNS queries matching the forwarding rules. This enables you to apply the same DNS forwarding logic to multiple VNets without duplicating configuration.

5.8 Verification Commands

# Get the inbound endpoint IP address az dns-resolver inbound-endpoint show \ --dns-resolver-name "dns-resolver-hub" \ --name "inbound-endpoint-hub" \ --resource-group "rg-dns-resolver" \ --query "ipConfigurations[0].privateIpAddress" \ --output tsv
# List all forwarding rules az dns-resolver forwarding-rule list \ --resource-group "rg-dns-resolver" \ --ruleset-name "ruleset-onprem-forwarding" \ --output table
# Check VNet links az dns-resolver vnet-link list \ --resource-group "rg-dns-resolver" \ --ruleset-name "ruleset-onprem-forwarding" \ --output table

Verification Commands Explanation:

  • Inbound Endpoint IP: Use this IP address to configure conditional forwarders on-premises
  • Forwarding Rules List: Verify all rules are created and enabled
  • VNet Links: Confirm all target VNets are properly linked

5.9 Command Dependency Flow

graph TD A[az dns-resolver create] --> B[az dns-resolver inbound-endpoint create] A --> C[az dns-resolver outbound-endpoint create] C --> D[az dns-resolver forwarding-ruleset create] D --> E[az dns-resolver forwarding-rule create] D --> F[az dns-resolver vnet-link create] subgraph "Order of Execution" O1[1st: DNS Resolver] O2[2nd: Inbound Endpoint] O3[3rd: Outbound Endpoint] O4[4th: Forwarding Ruleset] O5[5th: Forwarding Rules] O6[6th: VNet Links] end subgraph "Verification Commands" V1[az dns-resolver inbound-endpoint show] V2[az dns-resolver forwarding-rule list] V3[az dns-resolver vnet-link list] end A --> O1 B --> O2 C --> O3 D --> O4 E --> O5 F --> O6 style A fill:#e8f5e8 style B fill:#f3e5f5 style C fill:#fff3e0 style D fill:#e1f5fe style E fill:#fce4ec style F fill:#f3e5f5

Command Dependency Explanation:

The Azure CLI commands must be executed in a specific order due to resource dependencies:

  1. DNS Resolver: Foundation service that hosts all endpoints
  2. Inbound Endpoint: Depends on DNS Resolver, can be created in parallel with outbound
  3. Outbound Endpoint: Depends on DNS Resolver, required for forwarding ruleset
  4. Forwarding Ruleset: Depends on outbound endpoint being available
  5. Forwarding Rules: Depends on ruleset, multiple rules can be created in parallel
  6. VNet Links: Depends on ruleset, multiple links can be created in parallel

6. On-Premises Configuration and Testing

6.1 On-Premises DNS Server Configuration

Configure conditional forwarders on your on-premises DNS servers to forward queries for Azure Private DNS zones to the inbound endpoint.
# Windows DNS Server PowerShell Add-DnsServerConditionalForwarderZone -Name "contoso.local" -MasterServers "10.0.1.4" -ReplicationScope "Forest" # Linux BIND DNS Server (named.conf) zone "contoso.local" { type forward; forwarders { 10.0.1.4; }; };

6.2 Testing DNS Resolution

# Test from on-premises client nslookup vm1.contoso.local # Test from Azure VM nslookup server1.corp.local # Test with specific DNS server nslookup vm1.contoso.local 10.0.1.4

6.3 Troubleshooting Commands

# Check DNS resolver status az dns-resolver show --name "dns-resolver-hub" --resource-group "rg-dns-resolver" # Check endpoint connectivity az network private-endpoint-connection list --resource-group "rg-dns-resolver" # View DNS resolver logs (if configured) az monitor log-analytics query --workspace "log-analytics-workspace" --analytics-query "DnsResolution | where TimeGenerated > ago(1h)"

Common Issues and Solutions:

  • Subnet Delegation: Ensure subnets are properly delegated to Microsoft.Network/dnsResolvers
  • Network Connectivity: Verify ExpressRoute or VPN connectivity between on-premises and Azure
  • Firewall Rules: Allow UDP/TCP port 53 traffic between networks
  • DNS Caching: Clear DNS caches on both sides when testing
  • Private DNS Zone Links: Ensure Private DNS zones are linked to the resolver's VNet

6.4 Best Practices

Implementation Best Practices:

  • High Availability: Configure multiple target DNS servers in forwarding rules
  • Monitoring: Enable diagnostic logs and monitoring for DNS resolution
  • Security: Use Network Security Groups to restrict access to DNS endpoints
  • Naming: Use consistent naming conventions for all DNS resolver components
  • Testing: Thoroughly test both inbound and outbound resolution before production

Summary

Azure DNS Private Resolver provides seamless bi-directional DNS resolution between Azure and on-premises networks. The implementation requires careful planning of subnet delegation, proper sequencing of component creation, and thorough testing of both inbound and outbound resolution paths. With proper configuration, it enables hybrid cloud scenarios where Azure resources and on-premises systems can resolve each other's DNS names transparently.