This chapter covers Azure DNS and Private DNS Zones, essential for managing domain name resolution in Azure. For the AZ-104 exam, this topic appears in approximately 10-15% of networking questions, focusing on configuration, zone types, resolution behavior, and integration with virtual networks. Understanding the differences between public and private DNS, delegation, and record management is critical for passing the exam.
Jump to a section
Imagine a large corporate office building with hundreds of employees, each having a direct phone extension (like an IP address). The company maintains a phone directory (DNS) that maps employee names to their extensions. When you want to call someone, you look up their name in the directory and dial the extension. Now, the company has two types of directories: one public (Azure Public DNS) that lists employees who interact with external clients, and one private (Azure Private DNS) that only lists internal staff. The private directory is only accessible from inside the office phones (virtual network). If an employee changes desks (moves to a different subnet), the directory must be updated with the new extension. Similarly, if a new employee joins, their name and extension are added. The phone system uses a hierarchical structure: the top-level is the company name (domain), then department (subdomain), then individual name (record). When you dial a name, the system queries the directory, starting from the root (.) and going down to the specific record. If the directory is misconfigured, you might get the wrong extension or no answer at all.
What is Azure DNS?
Azure DNS is a hosting service for DNS domains that provides name resolution using Microsoft Azure infrastructure. It allows you to manage your DNS records using the same credentials, APIs, and billing as your other Azure services. Azure DNS supports both public and private DNS zones. Public DNS zones are resolvable from the internet, while private DNS zones are resolvable only within specified virtual networks.
Why Use Azure DNS?
Azure DNS eliminates the need to manage your own DNS servers. It provides high availability and low latency because it leverages the global Azure network of DNS servers. You can automate DNS management via Azure CLI, PowerShell, or ARM templates. It integrates with Azure RBAC for fine-grained access control.
DNS Zone Types
Public DNS Zone: Hosts DNS records for a domain that is publicly resolvable. Example: contoso.com. You must delegate the domain to Azure DNS by updating the registrar's name server records with the Azure DNS name servers.
Private DNS Zone: Hosts DNS records for a domain that is only resolvable within one or more Azure virtual networks. Example: internal.contoso.com. VMs in the linked VNet can resolve names without custom DNS servers.
How Private DNS Zones Work
Private DNS zones are associated with Azure virtual networks through a link. There are two types of links: - Registration VNet: The VNet where VMs are automatically registered with their private IP addresses. Only one registration VNet per zone is allowed. - Resolution VNet: VNets that can resolve names in the zone but do not auto-register. Multiple resolution VNets can be linked.
When a VM in a registration VNet is created, Azure automatically creates an A record in the private zone for its hostname. When the VM is deleted, the record is removed. The DNS resolution follows the standard DNS hierarchy: the VM queries the Azure-provided DNS (168.63.129.16), which checks private zones linked to the VNet before falling back to public DNS.
Record Types and TTL
Azure DNS supports common record types: A, AAAA, CNAME, MX, NS, PTR, SOA, SRV, TXT. Each record has a Time-to-Live (TTL) value, default is 3600 seconds (1 hour). TTL affects how long DNS resolvers cache the record. Lower TTLs reduce caching but increase query load.
Zone Delegation
For public zones, delegation is required. Azure DNS provides a set of name servers (NS records) for your zone. You must configure your domain registrar to use these name servers. The format is: ns1-01.azure-dns.com, ns2-01.azure-dns.net, ns3-01.azure-dns.org, ns4-01.azure-dns.info. The suffix varies by zone location.
DNS Resolution Flow
Client queries the Azure-provided DNS resolver (168.63.129.16).
The resolver checks if there is a private DNS zone linked to the VNet that matches the query.
If found, it returns the record from the private zone.
If not found, it performs a public DNS resolution.
For public zones, the resolver queries the Azure DNS name servers.
Split-Horizon DNS
Azure DNS supports split-horizon DNS using the same zone name for both public and private. For example, contoso.com can have a public zone with records for external services (e.g., www.contoso.com) and a private zone with internal records (e.g., db.contoso.com). VMs in the linked VNet will resolve db.contoso.com to the private IP, while external clients see the public record.
Limitations and Defaults
Maximum number of private DNS zones per subscription: 1000 (soft limit, can be increased).
Maximum number of record sets per zone: 10,000 (soft limit).
Maximum number of VNets per private zone: 10 (registration) and 100 (resolution).
Auto-registration only works for VMs with private IPs; it does not support load balancers or other resources.
Private zones cannot be used for reverse DNS lookup of Azure IPs; use Azure-provided reverse DNS.
Configuration with Azure CLI
# Create a resource group
az group create --name MyResourceGroup --location eastus
# Create a private DNS zone
az network private-dns zone create --resource-group MyResourceGroup --name private.contoso.com
# Link a VNet for registration
az network private-dns link vnet create \
--resource-group MyResourceGroup \
--zone-name private.contoso.com \
--name MyLink \
--virtual-network MyVNet \
--registration-enabled true
# Add a manual A record
az network private-dns record-set a add-record \
--resource-group MyResourceGroup \
--zone-name private.contoso.com \
--record-set-name db \
--ipv4-address 10.0.0.4Verification
Use nslookup or dig from a VM in the linked VNet:
nslookup db.private.contoso.comShould return the private IP. For public zones, you can query from anywhere:
nslookup www.contoso.comInteraction with Custom DNS Servers
If a VNet uses custom DNS servers (not Azure-provided), private DNS zones are not automatically resolved. The custom DNS server must be configured to forward queries to Azure DNS (168.63.129.16) for the private zone domain. Alternatively, you can configure conditional forwarding.
Integration with Azure Private Link
Private DNS zones are commonly used with Azure Private Link to resolve private endpoints. When you create a private endpoint, you can integrate it with a private DNS zone to automatically create DNS records. For example, a private endpoint for Azure SQL Database can create an A record in privatelink.database.windows.net zone.
Monitoring and Logging
Azure DNS provides diagnostic logs for DNS queries. You can enable logging for public zones to monitor query volume and errors. Private zones do not currently support diagnostic logs.
Exam-Relevant Details
The default TTL for SOA record is 3600 seconds.
Azure DNS supports alias records for Azure resources (e.g., Traffic Manager profiles, CDN endpoints).
When using custom DNS servers, private DNS zones are not resolved unless configured.
Auto-registration creates A records (not PTR).
The registration VNet must be in the same region as the private zone? No, it can be in any region.
You cannot link a VNet to a private zone if the VNet already has a custom DNS server configured? Incorrect; you can link, but auto-registration may not work as expected. Actually, auto-registration works regardless of custom DNS servers; the VMs still register with Azure DNS.
Common Exam Scenarios
You need to ensure that VMs in VNet A can resolve names in a private zone, but VMs in VNet B cannot. Solution: Link only VNet A as a resolution VNet.
You want VMs to automatically register their hostnames. Solution: Create a private zone and link the VNet with registration enabled.
You have an on-premises network connected via VPN. To resolve private zone names from on-premises, you need to configure conditional forwarding on your on-premises DNS servers to Azure DNS (168.63.129.16).
Create a Private DNS Zone
Use Azure Portal, CLI, or PowerShell to create a private DNS zone. Specify the zone name (e.g., `internal.contoso.com`). The zone is created in a resource group and region. The region does not affect resolution; private zones are global within a subscription. The zone will have default SOA and NS records. The NS records are for delegation within Azure; they are not used for external delegation.
Link a Virtual Network
Create a virtual network link to associate the private zone with a VNet. You must specify the link name, the VNet ID, and whether registration is enabled. Registration enabled means VMs in that VNet will automatically create A records for their hostnames. Only one VNet per zone can have registration enabled. You can link up to 100 resolution VNets (without registration). The link must be in the same subscription as the zone.
Verify Auto-Registration
After linking a VNet with registration enabled, any VM that is created in that VNet and has a private IP will automatically have an A record created in the zone. The record name is the hostname (without domain). For example, a VM named `web-vm` with private IP 10.0.0.5 gets an A record `web-vm.internal.contoso.com` pointing to 10.0.0.5. When the VM is deleted, the record is removed within a few minutes. Auto-registration does not work for VMs with public IPs only; they must have a private IP.
Add Manual Records
You can add manual A, CNAME, MX, etc. records to the private zone. For example, create an A record for a load balancer frontend IP. Manual records persist even if the target resource changes. You can also create alias records that point to Azure resources like internal load balancers. Alias records automatically update if the resource IP changes.
Test Resolution from a VM
From a VM in a linked VNet, use `nslookup` or `dig` to query the private zone name. The VM's DNS resolver (168.63.129.16) will check linked private zones first. If the name is found, it returns the private IP. If not, it falls back to public DNS. Ensure the VM is using the Azure-provided DNS (default) for this to work. If using custom DNS servers, you must configure conditional forwarding.
Enterprise Scenario 1: Internal Service Discovery
A large enterprise runs hundreds of microservices in Azure VMs across multiple VNets. They want internal DNS names like payment-service.internal.contoso.com to resolve to the private IP of the service. They create a private DNS zone internal.contoso.com and link all VNets as resolution VNets. Each service VM is deployed in a registration VNet (e.g., a management VNet) to auto-register its hostname. This eliminates the need for manual DNS updates when VMs scale in/out. The challenge is ensuring that all VNets are linked; forgetting to link a new VNet causes resolution failures. They use Azure Policy to enforce linking.
Enterprise Scenario 2: Hybrid DNS Resolution
A company has an on-premises data center connected to Azure via ExpressRoute. They want on-premises servers to resolve private zone names. They deploy a DNS forwarder on-premises (e.g., Windows Server) that forwards queries for internal.contoso.com to Azure DNS (168.63.129.16). The forwarder must have network connectivity to Azure (via ExpressRoute or VPN). They also configure conditional forwarding in their on-premises DNS. Common mistake: using the Azure DNS IP without ensuring the forwarder can reach it (requires proper routing). Performance is good because Azure DNS is highly available.
Scenario 3: Private Link Integration
A company uses Azure Private Link to access Azure SQL Database privately. They create a private endpoint with a private DNS zone privatelink.database.windows.net. The zone is linked to the VNet where the application VMs reside. When the private endpoint is created, Azure automatically adds an A record for the SQL server FQDN (e.g., myserver.database.windows.net) pointing to the private IP. This ensures that the application resolves the SQL server to the private IP without changing connection strings. Misconfiguration often occurs when the private DNS zone is not linked to the VNet, causing public resolution and potential data exfiltration.
What AZ-104 Tests
This topic falls under objective 4.3: Configure and manage Azure DNS zones. The exam tests your ability to:
Differentiate between public and private DNS zones.
Configure private DNS zone registration and resolution VNet links.
Understand auto-registration behavior and limitations.
Troubleshoot DNS resolution failures.
Implement split-horizon DNS.
Common Wrong Answers
"Private DNS zones are resolvable from the internet if the zone is public." This is false. Private zones are only resolvable from linked VNets. Candidates confuse public and private zones.
"You can link multiple VNets with registration enabled." False. Only one registration VNet per private zone. Candidates think you can have multiple registration VNets.
"Custom DNS servers automatically resolve private zones." False. Custom DNS servers do not automatically resolve private zones; you must configure forwarding.
"Auto-registration creates PTR records." False. It creates A records only. PTR records are not auto-created.
Key Numbers and Values
Default TTL: 3600 seconds.
Max private zones per subscription: 1000.
Max record sets per zone: 10,000.
Max resolution VNets per zone: 100.
Max registration VNets per zone: 1.
Azure DNS resolver IP: 168.63.129.16.
Edge Cases
If a VNet is linked to a private zone and also has custom DNS servers, auto-registration still works because VMs use Azure DNS for registration.
If you delete a VM, the auto-created record is removed within 5-10 minutes.
Private zones can be used with Azure App Service via regional VNet integration; the web app must be in the linked VNet.
Alias records are supported in private zones for Azure resources like internal load balancers.
How to Eliminate Wrong Answers
If an answer says "publicly resolvable" for a private zone, eliminate it.
If an answer says "multiple registration VNets," eliminate it.
If an answer says "auto-registration creates PTR records," eliminate it.
If an answer says "custom DNS servers resolve private zones without configuration," eliminate it.
Remember the Azure DNS resolver IP; questions may ask which IP to use for conditional forwarding.
Private DNS zones are only resolvable from VNets that are linked to the zone.
Only one VNet per private zone can have registration enabled for auto-registration.
Auto-registration creates A records for VM hostnames, not PTR records.
Default TTL for DNS records is 3600 seconds.
Azure DNS resolver IP is 168.63.129.16.
Custom DNS servers require conditional forwarding to resolve private zones.
Private DNS zones support alias records for Azure resources.
Maximum of 1000 private zones per subscription (soft limit).
Maximum of 10,000 record sets per zone (soft limit).
Maximum of 100 resolution VNets per private zone.
These come up on the exam all the time. Here's how to tell them apart.
Public DNS Zone
Resolvable from the internet.
Requires domain delegation from registrar.
Supports alias records for Azure resources (e.g., Traffic Manager).
Supports diagnostic logging for queries.
Can be used for reverse DNS for Azure public IPs.
Private DNS Zone
Resolvable only from linked VNets.
No delegation needed; linked via VNet links.
Supports alias records for Azure resources (e.g., internal load balancers).
No diagnostic logging currently available.
Cannot be used for reverse DNS of public IPs; only for private IPs within VNets.
Mistake
Private DNS zones are automatically accessible from all VNets in the subscription.
Correct
Private DNS zones are only accessible from VNets that are explicitly linked to the zone. You must create a VNet link for each VNet that needs resolution.
Mistake
Auto-registration creates both A and PTR records for VMs.
Correct
Auto-registration only creates A records (forward lookup). PTR records (reverse lookup) are not automatically created. You must manually add PTR records if needed.
Mistake
You can link a VNet to a private DNS zone with registration enabled even if the VNet uses custom DNS servers.
Correct
You can link the VNet, and auto-registration will still work because VMs use the Azure DNS resolver (168.63.129.16) for registration regardless of the custom DNS setting. However, resolution of the private zone from the VMs will require the custom DNS servers to forward queries to Azure DNS.
Mistake
Private DNS zones can be used for reverse DNS lookup for Azure public IP addresses.
Correct
Private DNS zones cannot be used for reverse DNS lookup of Azure public IPs. Azure provides a built-in reverse DNS service for public IPs (PTR records in public zones). For private IPs, reverse lookup is not supported by default.
Mistake
The registration VNet must be in the same region as the private DNS zone.
Correct
The registration VNet can be in any region. Private DNS zones are global resources; region selection is only for resource group location and does not affect resolution.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, you can create both a public and private DNS zone with the same name (e.g., `contoso.com`). This is called split-horizon DNS. VMs in linked VNets will resolve names using the private zone, while external clients use the public zone. Ensure the private zone contains only internal records, and the public zone contains external records.
You need to configure conditional forwarding on your on-premises DNS servers to forward queries for the private zone domain to Azure DNS (168.63.129.16). Ensure network connectivity (VPN or ExpressRoute) from on-premises to Azure. The Azure DNS resolver will respond with the private IP if the query matches a record in a linked private zone.
The auto-registered A record is automatically removed within a few minutes (typically 5-10 minutes) after the VM is deleted. You do not need to manually delete the record.
Yes, you can link a VNet from a different subscription to a private DNS zone, but both must be in the same Azure Active Directory tenant. The link is created in the zone's subscription, and you need appropriate permissions on the VNet (e.g., Network Contributor).
No, auto-registration only works for VMs that have a private IP assigned. A VM with only a public IP (unusual for Azure VMs) will not auto-register. Additionally, the VM must be in the registration VNet.
Yes, but the App Service must be integrated into a VNet (regional VNet integration). The App Service will then be able to resolve private DNS zones linked to that VNet. However, auto-registration does not apply to App Services; you must manually add DNS records.
A registration VNet allows VMs to automatically register their hostnames as A records in the private zone. Only one registration VNet per zone is allowed. A resolution VNet can resolve names in the zone but does not support auto-registration. You can have up to 100 resolution VNets per zone.
You've just covered Azure DNS and Private DNS Zones — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?