azureblog.co.uk
← cd ~/posts

Private endpoints and DNS: why your private endpoint isn't being used

You created a private endpoint, but traffic still goes to the public IP. It's almost always DNS. How private endpoint name resolution works and how to fix it.

2 min read✓ checked 19 Aug 2026Azure · Security
Part 5 of 5 in Azure landing zone guardrails
On this page
  1. How it should resolve
  2. Inside Azure
  3. From on-premises
  4. Troubleshooting

A gives a PaaS service, such as a storage account, SQL database or , a private IP address in your virtual network. Clients still connect using the normal public name, for example stdata.blob.core.windows.net. Whether they reach the private IP or the public one depends entirely on DNS.

On-prem clientOn-prem DNSPrivate ResolverPrivate DNS zonestdata.blob.core.windows.net?1Conditional forwarder:blob.core.windows.net2Public CNAME:stdata.privatelink.blob…Look up the privatelinkname4A record: 10.20.1.5510.20.1.5: traffic stays private6
Resolving a storage account with a private endpoint from on-premises.
  1. 01Client looks up stdata.blob.core.windows.net
  2. 02CNAME to privatelink name
  3. 03Private DNS zone answers 10.20.1.5
  4. 04Traffic stays on your network
If the lookup returns a public IP, DNS is the problem.

How it should resolve

When a private endpoint exists, the public name becomes a CNAME to a privatelink name:

text
stdata.blob.core.windows.net
  → stdata.privatelink.blob.core.windows.net
    → 10.20.1.5   (inside your network)
    → public IP   (everywhere else)

Your network needs to answer the privatelink name with the private IP. That's the job of a private DNS zone, such as privatelink.blob.core.windows.net.

Inside Azure

  • Create the private DNS zone. Usually the private endpoint wizard does this for you.
  • Link it to every virtual network that needs to resolve it. In hub-and-spoke, link it to the hub, and make sure spokes use DNS that can resolve through the hub.
  • Keep one zone per service type, shared across the estate, rather than a new zone per endpoint.

Common zone names

ServicePrivate DNS zone
Blob storageprivatelink.blob.core.windows.net
Azure Filesprivatelink.file.core.windows.net
Key Vaultprivatelink.vaultcore.azure.net
Azure SQL Databaseprivatelink.database.windows.net
App Service and Functionsprivatelink.azurewebsites.net

Each sub-resource gets its own zone. A storage account with blob and file endpoints needs records in two zones.

From on-premises

On-premises DNS servers can't query the Azure-provided resolver at 168.63.129.16 directly. That address only works from inside Azure. The usual fix:

  1. Deploy an Azure DNS Private Resolver with an inbound endpoint in the hub.
  2. On on-premises DNS, create conditional forwarders for the public service domains (such as blob.core.windows.net) pointing to the inbound endpoint's IP.

Troubleshooting

shell
nslookup stdata.blob.core.windows.net

Run it from the client that's failing. If you get a public IP back, DNS is the problem, not the private endpoint. Also check that the service's public network access setting matches your intent.

Scale tip: in a landing zone, use to create the DNS records in the central private DNS zones automatically whenever a private endpoint is deployed.
Resolve the public name from the client. What comes back?
A private IPDNS is right. Look at NSGs, routing or firewalls
A public IP via the privatelink CNAMEThe client's DNS can't see the private zone. Check forwarding and VNet links
A public IP with no privatelink CNAMENo private endpoint on that sub-resource, or the wrong name
NXDOMAINThe privatelink zone exists but has no record for this resource
What nslookup tells you.
powershell
# PowerShell equivalent, showing the CNAME chain
Resolve-DnsName stdata.blob.core.windows.net | Format-Table Name, Type, IPAddress, NameHost
  • Forward the public service domain, not the privatelink one, from on-premises
  • Avoid hosting privatelink zones on on-premises DNS: any account without a record there stops resolving
  • Custom DNS servers in Azure must forward to 168.63.129.16
  • Link private zones to the VNet your DNS servers or resolver live in
  • Use Azure Policy to create DNS records when private endpoints are created
You've reached the end of Azure landing zone guardrailsBack to the path →

Related posts