2.1 Azure DNS & Private DNS Zones

Azure DNS & Private DNS Zones

Name resolution is the foundational dependency for all distributed systems, hybrid architectures, and service communications in Microsoft Azure. Designing an enterprise network requires a comprehensive understanding of how Azure-provided name resolution functions, when to leverage authoritative Azure Public DNS Zones, and how to structure Azure Private DNS Zones to achieve secure, split-horizon resolution across isolated virtual networks.

---

Azure-Provided DNS & the Special Virtual IP 168.63.129.16

When a Virtual Network (VNet) is created without custom DNS server settings, Azure assigns Azure-provided DNS by default. Azure-provided DNS operates through a well-known, non-routable public IP address: 168.63.129.16.

Functions of 168.63.129.16

The virtual IP address 168.63.129.16 is an internal platform communication endpoint available from all Azure virtual subnets. It performs several critical platform duties:

1. Recursive DNS Resolution: Acts as the default DNS resolver for virtual machines inside the VNet, resolving internal hostnames within the same VNet (internal.cloudapp.net) and external public Internet domains.
2. Load Balancer Health Probes: Originates platform health probe packets from Azure Standard and Basic Load Balancers to monitor VM backend pool health.
3. DHCP Services: Delivers dynamic IP address assignments, default gateway routes, and DNS server configurations to VM Network Interface Cards (NICs).
4. Azure Instance Metadata Service (IMDS): Communicates with VM Guest Agents for heartbeat monitoring, guest OS provisioning, and scheduled maintenance notifications.

+-------------------------------------------------------------------------+
|                           Azure Subnet                                  |
|                                                                         |
|   +-------------------+                     +-----------------------+   |
|   |    VM Instance    | -- DNS Query -----> |     168.63.129.16     |   |
|   |  (NIC Configured  | <-- DHCP / Probes - |  (Virtual Platform IP |   |
|   |   for Default)    |                     |   Azure SDN Fabric)   |   |
|   +-------------------+                     +-----------------------+   |
+-------------------------------------------------------------------------+

Limitations of Azure-Provided DNS

While convenient for standalone development environments, Azure-provided DNS exhibits significant constraints in enterprise networking:

• No Cross-VNet Resolution: Virtual machines in one VNet cannot resolve the hostnames of virtual machines in a different VNet, even if the VNets are connected via VNet Peering, without Private DNS Zones.
• No Custom Domain Registration: VMs receive default suffix names under *.internal.cloudapp.net. You cannot register custom domains (such as corp.contoso.com) directly into Azure-provided DNS.
• Non-Routable Outside Azure: The 168.63.129.16 resolver cannot be queried across Site-to-Site (S2S) VPN, ExpressRoute, or from on-premises datacenters.
• No Conditional Forwarding: Azure-provided DNS cannot conditionally forward specific domain queries to custom on-premises DNS servers.

---

Public DNS Zones & Record Sets

Azure DNS is a globally distributed, high-availability hosting service for authoritative DNS domains. It uses Microsoft's global Anycast name server infrastructure to provide ultra-low-latency DNS query responses and 100% availability SLA.

Supported Public Record Types

Azure DNS supports all standard DNS record types:

Alias Records & Zone Apex Hosting

A critical exam objective is understanding Alias Record Sets. Standard DNS specifications (RFC 1034 / RFC 2181) prohibit creating a CNAME record at the zone apex (@ or root domain, such as contoso.com) because the apex must also host SOA and NS records, and a CNAME cannot coexist with other record types for the same name.

Azure DNS solves this problem through Alias Records:

• Direct Resource Targeting: An Alias record points directly to the Azure Resource ID of an Azure Public IP, Azure Traffic Manager profile, Azure Front Door endpoint, or Azure CDN profile.
• Dynamic IP Synchronization: If the underlying Azure resource changes its IP address, Azure DNS updates the record automatically without manual DNS management or TTL caching delays.
• Apex Hosting: Allows naked/root domains (e.g., contoso.com) to reference Traffic Manager or Front Door profiles using an Alias A or AAAA record set.

// Azure Bicep Snippet: Zone Apex Alias Record for Traffic Manager
resource apexAliasRecord 'Microsoft.Network/dnsZones/A@2018-05-01' = {
  name: 'contoso.com/@'
  properties: {
    ttl: 3600
    targetResource: {
      id: trafficManagerProfile.id
    }
  }
}

---

Azure Private DNS Zones Architecture

Azure Private DNS Zones provide reliable, secure domain name resolution within virtual networks without needing custom VM-based DNS servers or exposing records to the public Internet.

Key Use Cases

1. Internal Microservices & Workloads: Assigning predictable hostnames (e.g., api.internal.contoso.com) to private IP addresses across peered VNets.
2. Azure Private Endpoints (Private Link): Translating PaaS private endpoints (e.g., storageaccount.privatelink.blob.core.windows.net) to internal private IP addresses (10.1.4.5).
3. Split-Horizon (Split-Brain) DNS: Maintaining identical zone names (e.g., contoso.com) where internal Azure workloads resolve private IPs (10.0.1.10) while external Internet clients query Azure Public DNS and receive public IPs (20.40.100.50).

---

Virtual Network Links: Resolution vs. Registration

To make a Private DNS Zone accessible to a Virtual Network, you must establish a Virtual Network Link (Microsoft.Network/privateDnsZones/virtualNetworkLinks). Azure defines two distinct link behaviors:

+---------------------------------------------------------------------------------------+
|                                Azure Private DNS Zone                                 |
|                            (corp.privatelink.contoso.com)                             |
+---------------------------------------------------------------------------------------+
             ^                                                       ^
             | (1. Registration Link)                                | (2. Resolution Link)
             | - Auto-creates VM A & PTR records                     | - Read-only query access
             | - Max 1 Registration Link per Zone                    | - Up to 1,000 Links per Zone
             v                                                       v
+---------------------------+                           +---------------------------+
|     Registration VNet     |                           |      Resolution VNet      |
|        (VNet-Hub)         |                           |       (VNet-Spoke1)       |
|  +---------------------+  |                           |  +---------------------+  |
|  | VM-Web01 (10.0.1.4) |  |                           |  | VM-App01 (10.1.1.4) |  |
|  +---------------------+  |                           |  +---------------------+  |
+---------------------------+                           +---------------------------+

1. Resolution Virtual Network Links

• Purpose: Enables any VM located in the linked VNet to perform forward and reverse DNS queries against records defined in the Private DNS Zone.
• Scalability: A single Private DNS Zone supports up to 1,000 Resolution Virtual Network Links.
• Behavior: Read-only access to zone records. Workloads within the VNet do not register their hostnames automatically.

2. Registration Virtual Network Links (Auto-Registration)

• Purpose: In addition to resolving zone records, the linked VNet automatically registers its VMs' hostnames as DNS A records and reverse PTR records inside the Private DNS Zone.
• Lifecycle Synchronization: When a VM is provisioned, assigned a new private IP, or terminated/deallocated, Azure automatically adds, updates, or deletes the corresponding DNS record.
• Critical Constraints:
  • A Private DNS Zone can have only ONE Registration Virtual Network Link.
  • A Virtual Network can be linked as a Registration VNet to only ONE Private DNS Zone.
  • Auto-registration Limit: Up to 100 virtual machines per VNet are automatically registered by default.

---

Public DNS vs. Private DNS Zones Comparison

---

Real-World Exam Troubleshooting Scenarios

Scenario 1: Spoke VM Fails to Resolve Private Endpoint in Hub

• Topology: Hub VNet contains an Azure Private Endpoint for Azure SQL (sql-prod.privatelink.database.windows.net -> 10.0.5.4). The private zone is linked only to Hub VNet.
• Symptom: VM in VNet-Spoke1 (peered with Hub) fails to resolve the private IP and instead receives the public IP or NXDOMAIN.
• Root Cause: VNet-Spoke1 lacks a Resolution Virtual Network Link to privatelink.database.windows.net. VNet Peering provides IP routing, but does NOT forward DNS zone linkage automatically.
• Remediation: Create a Virtual Network Link from privatelink.database.windows.net to VNet-Spoke1 with registrationEnabled: false.

Scenario 2: Second Registration Link Deployment Failure

• Topology: DevOps engineer configures privatelink.contoso.local with auto-registration enabled on VNet-A. They then deploy an ARM template linking VNet-B with registrationEnabled: true.
• Symptom: Deployment fails with error OverlappingRegistrationVirtualNetworkLinksNotAllowed.
• Remediation: Change VNet-B's link configuration to registrationEnabled: false. Only one registration link is permitted per Private DNS Zone.