8.1 Azure DNS, Private DNS, and Name Resolution

Name resolution choices in Azure

Name resolution turns service names into IP addresses, and in Azure it often decides whether traffic uses a public path or a private path. Azure DNS is the managed public authoritative DNS service for zones such as contoso.com. Azure Private DNS is the managed private authoritative service for zones such as privatelink.blob.core.windows.net, corp.internal, or database.contoso.local when those names should resolve inside selected virtual networks.

Azure also provides default name resolution for resources inside a VNet. A VM can usually resolve the names of other VMs in the same VNet without you creating a DNS zone. That default capability is useful, but it is not a full enterprise DNS design. It does not replace a custom DNS server when you need conditional forwarding, on-premises name resolution, cross-environment naming standards, or domain controller integration.

Portal paths are exam-relevant. Use Azure portal > DNS zones for public zones. Use Azure portal > Private DNS zones for private zones. Inside a private zone, use Virtual network links to attach VNets and Recordsets to manage names. For private endpoints, check the DNS configuration blade of the endpoint and the related private DNS zone group.

Public Azure DNS

Azure DNS public zones are authoritative for internet-facing records. You create records such as A, AAAA, CNAME, MX, TXT, and SOA/NS records in the zone. Azure DNS does not buy the domain for you. You still register the domain with a registrar, then delegate the domain to the Azure DNS name servers shown on the zone.

A common web app pattern is to create a CNAME from www.contoso.com to an Azure-provided endpoint, then add the custom domain to the service. For apex domains such as contoso.com, you may need an A record or alias record depending on the target. In AZ-104, avoid assuming DNS alone completes the application mapping. Many services also require the custom domain to be verified or bound at the service.

Useful commands:

az network dns zone create -g rg-network -n contoso.com
az network dns record-set a add-record -g rg-network -z contoso.com -n app -a 20.30.40.50
az network dns record-set cname set-record -g rg-network -z contoso.com -n www -c app.contoso.com

Azure Private DNS

Azure Private DNS zones answer queries only for networks connected through VNet links or through a DNS forwarding design. A private DNS record can point sql01.corp.internal to 10.20.1.4, but a VM in another VNet will not resolve it unless that VNet is linked or a resolver forwards queries correctly.

Private DNS zone links have a registration option. Enable auto-registration when Azure should automatically create and maintain records for VMs in the linked VNet. Use it carefully. You can have many resolution links, but registration is a design choice because it controls which VNet can automatically write VM records into the zone.

az network private-dns zone create -g rg-network -n corp.internal
az network private-dns link vnet create \
  -g rg-network \
  -z corp.internal \
  -n link-spoke1 \
  -v /subscriptions/<sub-id>/resourceGroups/rg-network/providers/Microsoft.Network/virtualNetworks/vnet-spoke1 \
  -e false
az network private-dns record-set a add-record -g rg-network -z corp.internal -n app01 -a 10.10.2.15

Private endpoints and DNS

Private endpoints are a frequent source of DNS questions. The service FQDN may stay the same, but from the private network it should resolve to the private endpoint IP. For example, a storage account blob endpoint that normally resolves publicly may need to resolve through a privatelink.blob.core.windows.net private DNS zone. If DNS still returns a public IP, traffic may leave the private path and then fail because public network access is disabled or the service firewall blocks the request.

Troubleshooting tree for private endpoint name resolution:

Client cannot reach private endpoint service by FQDN
|-- Does nslookup return a private IP from the client subnet?
|   |-- No: check private DNS zone, A record, zone group, and VNet link.
|   |-- Yes: continue.
|-- Does the route to the private IP stay inside the VNet or peering path?
|   |-- No: inspect UDRs, peering, gateway transit, and next hop.
|   |-- Yes: continue.
|-- Do NSGs, service firewall rules, or endpoint policies block traffic?
|   |-- Yes: correct the blocking rule or service setting.
|   |-- No: inspect application port, TLS name, and service health.

Hybrid DNS considerations

Hybrid designs need a resolver path in both directions. Azure VMs may need to resolve on-premises domain names, and on-premises clients may need to resolve Azure private names. A common pattern is to configure VNet DNS servers to point to domain controllers or DNS forwarders, then configure conditional forwarders for Azure private zones. Another pattern uses Azure DNS Private Resolver to provide inbound and outbound endpoints with rulesets.

When VNet DNS server settings are changed, VMs may need a restart or DHCP lease renewal to pick up the new resolver. Linux and Windows clients may also cache results. Always test from the affected client, not only from your workstation.

Practical commands:

nslookup app01.corp.internal
nslookup mystorage.blob.core.windows.net
az network vnet show -g rg-network -n vnet-spoke1 --query dhcpOptions.dnsServers
ipconfig /displaydns
ipconfig /flushdns

Exam diagnostics

If a question says an IP address works but the FQDN fails, suspect DNS first. If DNS returns the expected IP but the connection fails, move to NSGs, routes, service firewall, load balancer probes, or the application listener. If one VNet resolves a private name and another does not, check the private DNS VNet links before rebuilding the endpoint.

Do not use public Azure DNS for private-only records that must not resolve publicly. Do not expect a private DNS zone to be globally available without links or forwarding. Do not assume VNet peering automatically links private DNS zones; peering provides network reachability, not DNS zone membership.