Private endpoint DNS zones

Every private endpoint needs the right privatelink.* private DNS zone, or clients keep resolving the public IP and traffic never enters the endpoint. This page is the printable version of the Private Endpoint DNS Zones tool, which deduplicates zones across a selection and generates the az cli commands for you.

How the redirection works

The service's public DNS name gains a CNAME into the matching privatelink.* name once a private endpoint exists. Public resolvers follow the chain back out to a public A record; resolvers that can see the private zone answer with the endpoint's private IP:

myvault.vault.azure.net
  → CNAME myvault.privatelink.vaultcore.azure.net
    → private zone linked to your VNet?  A 10.x.x.x   (private endpoint)
    → otherwise                          A <public IP> (or refusal, if public access is off)

Two consequences worth memorising: the zone must be linked to every VNet whose resolvers should see it (or reachable via your central DNS), and on-prem clients must forward the public zone (e.g. vault.azure.net) to a resolver inside Azure — you cannot forward privatelink.* directly, because on-prem clients never see that name until the CNAME redirects them.

Zones by service

Storage

Databases

Security

Compute & containers

Notes: replace {region} with the resource's region (e.g. privatelink.westeurope.azmk8s.io). Container Registry data-endpoint records (<registry>.<region>.data) live in the same zone. App Service also needs the <app>.scm record for Kudu/deployments — same zone.

Integration & messaging

Management & monitoring

{geo} is the vault's geo code, e.g. weu for West Europe. An Azure Monitor Private Link Scope needs all five zones — a partial set produces maddening partially-working telemetry.

AI & analytics

Setup commands

# Create a zone (once per DNS environment, not per endpoint)
az network private-dns zone create -g <rg> -n "privatelink.blob.core.windows.net"

# Link it to a VNet (once per VNet that must resolve it)
az network private-dns link vnet create -g <rg> -z "privatelink.blob.core.windows.net" \
  -n <link-name> --virtual-network <vnet-id> --registration-enabled false

# Attach the zone to a private endpoint (creates/maintains the A record)
az network private-endpoint dns-zone-group create -g <rg> \
  --endpoint-name <pe-name> -n default \
  --private-dns-zone <zone-id> --zone-name <any-label>

Gotchas

• One zone per DNS environment, not per endpoint. Duplicate privatelink.* zones in every spoke is the classic anti-pattern — records fragment and resolution depends on which VNet asks. Centralize (hub or dedicated DNS subscription) and link outward.
• Zone linked but not to the right VNet — resolution comes from whatever the client's DNS server's VNet sees, not the client's own VNet. With custom DNS servers or a Private Resolver, the zone must be linked to that VNet.
• Don't create records by hand. Use the endpoint's DNS zone group so the A record is created, updated and deleted with the endpoint.
• Verify from both sides: inside Azure nslookup myvault.vault.azure.net should return 10.x.x.x; from the internet it should not. Check the outside view with the DNS Record Lookup and decode any confusing resolver output with the dig & nslookup Output Explainer.
• Services with unstable or partitioned zone schemes are omitted here — verify anything exotic against Microsoft Learn's private endpoint DNS zone table.