Setting Up Azure DNS for Your Domain

Azure DNS is a hosted authoritative DNS service that runs your domain’s DNS zone on Microsoft’s globally distributed infrastructure. Once you delegate your domain to Azure DNS, you manage all records through the Azure portal, CLI, or ARM templates — with the full reliability of Azure’s network behind every query response.

Step 1 — Create a DNS zone

A DNS zone in Azure holds all the records for a domain. The zone name must match the domain exactly:

# Create a resource group for DNS resources
az group create \
  --name rg-dns \
  --location eastus

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

After creation, Azure assigns four name servers to the zone. These are the name servers you will configure at your domain registrar:

# View the name servers assigned to your zone
az network dns zone show \
  --name mycompany.com \
  --resource-group rg-dns \
  --query "nameServers" \
  --output table

The output will show four name servers like:

ns1-01.azure-dns.com
ns2-01.azure-dns.net
ns3-01.azure-dns.org
ns4-01.azure-dns.info

These are different for every zone Azure creates. Do not use example name servers from documentation — always copy the actual name servers from your zone.

Note

Azure DNS name servers use four different TLDs (.com, .net, .org, .info) deliberately. This ensures that even if there is a DNS infrastructure issue affecting one TLD, queries can resolve through the others. The zone is served from all four simultaneously.

Step 2 — Add DNS records

Before delegating the domain, add your DNS records so that as soon as delegation takes effect, services are reachable. The most common record types:

A record — maps a hostname to an IPv4 address:

# Add an A record for the root domain (@) pointing to a web server
az network dns record-set a add-record \
  --resource-group rg-dns \
  --zone-name mycompany.com \
  --record-set-name "@" \
  --ipv4-address 203.0.113.10

# Add an A record for www subdomain
az network dns record-set a add-record \
  --resource-group rg-dns \
  --zone-name mycompany.com \
  --record-set-name "www" \
  --ipv4-address 203.0.113.10

CNAME record — maps a hostname to another hostname (alias). Cannot be used for the root domain (@):

# CNAME for blog subdomain pointing to a CMS platform
az network dns record-set cname set-record \
  --resource-group rg-dns \
  --zone-name mycompany.com \
  --record-set-name "blog" \
  --cname "mycompany.wordpress.com"

MX record — specifies mail servers for the domain. Priority is required (lower number = higher priority):

# MX records for Microsoft 365 mail
az network dns record-set mx add-record \
  --resource-group rg-dns \
  --zone-name mycompany.com \
  --record-set-name "@" \
  --exchange "mycompany-com.mail.protection.outlook.com" \
  --preference 0

TXT record — used for domain verification, SPF, DKIM, and DMARC:

# SPF record (allows Microsoft 365 to send mail as your domain)
az network dns record-set txt add-record \
  --resource-group rg-dns \
  --zone-name mycompany.com \
  --record-set-name "@" \
  --value "v=spf1 include:spf.protection.outlook.com -all"

# Azure AD domain verification TXT record
az network dns record-set txt add-record \
  --resource-group rg-dns \
  --zone-name mycompany.com \
  --record-set-name "@" \
  --value "MS=ms12345678"

Record sets, records, and TTL

Azure DNS organises records into record sets. A record set is a collection of records with the same name and type — for example, all the A records for www.mycompany.com form one record set. You cannot set different TTLs for individual records within the same record set; the TTL applies to the entire record set.

Set TTL when creating or updating the record set:

# Create a record set with a custom TTL (3600 seconds = 1 hour)
az network dns record-set a create \
  --resource-group rg-dns \
  --zone-name mycompany.com \
  --name "api" \
  --ttl 3600

# Add an IP to the record set
az network dns record-set a add-record \
  --resource-group rg-dns \
  --zone-name mycompany.com \
  --record-set-name "api" \
  --ipv4-address 203.0.113.20

TTL best practices: use 3600 (1 hour) as a sensible default for stable records, 300 (5 minutes) for records you expect to change soon, and 60 (1 minute) only during active migrations when you need fast propagation. High TTLs (86400 = 24 hours) work for records that rarely change — but remember that a high TTL means slow propagation if you do need to change them.

Step 3 — Delegate the domain to Azure DNS

Delegation means telling the world’s DNS infrastructure that Azure DNS is authoritative for your domain. You do this by updating the NS records at your domain registrar.

Log into your registrar’s control panel (GoDaddy, Namecheap, Cloudflare Registrar, etc.) and find the nameserver settings for your domain. Replace the existing name servers with the four Azure DNS name servers from your zone. The exact UI varies by registrar, but every registrar has a nameserver configuration section in domain management.

After saving the new name servers, the change propagates as existing NS record caches expire. The existing NS records at the root .com servers have their own TTL (typically 48 hours maximum). During propagation, some queries go to the old name servers and some to Azure DNS.

Warning

Do not remove records from your old DNS provider until propagation is complete. During the propagation window, some clients are still querying the old name servers. Keep both DNS zones in sync until you confirm delegation is fully propagated globally.

Step 4 — Verify delegation

Use nslookup or dig to confirm the delegation is in place and records are resolving:

# Check NS records against Google's resolver
# Output should show Azure DNS name servers
nslookup -type=NS mycompany.com 8.8.8.8

# With dig on Linux/macOS
dig NS mycompany.com @8.8.8.8

# Verify an A record resolves correctly via Azure DNS directly
dig A www.mycompany.com @ns1-01.azure-dns.com

# Check MX records
nslookup -type=MX mycompany.com 8.8.8.8

# Verify TXT records (SPF, domain verification)
nslookup -type=TXT mycompany.com 8.8.8.8

When delegation is complete, the NS query against 8.8.8.8 returns Azure’s name servers, and querying the Azure name servers directly returns your A records correctly.

Alias records for Azure resources

Standard A records point to static IP addresses. If the IP behind a service changes — because of scale-out, failover, or redeployment — you must manually update the DNS record or risk pointing users to the wrong address. Azure DNS alias records eliminate this by pointing directly to an Azure resource instead of an IP.

Alias records work with: Azure Traffic Manager profiles, Azure Front Door endpoints, Azure Application Gateway public IPs, and standalone Public IP Address resources. When the resource’s IP changes, the alias record automatically returns the new IP.

# Get the resource ID of a Traffic Manager profile
TM_ID=$(az network traffic-manager profile show \
  --name tm-myapp \
  --resource-group rg-prod \
  --query id \
  --output tsv)

# Create an alias A record set pointing to Traffic Manager
az network dns record-set a create \
  --resource-group rg-dns \
  --zone-name mycompany.com \
  --name "app" \
  --target-resource $TM_ID

Alias records also solve the CNAME-at-apex problem. DNS specifications (RFC 1034) prohibit CNAME records at the zone apex (mycompany.com), but an alias record can point the apex to a Traffic Manager or Front Door hostname, effectively achieving the same result without violating the spec.

Tip

When using Azure Front Door or Traffic Manager for global load balancing, always use alias records for the DNS entries that point to them. The IPs behind these services can change without notice. Alias records ensure DNS stays current automatically.

Common mistakes

Delegating before adding records. If you update your registrar’s name servers before creating records in the Azure DNS zone, there is a window where DNS queries for your domain return NXDOMAIN. Users accessing your site during this window see failures. Always populate all critical records (A, MX, TXT, CNAME) in the Azure zone before changing the name servers at the registrar.
Using a CNAME at the root domain. A CNAME for mycompany.com (the apex) is prohibited by DNS specifications. Many resolvers will either refuse to load the zone or produce unpredictable behaviour. If you need the root domain to point to a Traffic Manager or Front Door hostname, use an alias record instead of a CNAME.
Setting TTL too high before a planned change. If your A record has a TTL of 86400 and you need to change the IP tomorrow, resolvers may cache the old IP for up to 24 hours after you make the change. Lower the TTL to 300 at least 24–48 hours before any planned change, switch the IP, confirm it resolves correctly, then raise the TTL back to its normal value.

Frequently asked questions

Does Azure DNS register domain names?

No. Azure DNS hosts DNS zones and serves authoritative DNS responses, but it does not register domain names. You register the domain with a registrar (GoDaddy, Namecheap, Google Domains, etc.) and then update the NS records at the registrar to point to Azure DNS name servers. After that, all queries for your domain are answered by Azure DNS.

What is an alias record in Azure DNS?

An alias record is a special Azure DNS record type that points to an Azure resource (Traffic Manager, Front Door, Application Gateway, or a public IP) instead of a static IP. When the resource's IP changes, the alias record updates automatically. Use alias records instead of A records whenever you are pointing a DNS record at an Azure resource that may change IP.

How long does DNS propagation take after changing name servers?

DNS propagation depends on the TTL of the existing NS records at the registrar and how long resolvers cache them. Most registrars set NS record TTLs between 24–48 hours. After you update the NS records, it may take up to 48 hours for all global resolvers to pick up the change. During this window, some clients will query the old name servers and some the new Azure DNS servers.

Last verified: 19 March 2026 Cloud services change frequently. Verify details against official documentation before making infrastructure decisions.