Azure VNet Name Resolution - Complete Guide

Overview

Name resolution in Azure Virtual Networks (VNets) is a critical component that enables resources to communicate using friendly names instead of IP addresses. Azure provides several DNS resolution options, each with specific use cases and traffic flow patterns.

Key Concepts:

Azure-provided DNS Architecture

graph TD A[VM in VNet] -->|DNS Query| B[Azure DNS 168.63.129.16] B -->|Resolve| C[Azure Internal DNS] C -->|Return IP| B B -->|Response| A D[VM in Different VNet] -->|DNS Query| B E[Internet Resource] -->|External Query| F[Public DNS] B -->|Forward External| F F -->|Response| B B -->|Response| A style A fill:#e1f5fe style B fill:#ffecb3 style C fill:#f3e5f5 style D fill:#e8f5e8 style E fill:#fff3e0 style F fill:#fce4ec
Traffic Flow Explanation:
This diagram shows how Azure-provided DNS (168.63.129.16) handles name resolution. VMs send DNS queries to Azure's DNS service, which resolves internal Azure resources through the internal DNS system and forwards external queries to public DNS servers. The Azure DNS service acts as a recursive resolver, handling both internal Azure resource names and external internet domains.

Custom DNS Server Architecture

graph TD A[VM in VNet] -->|DNS Query| B[Custom DNS Server] B -->|Internal Query| C[Local DNS Records] B -->|Forward to Azure| D[Azure DNS 168.63.129.16] B -->|Forward External| E[Public DNS] C -->|Response| B D -->|Azure Resource Response| B E -->|External Response| B B -->|Final Response| A F[VNet DNS Settings] -->|Points to| B G[On-premises DNS] -->|Conditional Forward| B B -->|Hybrid Queries| G style A fill:#e1f5fe style B fill:#ffab40 style C fill:#81c784 style D fill:#ffecb3 style E fill:#f48fb1 style F fill:#ce93d8 style G fill:#90caf9
Traffic Flow Explanation:
With custom DNS servers, VMs send queries to your designated DNS server first. The custom DNS server checks local records, forwards Azure-specific queries to Azure DNS (168.63.129.16), and handles external queries through public DNS or on-premises infrastructure. This setup enables hybrid scenarios where on-premises DNS can conditionally forward queries to Azure DNS servers.

Azure DNS Private Zones Architecture

graph TD A[VM in VNet] -->|DNS Query| B[Azure DNS 168.63.129.16] B -->|Check Private Zone| C[Azure DNS Private Zone] C -->|Match Found| D[Private Zone Records] D -->|Return Private IP| C C -->|Response| B B -->|Private Resolution| A B -->|No Match| E[Public DNS/Azure DNS] E -->|Public Resolution| B F[VNet Link] -->|Associates| C G[Auto-registration] -->|VM Records| C style A fill:#e1f5fe style B fill:#ffecb3 style C fill:#c8e6c9 style D fill:#dcedc8 style E fill:#f8bbd9 style F fill:#b39ddb style G fill:#ffcdd2
Traffic Flow Explanation:
Azure DNS Private Zones provide authoritative DNS resolution for private domains. When a VM queries a name, Azure DNS first checks linked private zones. If a match is found, it returns the private IP address. If no match exists, the query proceeds to public DNS resolution. VNet links associate private zones with virtual networks, and auto-registration can automatically create DNS records for VMs.

Hybrid DNS Resolution Architecture

graph TD A[On-premises VM] -->|DNS Query| B[On-premises DNS] B -->|Azure Domain Query| C[DNS Forwarder in Azure] C -->|Forward to Azure DNS| D[Azure DNS 168.63.129.16] D -->|Azure Resolution| C C -->|Response| B B -->|Response| A E[Azure VM] -->|DNS Query| F[Custom DNS in Azure] F -->|On-premises Query| G[VPN/ExpressRoute] G -->|Forward to On-premises| B B -->|On-premises Resolution| G G -->|Response| F F -->|Response| E H[Private DNS Zone] -->|Linked to VNet| F I[Conditional Forwarder] -->|Routes specific domains| B style A fill:#ffecb3 style B fill:#c8e6c9 style C fill:#e1f5fe style D fill:#ffab40 style E fill:#e1f5fe style F fill:#ffab40 style G fill:#f48fb1 style H fill:#dcedc8 style I fill:#ce93d8
Traffic Flow Explanation:
Hybrid DNS resolution enables seamless name resolution between on-premises and Azure environments. On-premises DNS servers use conditional forwarders to route Azure-specific queries to DNS forwarders in Azure, which then query Azure DNS. Similarly, Azure VMs can query on-premises resources through custom DNS servers that forward queries over VPN or ExpressRoute connections.

DNS Query Resolution Flow

sequenceDiagram participant VM as Azure VM participant DNS as DNS Server participant PZ as Private Zone participant AD as Azure DNS participant PD as Public DNS VM->>DNS: DNS Query (example.com) DNS->>PZ: Check Private Zone alt Private Zone Match PZ->>DNS: Return Private IP DNS->>VM: Private IP Response else No Private Zone Match DNS->>AD: Check Azure DNS alt Azure Resource AD->>DNS: Return Azure IP DNS->>VM: Azure IP Response else External Domain AD->>PD: Forward Query PD->>AD: Public IP Response AD->>DNS: Public IP Response DNS->>VM: Public IP Response end end
Sequence Flow Explanation:
This sequence diagram shows the complete DNS resolution process. When a VM makes a DNS query, it first checks private zones for matches. If found, it returns the private IP immediately. If not found, it checks Azure DNS for Azure resources or forwards to public DNS for external domains. This hierarchical approach ensures efficient resolution with proper priority handling.

Command Implementation Flow

graph LR A[1. Create Resource Group] --> B[2. Create VNet] B --> C[3. Create Subnet] C --> D[4. Configure DNS Settings] D --> E[5. Create Private DNS Zone] E --> F[6. Link VNet to Private Zone] F --> G[7. Create DNS Records] G --> H[8. Create VMs] H --> I[9. Configure Custom DNS] I --> J[10. Test Resolution] style A fill:#ffcdd2 style B fill:#f8bbd9 style C fill:#e1bee7 style D fill:#c5cae9 style E fill:#bbdefb style F fill:#b2dfdb style G fill:#c8e6c9 style H fill:#dcedc8 style I fill:#f0f4c3 style J fill:#fff9c4
Command Flow Explanation:
This diagram shows the logical order of Azure CLI commands needed to implement DNS resolution. Each step builds upon the previous one, starting with basic infrastructure (resource group, VNet, subnet), then configuring DNS components (private zones, links, records), and finally creating and configuring VMs with custom DNS settings.

Step-by-Step Implementation

Step 1: Create Resource Group

az group create \ --name myResourceGroup \ --location eastus
Parameters Explanation: Alternative Options:
Command Flow Context:
This is the first command in the sequence. Resource groups are logical containers that hold related resources. All subsequent resources will be created within this group, making management and cleanup easier.

Step 2: Create Virtual Network

az network vnet create \ --resource-group myResourceGroup \ --name myVNet \ --address-prefix 10.0.0.0/16 \ --location eastus
Parameters Explanation: Alternative Options:
Command Flow Context:
This is the second command in the sequence. The VNet provides the network foundation for all resources. The address prefix determines the IP range available for subnets and resources within this VNet.

Step 3: Create Subnet

az network vnet subnet create \ --resource-group myResourceGroup \ --vnet-name myVNet \ --name mySubnet \ --address-prefix 10.0.1.0/24
Parameters Explanation: Alternative Options:
Command Flow Context:
This is the third command in the sequence. Subnets segment the VNet into smaller networks. Resources like VMs will be deployed into these subnets. The subnet address prefix must be a subset of the VNet address space.

Step 4: Create Private DNS Zone

az network private-dns zone create \ --resource-group myResourceGroup \ --name contoso.local
Parameters Explanation: Alternative Options: Best Practices:
Command Flow Context:
This is the fourth command in the sequence. Private DNS zones provide authoritative DNS resolution for private domains. This zone will handle name resolution for the specified domain within linked VNets.

Step 5: Link VNet to Private DNS Zone

az network private-dns link vnet create \ --resource-group myResourceGroup \ --zone-name contoso.local \ --name myVNetLink \ --virtual-network myVNet \ --registration-enabled true
Parameters Explanation: Alternative Options:
Command Flow Context:
This is the fifth command in the sequence. VNet links associate private DNS zones with virtual networks. With registration enabled, VMs created in the linked VNet will automatically have DNS records created in the private zone.

Step 6: Create DNS A Record

az network private-dns record-set a create \ --resource-group myResourceGroup \ --zone-name contoso.local \ --name webapp
az network private-dns record-set a add-record \ --resource-group myResourceGroup \ --zone-name contoso.local \ --record-set-name webapp \ --ipv4-address 10.0.1.10
Parameters Explanation: Alternative Record Types:
Command Flow Context:
These are the sixth and seventh commands in the sequence. DNS records define name-to-IP mappings. The first command creates an empty record set, and the second adds the actual IP address. This two-step process allows for multiple IP addresses per name.

Step 7: Create Virtual Machine

az vm create \ --resource-group myResourceGroup \ --name myVM \ --image Ubuntu2204 \ --subnet mySubnet \ --vnet-name myVNet \ --admin-username azureuser \ --generate-ssh-keys \ --size Standard_B2s
Parameters Explanation: Alternative Options:
Command Flow Context:
This is the eighth command in the sequence. The VM is created in the subnet and will automatically use Azure-provided DNS (168.63.129.16) unless custom DNS is configured. If auto-registration is enabled, a DNS record will be created automatically.

Step 8: Configure Custom DNS Server

az network vnet update \ --resource-group myResourceGroup \ --name myVNet \ --dns-servers 10.0.1.4 168.63.129.16
Parameters Explanation: DNS Server Options: Important Notes:
Command Flow Context:
This is the ninth command in the sequence. This command configures the VNet to use custom DNS servers. All VMs in the VNet will use these DNS servers for name resolution. VMs need to be restarted for the change to take effect.

Step 9: Create DNS Forwarder VM

az vm create \ --resource-group myResourceGroup \ --name dnsForwarder \ --image Ubuntu2204 \ --subnet mySubnet \ --vnet-name myVNet \ --admin-username azureuser \ --generate-ssh-keys \ --size Standard_B1s \ --private-ip-address 10.0.1.4
Parameters Explanation: Post-Creation Setup Required:
Command Flow Context:
This is the tenth command in the sequence. This VM will act as a DNS forwarder, receiving DNS queries from other VMs and forwarding them to appropriate DNS servers based on the domain being queried.

Step 10: Test DNS Resolution

# Test from within a VM nslookup webapp.contoso.local
# Test Azure DNS resolution nslookup myVM.internal.cloudapp.net
# Test external DNS resolution nslookup microsoft.com
Test Commands Explanation: Alternative Testing Tools:
Command Flow Context:
These are the final validation commands. Run these from within VMs to verify that DNS resolution is working correctly for private zones, Azure resources, and external domains.

Advanced DNS Configuration

Conditional Forwarding Setup

# Create conditional forwarder rule az network dns forwarding-rule create \ --resource-group myResourceGroup \ --ruleset-name myForwardingRuleset \ --name azureForwarding \ --domain-name "azure.local" \ --forwarding-targets '[{"ip":"168.63.129.16","port":53}]'
Parameters Explanation: Use Cases:

Private DNS Zone with Multiple VNets

# Link additional VNet to same private DNS zone az network private-dns link vnet create \ --resource-group myResourceGroup \ --zone-name contoso.local \ --name myVNet2Link \ --virtual-network myVNet2 \ --registration-enabled false
Parameters Explanation: Multi-VNet Scenarios:

DNS Resolution Scenarios

graph TD A[DNS Query Types] --> B[Internal Azure Resources] A --> C[Private DNS Zones] A --> D[External Domains] A --> E[On-premises Resources] B --> F[VM Names] B --> G[PaaS Services] B --> H[Load Balancers] C --> I[Custom Domains] C --> J[Application Services] C --> K[Database Services] D --> L[Internet Sites] D --> M[Public APIs] D --> N[CDN Endpoints] E --> O[Domain Controllers] E --> P[File Servers] E --> Q[Legacy Applications] style A fill:#ffcdd2 style B fill:#f8bbd9 style C fill:#e1bee7 style D fill:#c5cae9 style E fill:#bbdefb
DNS Query Types Explanation:
This diagram categorizes different types of DNS queries and their typical use cases. Each category requires different DNS resolution strategies and may involve different DNS servers or forwarding rules.

Best Practices and Troubleshooting

Common Issues:
Performance Optimization:

Monitoring and Validation

# Check DNS configuration az network vnet show \ --resource-group myResourceGroup \ --name myVNet \ --query dhcpOptions.dnsServers
# List private DNS zones az network private-dns zone list \ --resource-group myResourceGroup \ --output table
# Check VNet links az network private-dns link vnet list \ --resource-group myResourceGroup \ --zone-name contoso.local \ --output table
Monitoring Commands:

Summary

Azure VNet name resolution provides flexible options for DNS resolution in cloud and hybrid environments. The key components work together to provide seamless name resolution:

Component Purpose When to Use
Azure-provided DNS Default DNS service Simple scenarios, Azure resources only
Custom DNS Servers Advanced DNS control Complex routing, hybrid scenarios
Private DNS Zones Private domain resolution Internal applications, microservices
DNS Forwarding Conditional forwarding Multi-environment, selective routing
Remember: Always test DNS resolution after configuration changes and monitor performance to ensure optimal operation. DNS is critical infrastructure that affects all network communication.