Name Resolution: Azure DNS
Configure Azure DNS for public and private name resolution — public zones, private zones, auto-registration, and DNS Private Resolver for hybrid environments.
Name Resolution: Azure DNS
Nobody memorises IP addresses. DNS translates names like app.pinnacle.com into IPs. This module covers how Azure handles DNS — from the automatic basics to the advanced DNS Private Resolver for hybrid scenarios.
🎬 Video coming soon
Azure DNS — Public, Private, and Resolver
Azure DNS — Public, Private, and Resolver
~14:00DNS is the phone book of the internet — it translates names like app.pinnacle.com into IP addresses like 10.20.1.5. Azure gives you DNS automatically for VMs in the same VNet. But when you need your own domain names, host zones for the internet, or bridge Azure and on-prem DNS, you need to understand Azure DNS.
VNet DNS Options
When you create a VNet, you choose how resources resolve DNS names:
| Option | How It Works | Limitations |
|---|---|---|
| Azure-provided DNS | Default. Azure handles resolution within the VNet automatically. | Cannot resolve names across VNets. No conditional forwarding. No custom domain names. |
| Custom DNS servers | Point VNet DNS settings to your own DNS server IPs (e.g., AD DS domain controllers). | You manage the servers, availability, and forwarding rules. |
| DNS Private Resolver | Azure-managed inbound/outbound DNS endpoints in your VNet. Replaces custom DNS VMs. | Requires its own delegated subnets. |
Exam Tip: Azure-provided DNS works great within a single VNet — VMs can resolve each other by hostname. But it cannot resolve across peered VNets, do conditional forwarding, or register custom domain names. For anything beyond single-VNet resolution, you need private DNS zones or a resolver.
The Magic IP: 168.63.129.16
Every Azure VM uses 168.63.129.16 as its DNS resolver by default. This isn’t a real server you can ping from outside — it’s Azure’s internal virtual IP that handles DNS resolution, health probes, and DHCP. You’ll see it referenced throughout Azure networking.
Public DNS Zones
Public DNS zones host your internet-facing DNS records. If Ravi owns pinnacle.com, he can manage its DNS records in Azure DNS.
🏢 Ravi’s scenario: Pinnacle Financial currently manages DNS with an external provider. Ravi migrates to Azure DNS:
- Creates a public DNS zone for
pinnacle.com - Azure assigns four name servers (e.g., ns1-03.azure-dns.com)
- Ravi updates his domain registrar to point to these Azure name servers
- Adds records: A record for
app.pinnacle.com, MX for email, TXT for verification
Important record types:
| Record Type | Purpose | Example |
|---|---|---|
| A | Maps name to IPv4 | app.pinnacle.com to 20.53.x.x |
| AAAA | Maps name to IPv6 | app.pinnacle.com to 2001:db8::1 |
| CNAME | Alias to another name | www.pinnacle.com to app.pinnacle.com |
| MX | Mail routing | pinnacle.com to mail.pinnacle.com |
| TXT | Text verification | SPF, DKIM, domain verification |
| Alias | Azure-specific — points to Azure resource | pinnacle.com to Azure Traffic Manager |
Alias records are unique to Azure DNS. They point directly to an Azure resource (public IP, Traffic Manager, Front Door, CDN) and automatically update when the resource’s IP changes. Unlike CNAME records, alias records work at the zone apex (e.g., pinnacle.com without www).
Exam Tip: Azure DNS is not a domain registrar — you cannot buy domain names through Azure DNS. You purchase domains elsewhere (e.g., Azure App Service domains, GoDaddy, Cloudflare) and delegate to Azure DNS name servers.
Private DNS Zones
Private DNS zones provide name resolution within your Azure virtual networks — no internet exposure.
☁️ Elena’s scenario: Skyline Logistics needs VMs across three peered VNets to resolve each other by name (e.g., db01.skyline.internal). She creates a private DNS zone:
- Creates private zone
skyline.internal - Links the zone to each VNet with two types of links:
| Link Type | What It Does |
|---|---|
| Registration link | VMs in the linked VNet auto-register their DNS records. Max one registration link per VNet. |
| Resolution link | VMs in the linked VNet can resolve records from the zone but don’t auto-register. No limit on resolution links. |
Key rules:
- A VNet can have only one registration link (to one private zone) but multiple resolution links
- Auto-registration creates A records for VM primary NIC IPs
- Private zones support up to 1,000 VNet links per zone
- You can have multiple private zones and link them to the same VNet for resolution
🏢 Ravi’s extension: He creates pinnacle.internal as a private zone. Hub VNet gets a registration link (so shared services VMs auto-register). Spoke VNets get resolution links (so they can look up hub VMs). Spoke VMs register in separate private zones for their own domains.
Private DNS Zones for Private Endpoints
When you create a private endpoint for a service like Azure SQL, the recommended pattern is:
- Create a private DNS zone with the service-specific name (e.g.,
privatelink.database.windows.net) - Link it to your VNets
- The private endpoint auto-registers an A record mapping the FQDN to its private IP
This means mydb.database.windows.net resolves to the private IP within your VNet instead of the public IP. More on this in Domain 4.
DNS Private Resolver
Before the DNS Private Resolver, hybrid DNS required running IaaS DNS forwarder VMs — they needed patching, HA pairs, and monitoring. The Private Resolver is a fully managed replacement.
Components:
| Component | Purpose | Subnet |
|---|---|---|
| Inbound endpoint | Receives DNS queries from on-premises (via VPN/ER). Provides a private IP that on-prem DNS can forward to. | Dedicated delegated subnet |
| Outbound endpoint | Sends DNS queries to on-premises or external DNS (conditional forwarding). Linked to DNS forwarding rulesets. | Dedicated delegated subnet |
| Forwarding ruleset | Defines where to forward queries for specific domains (e.g., forward corp.local to on-prem DNS at 192.168.1.5). | Linked to VNets |
| Feature | Forwarder VMs | DNS Private Resolver |
|---|---|---|
| Management | You manage, patch, scale | Fully managed by Azure |
| High availability | You deploy HA pairs | Built-in HA |
| Cost | VM compute costs | Per-endpoint hourly + per-query |
| Conditional forwarding | Configure on each VM | Centralised forwarding rulesets |
| Max throughput | Limited by VM size | Up to 10,000 queries/second per endpoint |
| VNet integration | Deployed in VNet | Deployed in VNet with delegated subnets |
🏢 Ravi’s hybrid DNS: On-premises DNS servers forward pinnacle.internal to the Private Resolver’s inbound endpoint IP. The resolver checks private DNS zones and returns the private IP. For on-prem domains like corp.pinnacle.local, he creates a forwarding ruleset on the outbound endpoint to forward to 192.168.1.5 (on-prem DNS).
Key Takeaways
- Azure-provided DNS works within one VNet only — no cross-VNet, no conditional forwarding
- Public DNS zones host internet-facing records; alias records auto-update for Azure resources
- Azure DNS is not a registrar — you manage domains elsewhere
- Private DNS zones enable cross-VNet resolution with registration and resolution links
- DNS Private Resolver replaces forwarder VMs with a managed service
Test Your Knowledge
Elena's VMs in VNet-A need to resolve names of VMs in VNet-B. Both VNets are peered. What's the recommended approach?
What is an alias record in Azure DNS?
Ravi needs on-premises servers to resolve Azure private DNS zones. What should he deploy?
Next up: Routing: UDRs, Route Server and NAT Gateway — Control how traffic flows with user-defined routes, understand BGP with Route Server, and configure NAT Gateway for outbound internet.