Private DNS Zones in Azure

What private DNS zones are

A Private DNS zone is a DNS zone that is only resolvable from VNets you explicitly link it to. The zone is hosted by Azure and managed through the Azure control plane, but unlike Azure DNS (public zones), it is completely invisible to the public internet.

You can name a private zone anything — internal.mycompany.com, prod.azure.local, or privatelink.blob.core.windows.net. The name does not need to be a registered public domain. VMs in linked VNets can query the zone through Azure-provided DNS at 168.63.129.16. No external configuration is needed — the link between the zone and the VNet is what activates resolution.

Creating a private DNS zone

Private DNS zones are global resources — they are not tied to a specific region. They live in a resource group, but the zone itself has no region requirement:

# Create a private DNS zone for internal services
az network private-dns zone create \
  --name internal.mycompany.com \
  --resource-group rg-dns

After creating the zone, it has no VNet links and resolves nothing. You must link it to at least one VNet for it to function.

Linking zones to VNets

A VNet link associates a private zone with a VNet. Once linked, VMs in that VNet can resolve records in the zone through Azure-provided DNS. Link with optional auto-registration enabled:

# Link the zone to the hub VNet (without auto-registration)
az network private-dns link vnet create \
  --name link-hub-vnet \
  --resource-group rg-dns \
  --zone-name internal.mycompany.com \
  --virtual-network vnet-hub-eastus \
  --registration-enabled false

# Link the zone to the spoke VNet (with auto-registration)
# VMs in this VNet will auto-register their names
az network private-dns link vnet create \
  --name link-spoke-app-vnet \
  --resource-group rg-dns \
  --zone-name internal.mycompany.com \
  --virtual-network vnet-spoke-app-eastus \
  --registration-enabled true

With auto-registration enabled, every VM in vnet-spoke-app-eastus automatically gets an A record in internal.mycompany.com when it is created, and the record is removed when the VM is deleted. Only one zone per VNet can have auto-registration enabled.

Adding records manually

Add A records for services that are not VMs (load balancers, internal APIs, private endpoints):

# Add an A record for an internal API service
az network private-dns record-set a add-record \
  --resource-group rg-dns \
  --zone-name internal.mycompany.com \
  --record-set-name "api" \
  --ipv4-address 10.0.2.50

# Add a CNAME alias
az network private-dns record-set cname set-record \
  --resource-group rg-dns \
  --zone-name internal.mycompany.com \
  --record-set-name "db" \
  --cname "sql-prod-001.database.windows.net"

# List all records in the zone
az network private-dns record-set list \
  --resource-group rg-dns \
  --zone-name internal.mycompany.com \
  --output table

Private Endpoints and the privatelink zones

When you create a Private Endpoint for an Azure service (Storage, SQL Database, Key Vault, etc.), that endpoint gets a private IP in your VNet. For name resolution to work correctly — so the service’s hostname resolves to the private IP rather than the public IP — you need a Private DNS zone with a specific name matching the service’s privatelink subdomain.

Practical example — Private Endpoint for a Storage Account:

# 1. Create the private endpoint for the storage account
STORAGE_ID=$(az storage account show \
  --name mystorageaccount \
  --resource-group rg-prod \
  --query id \
  --output tsv)

az network private-endpoint create \
  --name pe-mystorageaccount-blob \
  --resource-group rg-networking \
  --vnet-name vnet-spoke-app-eastus \
  --subnet snet-private-endpoints \
  --private-connection-resource-id $STORAGE_ID \
  --group-id blob \
  --connection-name conn-mystorageaccount-blob

# 2. Create the Private DNS zone
az network private-dns zone create \
  --name privatelink.blob.core.windows.net \
  --resource-group rg-dns

# 3. Link the zone to the VNet
az network private-dns link vnet create \
  --name link-spoke-app-to-blobdns \
  --resource-group rg-dns \
  --zone-name privatelink.blob.core.windows.net \
  --virtual-network vnet-spoke-app-eastus \
  --registration-enabled false

# 4. Get the private endpoint's network interface private IP
PE_NIC=$(az network private-endpoint show \
  --name pe-mystorageaccount-blob \
  --resource-group rg-networking \
  --query "networkInterfaces[0].id" \
  --output tsv)

PRIVATE_IP=$(az network nic show \
  --ids $PE_NIC \
  --query "ipConfigurations[0].privateIPAddress" \
  --output tsv)

# 5. Add the A record to the private DNS zone
az network private-dns record-set a add-record \
  --resource-group rg-dns \
  --zone-name privatelink.blob.core.windows.net \
  --record-set-name "mystorageaccount" \
  --ipv4-address $PRIVATE_IP

After these steps, queries for mystorageaccount.blob.core.windows.net from within the linked VNet resolve to the private endpoint IP (10.x.x.x) instead of the public IP.

Multiple VNet linking and DNS resolution flow

One private DNS zone can serve multiple VNets by adding additional VNet links. This is the pattern for hub-and-spoke architectures: create the zone once, link it to the hub VNet and all spoke VNets.

DNS resolution flow for a VM in a spoke VNet querying a private endpoint hostname:

1. VM queries Azure-provided DNS at 168.63.129.16.

2. Azure-provided DNS checks for private DNS zones linked to the VM’s VNet.

3. It finds a zone link for privatelink.blob.core.windows.net.

4. It queries that zone and finds an A record for mystorageaccount pointing to 10.0.5.4.

5. The VM receives 10.0.5.4 and connects directly to the private endpoint.

Split-brain DNS with private zones

Split-brain (or split-horizon) DNS returns different answers for the same hostname depending on where the query originates. Create a private zone with the same name as a public zone to achieve this.

Example: api.mycompany.com should resolve to a private IP for VMs inside Azure but to a public IP for external users. Create a private zone named api.mycompany.com, add an A record pointing to the private IP, and link it to the application VNets. The public Azure DNS zone for api.mycompany.com continues to serve the public IP. Internal queries find the private zone link and get the private IP. External queries never see the private zone and get the public IP from Azure DNS.