Lesson 17 — DNS in Azure

Domain 4 — Networking AZ-104: 15–20% ~25 min Prereq: VNets, Private Endpoints

Why DNS Matters for Azure Administrators

DNS is the nervous system of every network, and Azure's DNS story has three distinct layers that every AZ-104 candidate must understand: public DNS hosting (Azure DNS), private DNS zones for VNet-internal resolution, and the specialised private endpoint DNS zones that make PaaS service private connectivity actually work.

In the exam, DNS scenarios appear in the context of hybrid connectivity, private endpoints, and custom DNS configuration. Getting these wrong in production leads to silent failures — traffic resolves to a public IP instead of the private endpoint, or on-premises clients cannot reach Azure private zones. This lesson gives you the complete mental model.

1. Azure DNS — Public Zones

Azure DNS is a hosting service for DNS domains. You can host your public DNS domains in Azure and manage DNS records using the same RBAC and tools as all your other Azure resources. Azure DNS is backed by Microsoft's global anycast network, delivering high availability and fast resolution worldwide.

Critical distinction Azure DNS is NOT a domain registrar. You cannot buy domain names from Azure DNS. You register domains at a registrar (GoDaddy, Namecheap, your ISP, etc.) and then delegate the NS records from the registrar to Azure DNS. Once delegated, Azure becomes authoritative for that zone.

How delegation works

  1. Register contoso.com at your domain registrar.
  2. Create a DNS zone called contoso.com in Azure DNS.
  3. Azure assigns four name server hostnames to your zone (e.g. ns1-01.azure-dns.com).
  4. At your registrar, update the NS records for contoso.com to point to these four Azure name servers.
  5. Azure DNS is now authoritative for contoso.com.
Azure RBAC integration Because Azure DNS is a first-class Azure resource, you can control who can create, modify, or delete DNS records using standard RBAC role assignments. The built-in DNS Zone Contributor role grants full control over DNS records without giving access to other Azure resources — critical for least-privilege scenarios.

2. DNS Record Types

Azure DNS supports the full set of standard DNS record types. The following table covers every type you need to know for the exam:

Record TypePurposeExam Notes
A Maps a hostname to an IPv4 address Most common record type
AAAA Maps a hostname to an IPv6 address Same semantics as A but for IPv6
CNAME Alias — points one hostname to another FQDN Cannot be used at the zone apex (e.g. contoso.com itself). Can be used for subdomains like www.contoso.com.
MX Mail exchange — specifies mail servers for the domain Points to an FQDN (not an IP). Lower priority number = higher preference.
TXT Arbitrary text — used for domain verification, SPF, DKIM, DMARC Common in exam scenarios involving email security and domain ownership verification
SRV Service location — specifies host and port for a service Used by protocols like SIP, XMPP, Kerberos
NS Name server — delegates a DNS zone to a set of name servers Auto-created by Azure when you create a zone. Used for subdomain delegation.
SOA Start of authority — zone metadata (primary NS, contact, serial number) Auto-created and managed by Azure. One per zone.
PTR Reverse DNS — maps an IP address back to a hostname Used for reverse lookup zones (e.g. 1.0.168.192.in-addr.arpa)
CAA Certification Authority Authorization — specifies which CAs may issue certs for the domain Security hardening — prevents mis-issuance by rogue CAs
Alias Azure DNS extension — points to Azure resources directly (see below) Can be used at the zone apex — solves the CNAME-at-apex problem

3. Alias Records — Solving the Apex Problem

The DNS specification (RFC 1912) prohibits CNAME records at the zone apex — you cannot create a CNAME for contoso.com itself, only for subdomains like www.contoso.com. This is a problem when you want the root domain to point to an Azure resource that has a dynamic IP (like a Load Balancer).

Azure Alias records solve this. They are an Azure DNS extension that lets you create a record at the zone apex that points directly to:

  • Azure Public Load Balancer (Standard SKU)
  • Azure Traffic Manager profile
  • Azure CDN endpoint
  • Azure Front Door
Why Alias records are better than CNAME Alias records are tightly coupled to the Azure resource. If the underlying resource's IP address changes, Azure DNS automatically updates the resolved IP — there is no stale DNS record problem. During resolution, Azure DNS replaces the alias with the current IP of the target resource inline, so external resolvers see an A/AAAA record, not a CNAME chain.
Exam trap: CNAME vs. Alias at apex If an exam question asks how to point contoso.com (the root/apex domain, not a subdomain) to an Azure Load Balancer or Traffic Manager — the answer is always an Alias record. A CNAME at the apex is technically invalid and Azure DNS will reject it.

4. Private DNS Zones

A Private DNS Zone is a DNS zone that is only resolvable from within Azure VNets that are linked to it — it does not appear on the public internet. Private DNS zones are the primary mechanism for internal name resolution in Azure, replacing the need for custom DNS server VMs in most pure-Azure scenarios.

VNet links and auto-registration

To use a private DNS zone from a VNet, you must create a VNet link. Each link can be configured in one of two modes:

Link TypeBehaviourLimit
Auto-registration enabled Azure automatically creates and removes A records for VMs in the linked VNet as they start, stop, or are deleted. Records use the VM's hostname. A VNet can be linked with auto-registration to only ONE private DNS zone
Resolution only VMs in the linked VNet can resolve names in the private DNS zone, but records are not automatically created. A VNet can have resolution-only links to multiple private DNS zones
Auto-registration limit — common exam trap A VNet can be configured for auto-registration in only one private DNS zone. However, you can link that same VNet for resolution (without auto-registration) to up to 1,000 private DNS zones. These are different link types — do not confuse them.

Use cases

  • Internal naming for Azure VMs — VMs get a predictable FQDN like vm-api-prod-001.internal.contoso.com
  • Name resolution for PaaS services accessed over Private Endpoints (critical — see next section)
  • Multi-VNet environments where VMs in different VNets need to resolve a shared internal namespace

5. Private Endpoint DNS — The Critical Configuration

When you create a Private Endpoint for a PaaS service (covered in Lesson 16), the service's public FQDN must resolve to the private endpoint's private IP address — not the public Azure IP. This requires a specific private DNS zone named exactly according to Microsoft's privatelink naming convention.

This is the most exam-tested DNS configuration in AZ-104 If the private DNS zone does not exist, is named incorrectly, or is not linked to the VNet, traffic will bypass the private endpoint entirely and go to the public endpoint. This breaks network isolation — VMs can still reach the service, but they do so over the public internet, not through the private IP.

Private DNS zone names per service

Azure ServiceRequired Private DNS Zone
Azure Storage — Blobprivatelink.blob.core.windows.net
Azure Storage — Fileprivatelink.file.core.windows.net
Azure Storage — Queueprivatelink.queue.core.windows.net
Azure Storage — Tableprivatelink.table.core.windows.net
Azure Key Vaultprivatelink.vaultcore.azure.net
Azure SQL Databaseprivatelink.database.windows.net
Azure App Service / Functionsprivatelink.azurewebsites.net
Azure Cosmos DB (SQL)privatelink.documents.azure.com
Azure Container Registryprivatelink.azurecr.io
Azure Service Busprivatelink.servicebus.windows.net

How it works end-to-end

  1. Private Endpoint is created for mykeyvault.vault.azure.net. Azure assigns it a private IP (e.g. 10.1.1.5).
  2. Azure creates a DNS A record: mykeyvault.privatelink.vaultcore.azure.net → 10.1.1.5 in the private DNS zone.
  3. Azure public DNS returns a CNAME: mykeyvault.vault.azure.net → mykeyvault.privatelink.vaultcore.azure.net.
  4. When a VM in the linked VNet queries mykeyvault.vault.azure.net, Azure DNS follows the CNAME to the private zone and returns 10.1.1.5.
  5. Traffic flows over the private IP through the VNet to the Private Endpoint — never over the public internet.
Auto-registration vs. manual registration When you create a Private Endpoint and configure DNS integration in the portal, Azure automatically creates the A record in the private DNS zone. If you create the private endpoint via ARM/Bicep/Terraform without DNS integration, you must create the A record manually.

6. DNS Resolution Flow for Azure VMs

By default, Azure configures VMs to use 168.63.129.16 as their DNS server. This is a virtual IP managed by the Azure platform — it is always reachable from within any Azure VNet and is not a real machine.

What 168.63.129.16 resolves

  • All public internet DNS names (acts as a recursive resolver via Microsoft's resolvers)
  • Private DNS zones linked to the VNet the VM is in
  • Auto-registered VM names from private DNS zones
  • Internal Azure platform names (e.g. IMDS endpoint, health probe IPs)
Azure VM query: "mykeyvault.vault.azure.net" │ ▼ 168.63.129.16 (Azure DNS) ├─ Check: is this name in any linked private DNS zone? │ YES → return private IP from privatelink zone └─ NO → recursive public DNS resolution └─ return public IP (bypasses Private Endpoint!)
Custom DNS servers — the forwarding requirement If you configure a custom DNS server (e.g. a Windows Server DNS VM) in the VNet's DNS settings, VMs will send queries to that custom server. The custom server must be configured to forward unresolved queries back to 168.63.129.16. If it doesn't, VMs lose the ability to resolve Azure private zones and Azure platform endpoints. This is a very common misconfiguration in hybrid environments.

7. Azure DNS Private Resolver

The Azure DNS Private Resolver is a managed, serverless DNS forwarding service that replaces the traditional pattern of running custom DNS VMs in Azure for hybrid DNS scenarios. It eliminates the operational overhead of maintaining DNS VMs (patching, HA, scaling).

ComponentDirectionPurpose
Inbound endpoint On-premises → Azure A private IP in your VNet. On-premises DNS servers forward queries for Azure private zones to this IP. The Private Resolver then resolves them using Azure DNS (including private zones).
Outbound endpoint Azure → On-premises Sends DNS queries from Azure VMs to on-premises DNS. Configured via forwarding rulesets — e.g. forward corp.local queries to on-premises DNS server 192.168.1.10.
Why prefer Private Resolver over custom DNS VMs Custom DNS VMs require: high availability (at least 2 VMs per region), OS patching, Windows Server licences, and manual forwarding rule management. The Private Resolver is a fully managed PaaS service deployed within your VNet subnets — no VMs to manage. It is the current recommended pattern for hybrid DNS.

Deployment requirements

  • Inbound and outbound endpoints are deployed into dedicated subnets (minimum /28) within a VNet.
  • Subnets used for Private Resolver endpoints cannot contain other resources.
  • Forwarding rulesets (for outbound) are associated with VNets — they define conditional forwarding rules (domain name → target DNS server IP).

8. Hybrid DNS Architecture

In hybrid environments where Azure VNets connect to on-premises networks via VPN or ExpressRoute, DNS resolution must work bidirectionally. The following architecture uses the DNS Private Resolver (preferred modern approach):

── On-premises clients resolve Azure private names ── On-prem DNS server └─ Conditional forwarder: "privatelink.*.net" → [Inbound Endpoint IP] └─ Private Resolver Inbound Endpoint (e.g. 10.0.1.4) └─ Azure DNS 168.63.129.16 └─ Returns: private IP from linked private zone ── Azure VMs resolve on-premises names ── Azure VM → 168.63.129.16 (Azure DNS) └─ Outbound forwarding ruleset: "corp.local" → 192.168.1.10 └─ Private Resolver Outbound Endpoint └─ On-premises DNS server → returns corp.local record
Older pattern: custom DNS VMs Before the DNS Private Resolver was available, the standard pattern was to deploy Windows Server DNS VMs in Azure, configure them with conditional forwarders, and point VNet DNS settings to these VMs. You may still encounter this in older deployments and in exam scenarios. The mechanics are the same — the key difference is operational (managed service vs. VM). Both patterns require forwarding unresolved queries to 168.63.129.16.

9. DNS TTL and Operational Considerations

TTL (Time-To-Live) controls how long DNS resolvers cache a record before re-querying the authoritative server. The right TTL depends on the stability of the record.

ScenarioRecommended TTLReasoning
Pre-migration (before a planned DNS change) 60 seconds (1 min) Lower TTL 24–48 hours before migration so caches flush quickly when you cut over
Active failover / blue-green deployment 60–300 seconds Fast failover requires short TTL so clients pick up the new IP quickly
Stable production records (e.g. MX, NS) 3600 seconds (1 hr) or higher High TTL reduces DNS query load and improves resolution performance
Traffic Manager weighted routing (A/B test) 0–30 seconds Traffic Manager overrides TTL for fast rerouting — set the profile's TTL, not the individual record
TTL during DR events When a failover is needed urgently but your TTL is set to 3600 seconds, clients will continue hitting the old endpoint until their cache expires. This is why you should pre-emptively lower TTL before planned maintenance windows. In an unplanned DR event, you are at the mercy of whatever TTL you had configured — this is why 300–600 seconds is a common operational default for externally-facing records.

Check Your Understanding

Click any option to see immediate feedback. Answers reflect real Azure DNS behaviour.

1. You link a VNet to a private DNS zone named internal.contoso.com with auto-registration enabled. You then try to link the same VNet with auto-registration to a second private DNS zone named backend.contoso.com. What happens?

Azure enforces a hard limit: each VNet can be linked with auto-registration to exactly ONE private DNS zone. You can create additional resolution-only links to as many other private DNS zones as needed. Attempting to enable auto-registration on a second zone returns an error in the portal and a 400 error via API.

2. Your company wants to point contoso.com (the root/apex domain, not www.contoso.com) to an Azure Traffic Manager profile. What DNS record type must you create in Azure DNS?

CNAME records cannot be placed at the zone apex — this is a hard constraint in the DNS specification (RFC 1912). Azure Alias records were specifically created to solve this problem. An Alias record at the apex can point to Azure Load Balancer (Standard), Traffic Manager, Azure CDN, or Azure Front Door, and Azure DNS resolves it to the current IP inline.

3. You configure a custom DNS server VM in a VNet's DNS settings. Azure VMs in that VNet can resolve on-premises names correctly, but they can no longer resolve names in private DNS zones linked to the VNet. What is the most likely cause?

When a custom DNS server is configured, all VM queries go to that server. The custom DNS server must have a conditional forwarder (or a catch-all forwarder) pointing to 168.63.129.16 for any names it cannot resolve locally. Without this, private DNS zone names and Azure platform endpoints (like the IMDS at 169.254.169.254) fail to resolve.

4. You create a Private Endpoint for an Azure Key Vault named myvault. A VM in the linked VNet queries myvault.vault.azure.net and receives the public IP instead of the private endpoint IP. The VM can reach the Key Vault but over the public internet. What configuration is most likely missing?

Without the correct private DNS zone (privatelink.vaultcore.azure.net), Azure DNS follows the public CNAME chain for myvault.vault.azure.net and returns the public IP. The zone must be exactly named privatelink.vaultcore.azure.net (not privatelink.vault.azure.net), the A record for myvault must be in it pointing to the private IP, and the zone must be linked to the VNet where the VM resides.

5. Your organisation wants on-premises clients to resolve Azure private DNS zones, and Azure VMs to resolve on-premises corporate hostnames — without managing any DNS VMs in Azure. What is the recommended modern architecture?

Azure DNS Private Resolver is the modern managed alternative to custom DNS VMs. Inbound endpoints receive queries from on-premises DNS servers (via conditional forwarders). Outbound endpoints, governed by forwarding rulesets, forward Azure VM queries for corporate domains to on-premises DNS servers. No VMs to manage, no patching, and it scales automatically.

6. You manage the DNS for contoso.com in Azure DNS. You need to configure email so that messages to @contoso.com are accepted by your mail provider at mail.mailprovider.com (higher priority) and backup.mailprovider.com (lower priority). Which configuration is correct?

MX records define mail server preferences. The priority value is a number where lower numbers mean higher priority — so priority 10 is preferred over priority 20. MX records must point to FQDNs (not IP addresses). Setting mail.mailprovider.com at priority 10 and backup.mailprovider.com at priority 20 makes the first server the primary mail exchanger.
Primary source for this lesson Azure DNS overview — Microsoft Learn

Read the Private DNS zone overview, the Private Endpoint DNS configuration docs, and the DNS Private Resolver overview. Pay special attention to the private DNS zone names for each PaaS service — these are frequently tested.

Questions for your teacher (the AI agent)
This lesson covered Azure DNS architecture end to end. Go deeper on any of these:
  • Walk me through configuring a complete private endpoint DNS setup for an Azure SQL Database using Bicep.
  • How do you set up split-horizon DNS so internal clients resolve a name to a private IP while external clients resolve to the public IP?
  • What is DNSSEC and does Azure DNS support it?
  • How does Azure DNS Private Resolver differ in architecture from an Azure Firewall with DNS proxy enabled?
Coming up: Lesson 18 — Load Balancing in Azure With DNS resolved (literally), the next lesson covers how Azure distributes traffic across multiple backends. Azure has four load balancing services — Azure Load Balancer, Application Gateway, Azure Front Door, and Traffic Manager — each targeting different scenarios. You will learn exactly which to use when, a question that appears on virtually every AZ-104 exam.