Azure DNS
Azure DNS hosts your domains on Azure's global anycast name-server network, resolving public DNS queries with high availability and low latency. You manage records through the same control plane as everything else in Azure, with RBAC and activity logging, rather than at a separate registrar's portal.
Beyond public zones, private DNS zones resolve names inside your VNets — so resources reach each other and your PaaS private endpoints by name rather than by IP. Getting private DNS wrong is the quiet cause of private endpoints that resolve to public IPs and defeat their own purpose.
Public Zones
A public DNS zone hosts the records for a domain — A, AAAA, CNAME, MX, TXT, and the rest — served from Azure's anycast network. Azure DNS hosts the zone; domain registration still happens at a registrar, and you delegate the domain to Azure's name servers to make the zone authoritative.
Private DNS Zones
A private DNS zone resolves names only within the VNets linked to it, giving internal resources stable names and underpinning private-endpoint resolution. When you create a private endpoint, the matching private DNS zone is what makes the service's public hostname resolve to the private IP inside your network — without it, clients resolve the public IP and the private endpoint does nothing.
Alias Records
Alias records point a zone record at an Azure resource — a public IP, a Front Door or Traffic Manager profile — and track that resource's address automatically. Unlike a CNAME, an alias can sit at the zone apex (the naked domain), and it updates when the underlying resource's IP changes, avoiding dangling records.
Delegation
Making Azure DNS authoritative for a domain means updating the registrar to point at the four Azure name servers assigned to the zone. Until that delegation is in place, the zone exists but the internet does not consult it. Subdomains can be delegated independently, which is how teams divide DNS ownership.
- Creating private endpoints without the matching private DNS zone, so clients resolve the public IP and the private endpoint is bypassed entirely.
- Forgetting to delegate the domain at the registrar, leaving an authoritative-looking zone the internet never queries.
- Using a CNAME at the zone apex (which DNS forbids) instead of an alias record.
- Leaving dangling records that point at deallocated resources — an alias record would have tracked the change.
- Managing DNS at a separate registrar portal, losing the RBAC and audit logging Azure DNS provides.
- Not linking the private DNS zone to every VNet that needs to resolve the names, so resolution works in one network and fails in another.
- Pair every private endpoint with the correct private DNS zone, and link that zone to all VNets that must resolve it.
- Delegate the domain to Azure's assigned name servers so the zone becomes authoritative.
- Use alias records for zone-apex entries and for pointing at Azure resources whose IPs can change.
- Manage DNS through Azure for RBAC and activity logging rather than a separate registrar portal.
- Audit for dangling records pointing at deallocated resources.
- Delegate subdomains to divide DNS ownership cleanly between teams.
Knowledge Check
A private endpoint was created, but clients still connect over the public internet. What is the most likely cause?
- The matching private DNS zone is missing or unlinked, so the hostname resolves to the public IP
- The private endpoint needs a public IP address attached to its underlying network interface card
- Azure DNS does not support private endpoint resolution at all
- The domain was delegated to the wrong external registrar
Why use an alias record instead of a CNAME for the naked (apex) domain?
- DNS forbids a CNAME at the zone apex, and an alias also tracks the target resource's IP automatically
- Alias records resolve measurably faster than ordinary CNAMEs
- CNAMEs are unable to point at any Azure resource hostname
- Alias records are entirely free of charge, while every single CNAME query is billed individually per lookup
What makes an Azure DNS public zone authoritative for a domain?
- Delegating the domain at the registrar to the Azure name servers assigned to the zone
- Creating the zone resource in the Azure portal, which is sufficient entirely by itself on its own
- Linking the zone to a virtual network for resolution
- Adding an alias record at the zone apex domain
You got correct