Azure DNS: Fix Setup, Config & Resolution Errors
Why Azure DNS Issues Keep Biting People
I've seen this pattern dozens of times. Someone spins up an Azure DNS zone, adds a record, waits an hour , and the domain still doesn't resolve. Or they set up a private DNS zone for their virtual network and suddenly internal services can't find each other. Maybe you just deleted a record by accident and now a production service is dark. Whatever brought you here, I know it's stressful.
Azure DNS is genuinely powerful. It's Microsoft's globally distributed, authoritative DNS hosting service , backed by the same infrastructure that handles billions of queries a day. When it works, it's invisible. When it doesn't, the failure messages are maddeningly vague. You'll see generic resolution timeouts in your browser, or a SERVFAIL in your dig output, with zero indication of whether the problem is in your zone configuration, your registrar's nameserver delegation, or something deeper in your Azure subscription.
The root causes I see most often fall into three buckets:
- Delegation not updated at the registrar. You created an Azure DNS zone, but never went back to GoDaddy (or Namecheap, or wherever) to swap out the nameservers. Azure gives you four nameservers when you create a zone, those have to be entered at your registrar. If they aren't, Azure DNS never gets a chance to answer queries.
- Wrong record type or TTL confusion. Creating an A record when you needed a CNAME, or setting a TTL of 3600 and then immediately changing it, your old record is cached at resolvers all over the internet and you're staring at stale data.
- Private DNS zones not linked to a virtual network. Azure private DNS domains require an explicit virtual network link. If you skipped that step, machines inside the VNet are still using Azure's default names, not yours.
There's also the alias record confusion. Azure DNS alias record sets are one of those features that look simple on paper but trip people up because they work differently from standard DNS CNAME records. And with DNSSEC now supported on Azure Public DNS, misconfigured signing can cause validation failures in DNSSEC-aware resolvers, which look identical to ordinary resolution failures from the user's side.
The good news: almost every Azure DNS problem has a clean, documented fix. Let's work through them. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you spend an hour digging through zone files and network traces, run this check. It catches the majority of Azure DNS not resolving problems in under five minutes.
Step 1, Verify your Azure DNS nameservers are actually delegated at your registrar.
Go to the Azure portal and open your DNS zone. Right at the top of the zone overview page, under Name server 1 through Name server 4, you'll see four entries that look something like:
ns1-04.azure-dns.com
ns2-04.azure-dns.net
ns3-04.azure-dns.org
ns4-04.azure-dns.info
Now open a new tab and go to your domain registrar's control panel. Find the nameserver settings for your domain, usually under "DNS Management" or "Domain Settings." Compare the nameservers listed there with the ones Azure gave you. They need to match exactly. One mismatched character means Azure DNS never sees a single query for your domain.
Step 2, Run a quick delegation check from your terminal.
nslookup -type=NS yourdomain.com 8.8.8.8
Replace yourdomain.com with your actual domain. If the NS records returned point to Azure DNS nameservers, delegation is working. If they point somewhere else, like your registrar's default nameservers, that's your problem.
On Windows PowerShell, you can also use:
Resolve-DnsName -Name yourdomain.com -Type NS -Server 8.8.8.8
If delegation looks right but resolution still fails, move on to the step-by-step section below.
A lot of the pain people experience with Azure DNS starts at zone creation, specifically, naming it wrong or putting it in the wrong resource group. Let me walk you through doing this the right way in the Azure portal.
Sign in to the Azure portal. In the search bar at the top, type DNS zones and select it from the results. Click + Create in the top-left corner.
On the Create DNS zone page, fill in:
- Subscription, make sure you're in the right subscription. I've seen people create zones in a dev subscription and then wonder why production can't see them.
- Resource group, either select an existing one or click Create new and give it a name like
dns-prod-rg. The resource group name has to be unique within your subscription. - Name, this must be your actual domain name, like
contoso.comormyapp.io. Don't addwwwhere. Don't add a trailing dot. Just the bare domain.
Click Review + create, verify everything, then Create. Deployment takes under 30 seconds.
After creation, open the zone. You'll see the four Azure nameservers assigned to it in the right-hand panel. Copy all four of them, you'll need these for the next step with your registrar. If you skip this, nothing else in this guide will matter, because the internet won't know to ask Azure about your domain.
You should see your new zone appear in the DNS zones list with zero record sets (aside from the SOA and NS records Azure auto-creates). If the zone doesn't appear within a minute, refresh the list or check whether your account has Contributor or DNS Zone Contributor role on the resource group.
Once your zone exists, you need to populate it with records. This is where most configuration errors happen. Open your DNS zone in the Azure portal and click + Record set in the toolbar.
For a basic web server pointing www.yourdomain.com to an IP address:
- Name:
www - Type: A
- TTL: 3600 (or 300 during testing)
- IP address: your server's public IP
For pointing the root/apex domain (sometimes called a "naked domain"), like yourdomain.com with no www, use @ as the name. This creates a record at the zone apex.
To verify a domain for Microsoft 365 or Google Workspace, you'll need a TXT record. Set the name to @, type to TXT, and paste the verification string in the value field.
For MX records (email routing), the value format matters: you must specify priority before the mail server hostname, like 10 mail.yourdomain.com. Azure's portal handles this with separate Priority and Mail Exchange fields, fill both.
Using PowerShell to add a record programmatically:
$zone = Get-AzDnsZone -Name "yourdomain.com" -ResourceGroupName "dns-prod-rg"
New-AzDnsRecordSet -Name "www" -RecordType A -ZoneName "yourdomain.com" `
-ResourceGroupName "dns-prod-rg" -Ttl 3600 `
-DnsRecords (New-AzDnsRecordConfig -IPv4Address "203.0.113.10")
After saving, wait for your TTL window to pass, then test with nslookup www.yourdomain.com. You should get back your IP address. If you get Non-existent domain, double-check that the name and type match what you intended.
If you're pointing DNS at an Azure resource, a public IP address, a Traffic Manager profile, or a CDN endpoint, stop right there before you create a regular A or CNAME record. You want an alias record set instead, and here's why.
Standard DNS records store a hard-coded IP. If your Azure Public IP address ever changes (during a redeployment, a scale event, or a service migration), your DNS record becomes stale and traffic stops routing correctly. Azure DNS alias records solve this by pointing directly at the Azure resource itself, not at its IP. When the IP changes, the alias record automatically picks up the new value during DNS resolution, no manual intervention needed.
To create an alias record in the Azure portal, click + Record set in your DNS zone. Set the type to A (or AAAA for IPv6). You'll see an Alias record set toggle, switch it to Yes. A dropdown appears letting you select the Azure resource to point at: an Azure public IP address resource, a Traffic Manager profile, or a CDN endpoint.
There's one important constraint: you can only use an alias record at the zone apex (using @ as the name) to point to Traffic Manager or CDN. This is huge for "naked domain" setups, standard DNS doesn't allow CNAMEs at the apex, but Azure DNS alias records work around this limitation cleanly. So contoso.com (not just www.contoso.com) can point to a Traffic Manager profile.
PowerShell equivalent for creating an alias record targeting a Traffic Manager profile:
$tm = Get-AzTrafficManagerProfile -Name "myTMProfile" -ResourceGroupName "app-rg"
New-AzDnsRecordSet -Name "@" -RecordType A -ZoneName "yourdomain.com" `
-ResourceGroupName "dns-prod-rg" -Ttl 300 -TargetResourceId $tm.Id
After creation, the record set in the portal will show "Alias" in the record list. Test it: Resolve-DnsName yourdomain.com -Type A should return the current IP of your Traffic Manager endpoint.
This one trips up almost every team that's building a microservices architecture in Azure. By default, resources inside an Azure virtual network get names like myvm.internal.cloudapp.azure.com, not exactly memorable or manageable. Azure private DNS domains let you replace those with names you control, like myvm.corp.internal.
Here's the critical thing people miss: a private DNS zone does nothing until you link it to a virtual network. The zone and the VNet are separate resources, and the connection between them is a virtual network link. Without it, machines in the VNet keep using Azure's default DNS resolution and your private zone is completely ignored.
To set this up:
- In the Azure portal, search for Private DNS zones and click + Create.
- Select your subscription and resource group. For the name, use an internal-only domain like
corp.internalormyapp.private. Do not use a public TLD you own, use something clearly internal. - After the zone is created, open it and click Virtual network links in the left menu.
- Click + Add and select the virtual network where your resources live. Enable Auto registration if you want Azure to automatically create DNS records for VMs as they're provisioned in that VNet.
With auto registration on, every VM you spin up in that VNet gets a DNS record in your private zone automatically, based on its hostname. Without it, you manage records manually.
Test the link by logging into a VM inside the VNet and running:
nslookup myvm.corp.internal
If it resolves, you're done. If it returns NXDOMAIN, the most common cause is that the VNet link wasn't saved correctly, go back to the Virtual network links blade and confirm the link shows a status of Completed, not Pending.
Azure Public DNS now supports DNSSEC, which adds cryptographic signing to your DNS responses. If your domain name registrar or downstream resolvers are DNSSEC-aware, this protects against DNS spoofing and cache poisoning attacks. But misconfiguring DNSSEC is one of the fastest ways to make your domain completely unresolvable for a subset of users, specifically those whose ISP or corporate resolver does DNSSEC validation.
Before enabling DNSSEC, make sure your domain registrar supports DS (Delegation Signer) records. Most major registrars do, but some smaller ones don't. If yours doesn't, enabling DNSSEC signing on the Azure side without publishing the DS record at the registrar will cause DNSSEC validation failures, your domain will resolve fine for non-validating resolvers but fail for validating ones.
To enable DNSSEC on your zone via Azure CLI:
az dns dnssec-config create --resource-group dns-prod-rg --zone-name yourdomain.com
After running this, Azure generates a Key Signing Key (KSK) and Zone Signing Key (ZSK). Get the DS record details:
az dns dnssec-config show --resource-group dns-prod-rg --zone-name yourdomain.com
Copy the DS record output and paste it into your registrar's DS record configuration. The exact field names vary by registrar, but you'll need the Key Tag, Algorithm, Digest Type, and Digest values.
After publishing the DS record, test DNSSEC validation:
Resolve-DnsName yourdomain.com -DnssecOk -Server 8.8.8.8
On Linux: dig +dnssec yourdomain.com @8.8.8.8
Look for the ad flag in the response header, that means "authenticated data" and confirms DNSSEC is working end to end. If you see SERVFAIL instead, the DS record at your registrar doesn't match what Azure signed. Remove the DS record at the registrar, wait for TTL to expire, then re-enter it carefully.
Advanced Troubleshooting for Azure DNS
Diagnosing Azure DNS resolution failures with dig and nslookup
When standard resolution isn't working and you've checked delegation, go direct. Query Azure's nameservers directly to rule out a propagation delay at public resolvers:
nslookup www.yourdomain.com ns1-04.azure-dns.com
If this returns the correct record, Azure DNS has the right data and the problem is a caching or propagation issue at intermediate resolvers. Wait for your TTL to expire. If this also fails, the record either doesn't exist in the zone or has a typo in the name.
Azure DNS billing and zone count limits
Azure DNS billing is based on two things: the number of DNS zones hosted in Azure, and the number of DNS queries received. Each zone counts toward your bill from the moment it exists, even if it has no traffic. If you're running automated systems that create DNS zones programmatically, make sure you're cleaning up test zones, orphaned zones silently accumulate costs. Check Azure DNS pricing in the Azure portal cost management section to spot unexpected zone counts.
Automating DNS management with the Azure DNS REST API and SDKs
If you're managing DNS records as part of a CI/CD pipeline, for example, creating a per-environment subdomain on every deployment, the Azure DNS REST API is the right tool. The API supports full CRUD on zones and record sets. Authenticate with a service principal that has DNS Zone Contributor role (not full Contributor, least privilege applies).
Example: create a record set via the REST API with az rest:
az rest --method PUT \
--uri "https://management.azure.com/subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.Network/dnsZones/{zone}/A/{name}?api-version=2018-05-01" \
--body '{"properties":{"TTL":300,"ARecords":[{"ipv4Address":"203.0.113.10"}]}}'
Enterprise scenarios: DNS resolution for hybrid networks
In environments where on-premises networks connect to Azure via ExpressRoute or VPN, DNS resolution gets complicated. On-premises resolvers don't inherently know about Azure private DNS zones. The solution Microsoft recommends is setting up Azure DNS Private Resolver, a dedicated inbound/outbound endpoint that lets your on-premises DNS infrastructure forward queries into Azure's private DNS system without going through a VM-based forwarder. If you're seeing internal Azure hostnames fail to resolve from on-premises, this is almost always the missing piece.
For event-level diagnostics, Azure Monitor logs can capture DNS query logs if you route them through Azure Diagnostic Settings. Set up a diagnostic setting on the DNS zone resource to send query logs to a Log Analytics workspace, then query them:
AzureDiagnostics
| where ResourceType == "DNSZONES"
| where OperationName == "Query DNS"
| where ResultSignature == "NXDOMAIN"
| project TimeGenerated, QueryName, ClientIp
dig +dnssec yourdomain.com @8.8.8.8 to speed up triage.
Prevention & Best Practices for Azure DNS
The teams that never have DNS emergencies aren't lucky, they've built habits that catch problems before they become outages. Here's what that looks like in practice.
Use Infrastructure as Code for DNS zones and records. Managing Azure DNS through the portal by hand is fine for one-off setups, but in production it's a recipe for configuration drift. Use Terraform or Bicep to define your zones and record sets. When DNS configuration lives in source control, you have an audit trail, you can review changes before they're applied, and rollback is a git revert away. The azurerm_dns_zone and azurerm_dns_a_record Terraform resources map directly to Azure DNS concepts.
Set low TTLs before planned changes, raise them after. This is the single most actionable thing you can do before any DNS migration or record change. Drop your TTL to 60–300 seconds 24 hours before a planned change. The change propagates fast. Once you've confirmed the new record is working, raise the TTL back to 3600 or higher for normal operation.
Tag your DNS zones with environment and owner metadata. Azure resource tagging applies to DNS zones just like any other resource. Tag each zone with environment: production, owner: platform-team@company.com, and cost-center: xyz. This makes it obvious at a glance which zones are safe to delete and which ones would take down production if touched.
Set up Azure Monitor alerts on DNS query volume. A sudden drop to zero queries on a public-facing zone often means delegation broke. An unexpected spike might indicate a DDoS amplification attempt. Both are worth alerting on. Route DNS diagnostic logs to Log Analytics and create alert rules against query patterns.
Test DNSSEC with an online validator before going live. If you're enabling DNSSEC, test the full chain of trust before announcing it. Tools like DNSViz (available via web search) show you exactly where the DNSSEC chain breaks so you can fix it before it affects users.
- Always copy all four Azure nameservers to your registrar, not just one or two. All four need to be present for proper anycast routing.
- Use alias record sets for any Azure resource with a dynamic IP, public IPs, Traffic Manager, CDN endpoints, instead of hard-coded A records.
- Enable virtual network auto-registration when linking private DNS zones to VNets, it eliminates manual record management for VMs.
- Audit orphaned DNS zones monthly using Azure Resource Graph or the CLI:
az network dns zone list --output table, unused zones still cost money.
Frequently Asked Questions
How long does Azure DNS propagation take after I add or change a record?
Azure DNS changes are typically visible to global resolvers within a few minutes, the Azure nameservers themselves pick up changes almost instantly. What takes longer is the TTL-based cache expiry at intermediate resolvers. If your previous record had a TTL of 3600, resolvers that cached it won't check for updates for up to an hour. To test whether Azure has your new record, query the Azure nameserver directly: nslookup yourrecord.yourdomain.com ns1-04.azure-dns.com. If that returns the right value, Azure is correct and you're waiting on cache expiry.
Why can't I create a CNAME record at my zone root (naked domain)?
This is a DNS protocol restriction that has nothing to do with Azure specifically, the DNS standard (RFC 1034) prohibits CNAME records at the zone apex because the apex must always have SOA and NS records, and CNAMEs can't coexist with other record types. If you need to point your root domain (yourdomain.com with no subdomain) to an Azure service like Traffic Manager or a CDN endpoint, use an Azure DNS alias record set instead. Set the record name to @, toggle the alias option on, and select the Azure resource. This is specifically what alias records were designed for, and it sidesteps the CNAME-at-apex limitation cleanly.
How do I point my domain from GoDaddy (or another registrar) to Azure DNS?
After creating your Azure DNS zone, note the four nameservers shown on the zone overview page in the Azure portal (they'll look like ns1-xx.azure-dns.com, ns2-xx.azure-dns.net, etc.). Log into your registrar account, navigate to the DNS or nameserver settings for your domain, and replace whatever nameservers are currently listed with all four Azure nameservers. Save the change. Registrar propagation can take 24–48 hours, though most major registrars process it within an hour. You can monitor progress with nslookup -type=NS yourdomain.com 8.8.8.8, once it returns Azure nameservers, delegation is live.
My Azure private DNS zone isn't resolving inside my virtual network, what's wrong?
Nine times out of ten, the virtual network link is missing or in a failed state. Open your private DNS zone in the Azure portal, click Virtual network links in the left sidebar, and check whether your VNet appears in the list with a status of Completed. If the link isn't there, click + Add and create it. If it's in a Failed state, delete it and recreate it. Also confirm that your VMs are actually using Azure's default DNS resolver (168.63.129.16), if someone configured a custom DNS server on the VNet or NIC level, it may not be forwarding queries to Azure's resolver, which is what answers private DNS zone queries.
Does Azure DNS support wildcard records like *.mydomain.com?
Yes, Azure DNS supports wildcard record sets. To create one, use * as the record name in the portal or in your PowerShell/CLI command. A wildcard A record at *.yourdomain.com will match any subdomain query that doesn't have a more specific record, so anything.yourdomain.com would resolve to whatever IP you specify. One important caveat: Azure DNS alias record sets cannot be wildcard records. Wildcard support works for standard A, AAAA, CNAME, MX, and TXT records.
How much does Azure DNS cost and how can I reduce my bill?
Azure DNS billing has two components: a per-zone monthly charge for each DNS zone hosted in Azure, plus a per-query charge based on the number of DNS queries your zones receive. The first five million queries per month are billed at one rate, with a reduced rate above that threshold, check the current Azure DNS pricing page for exact figures since rates can update. To keep costs down: delete unused test zones promptly (they accrue the per-zone charge even with zero traffic), consolidate small zones where possible, and use Azure Cost Management's resource filtering to specifically monitor DNS zone spend. If you have a large number of queries, consider whether caching settings or longer TTLs could reduce query volume.