Manage DNS Zones in Azure

Ever deployed a production app in Azure, only to realize your custom domain doesn't resolve? Or spent an afternoon waiting for DNS changes to propagate, unsure whether you configured the zone correctly? Managing DNS zones in Azure can feel like a black box — but it doesn't have to be. In this lesson, you'll learn how to create, configure, and maintain Azure DNS zones with confidence, turning a potential headache into a straightforward, repeatable process.

The problem this lesson solves

DNS (Domain Name System) is the phonebook of the internet: it translates human-friendly names like api.myapp.com into IP addresses like 20.201.10.10. When you run applications on Azure, you almost always need to point a custom domain at your resources. But managing DNS is tedious and error-prone:

• You might be juggling multiple domain registrars, each with its own control panel.
• You might be manually copy-pasting IP addresses every time your app's public IP changes.
• You might struggle with propagation delays and wonder why changes aren't showing up.
• You might mix up record types (A, CNAME, MX, TXT) and accidentally expose your infrastructure or break email delivery.

Azure DNS solves these problems by giving you a single, cloud-based service to host your DNS zones. Instead of logging into your registrar every time, you manage everything through the Azure portal, CLI, or Infrastructure-as-Code. This lesson gives you the mental model and hands-on skills to manage DNS zones in Azure effectively.

Core concept / mental model

Think of an Azure DNS zone as a central directory for a domain. When you create a zone, you're telling Azure: "I want to manage DNS records for example.com here." The zone itself doesn't serve traffic — it's just a container for records.

Here's a word-based diagram:

Internet
   |
   | query: api.example.com
   v
Azure DNS (authoritative)
   |
   | zone: example.com
   |   records:
   |   - A     api      -> 20.201.10.10
   |   - CNAME www      -> myapp.azurewebsites.net
   |   - TXT   _acme    -> validation-token
   |   - MX    @        -> mail.example.com

Key definitions:

• DNS zone: A hosted zone for a domain. It contains all records for that domain.
• Record set: A collection of records with the same name and type — e.g., two A records for api pointing to different IPs load-balance traffic.
• Record type: The kind of data a record holds (A for IPv4, CNAME for aliases, MX for mail, TXT for verification).
• Name server (NS): Azure gives you NS records for each zone; you must update your registrar to point to these to make your zone authoritative.
• Propagation: The time it takes for DNS changes to be visible globally (usually under 10 minutes, often just seconds in Azure).

Azure DNS is global and highly available by default — you don't need to manage any virtual machines or worry about scaling.

How it works step by step

Let’s walk through the entire lifecycle of a DNS zone, from creation to delegating from your registrar.

Step 1: Create a DNS zone

You need a domain name (either newly purchased or one you already own). In the Azure portal:

1. Navigate to Create a resource → Networking → DNS zone.
2. Enter the Domain name — e.g., example.com. (Azure will warn if the name is already in use globally.)
3. Choose a Resource group and Location (location is mostly cosmetic; zones are global).
4. Click Review + create.

Step 2: Add records

After creation, you'll see default records: NS (name servers) and SOA (start of authority). Now add records specific to your app.

• A record: Maps a hostname like api to an IPv4 address (e.g., your App Service or VM's public IP).
• CNAME: Maps an alias like www to another FQDN, such as myapp.azurewebsites.net. CNAMEs can’t be used at the zone apex (@).
• MX: For mail servers.
• TXT: For domain verification (e.g., for SSL certificates or Google Workspace).

Step 3: Delegate your domain

This is the crucial step — you must tell your registrar that Azure is now authoritative for your domain.

1. In the zone’s Overview blade, copy the four Name Server records.
2. Go to your registrar (GoDaddy, Namecheap, Cloudflare, etc.) and find the DNS settings for your domain.
3. Replace the existing NS records with Azure’s values for the root domain (@).
4. Save; propagation usually completes in under 30 minutes.

Step 4: Verify and maintain

Use nslookup or dig to verify. After any change, remember: Azure uses TTL values to control caching. Lower TTLs (300 seconds) speed up propagation during testing; higher TTLs (3600) reduce DNS query load in production.

Hands-on walkthrough

Let’s put theory into practice with the Azure CLI. All commands assume you’re logged in and have a resource group ready. If you haven’t created one yet, start with the first command.

Create a resource group and DNS zone

# Create a resource group (use your preferred location)
az group create \
  --name my-dns-rg \
  --location eastus

# Create the DNS zone
az network dns zone create \
  --resource-group my-dns-rg \
  --name example.com

Expected output (truncated):

{
  "name": "example.com",
  "nameServers": [
    "ns1-01.azure-dns.com.",
    "ns2-01.azure-dns.net.",
    "ns3-01.azure-dns.org.",
    "ns4-01.azure-dns.info."
  ],
  "provisioningState": "Succeeded"
}

Add records

Now, let’s add a couple of records — an A record for api and a CNAME for www.

# Add an A record for api.example.com -> 20.201.10.10
az network dns record-set a add-record \
  --resource-group my-dns-rg \
  --zone-name example.com \
  --record-set-name api \
  --ipv4-address 20.201.10.10

# Add a CNAME for www.example.com -> myapp.azurewebsites.net
az network dns record-set cname set-record \
  --resource-group my-dns-rg \
  --zone-name example.com \
  --record-set-name www \
  --cname myapp.azurewebsites.net

List and verify records

# List all record sets
az network dns record-set list \
  --resource-group my-dns-rg \
  --zone-name example.com

# Verify public resolution (after delegation)
# Run this from anywhere — it should return Azure's name servers
nslookup -type=NS example.com

Expected output for the nslookup command:

Server:  resolver-1.example.com
Address:  192.0.2.1

Non-authoritative answer:
example.com
    nameserver = ns1-01.azure-dns.com.
    nameserver = ns2-01.azure-dns.net.

Pro tip: For production, always use Infrastructure-as-Code (Bicep or Terraform) to define your zones and records. It makes changes auditable and prevents “ghost” records from lingering when you decommission resources.

A practical automation example

Here’s a Python script using the azure.identity and azure.mgmt.dns SDKs to manage records programmatically. This is perfect for dynamic DNS updates or CI/CD pipelines.

from azure.identity import DefaultAzureCredential
from azure.mgmt.dns import DnsManagementClient
from azure.mgmt.dns.models import RecordSet, ARecord

# Replace these with your own values
SUBSCRIPTION_ID = "your-subscription-id"
RESOURCE_GROUP = "my-dns-rg"
ZONE_NAME = "example.com"

credential = DefaultAzureCredential()
dns_client = DnsManagementClient(credential, SUBSCRIPTION_ID)

# Update or create an A record
record_set = RecordSet(
    ttl=300,
    a_records=[ARecord(ipv4_address="20.201.10.10")]
)

dns_client.record_sets.create_or_update(
    resource_group_name=RESOURCE_GROUP,
    zone_name=ZONE_NAME,
    relative_record_set_name="api",
    record_type="A",
    parameters=record_set
)

print("A record for api.example.com updated successfully.")

Run the script after pip install azure-identity azure-mgmt-dns and you’ll see the confirmation message. This is a real-world pattern for keeping DNS in sync with dynamic IPs (e.g., for a home VPN or a load balancer).

Compare options / when to choose what

You have several ways to host your DNS. Here’s a comparison to guide your choice:

Key considerations:

• AKS or App Service with custom domains: Azure DNS makes it trivial to create alias records that automatically track changes in your public IP (e.g., for App Service).
• Private DNS zones: If you need internal name resolution for VMs or VNets (e.g., myapp.internal.local), Azure DNS private zones are the right choice — they don’t require delegation from a public registrar.
• Multi-cloud or hybrid: If you use other cloud providers, you might prefer a neutral option like Route53 or Cloudflare.

In short: choose Azure DNS when your workload is already on Azure and you want tight integration with IAM and monitoring. Choose registrar DNS only for prototyping.

Troubleshooting & edge cases

“My changes never propagate!” — Propagation is usually fast, but check your TTL. If it’s 3600 seconds, clients won’t see changes for an hour. Temporarily lower the TTL to 300 during maintenance windows.

Common error: “NS records not found” or “SERVFAIL”

• Cause: You haven’t delegated your domain properly at the registrar.
• Fix: Confirm the registrar’s NS records exactly match Azure’s (including trailing dots!). Usually, you need to replace the @ records, not add new ones.

CNAME at zone apex

• Error: CNAME record cannot be created at the root of the zone.
• Fix: Use an A record (if you have a static IP) or an alias record for Azure resources. Alias records are Azure’s way to simulate CNAME at the root without violating DNS standards.

Record set already exists

• Error: Conflict: Record set already exists.
• Fix: Before creating, check if a record of the same name and type exists. Use az network dns record-set list or the Get-* cmdlet; then either delete it or use update instead.

Slow propagation from legacy caches

• Some ISPs cache DNS aggressively. You can bypass by using a public resolver like dig @8.8.8.8. This is a useful testing trick.

Private zone not resolving

• Cause: The VNet isn’t linked to the private zone. In the portal, go to the private zone → Virtual network links → Add.
• Fix: Ensure the link’s registration enabled checkbox is set for auto-registration of VM DNS records.

What you learned & what's next

You now know how to manage DNS zones in Azure end-to-end: you understand the core concepts (zones, record sets, delegation), you can create and configure zones via portal or CLI, and you’ve seen a Python automation example. You’ve also learned how to choose between Azure DNS and alternatives, and how to troubleshoot common issues like delegation and CNAME root limitations.

Key takeaways:

• Azure DNS zones are containers for records; the real work is adding correct records and delegating from your registrar.
• Always check NS records at the registrar — this is the #1 cause of “DNS not working.”
• Use lower TTLs during rollouts, higher in stable production.
• Prefer alias records for Azure resources to avoid stale IPs.
• Automate with CLI or SDKs to make DNS management repeatable and version-controlled.

Now you’re ready to move to the next lesson in the Azure track, where you’ll likely integrate DNS with App Service or AKS. Go ahead and practice creating a zone for a test domain — you’ll be a DNS pro in no time.