🔌 Azure Private Link and Private Endpoints With AI: It's Always DNS

The ticket read “private endpoint not working.” The endpoint was Approved. The connection state was Connected. The NIC had a private IP in the right subnet. By every status indicator Azure showed me, Private Link was working — and yet the application was still reaching the storage account over the public internet, which I confirmed by watching the public endpoint’s metrics tick up. The endpoint was fine. The DNS was wrong. That sentence describes the overwhelming majority of Private Link tickets, and once you internalize it, debugging gets dramatically faster.

Private Endpoints fail in a uniquely deceptive way because the network plumbing and the name resolution are separate concerns that both have to be right. You can provision a perfect endpoint and still resolve the PaaS FQDN to its public address, because nobody linked the Private DNS zone to the VNet the client lives in. AI is helpful here precisely because it refuses to be fooled by the green status indicators — it asks the one question that matters first: what does the client actually resolve the FQDN to?

Start with what the client resolves, not the endpoint

The endpoint’s status tells you almost nothing about whether traffic is private. The DNS resolution from inside the VNet tells you everything. So the first command is always a lookup from a representative client, not an inspection of the endpoint.

Prompt: “My Private Endpoint for a storage account (blob) shows Approved and Connected, but the app still reaches the public endpoint. Before I touch anything, give me the read-only checks to confirm whether clients in the VNet resolve mystorage.blob.core.windows.net to the private endpoint IP or the public one, and how to read the result.”

The check itself is simple, and the answer it gives is decisive:

# From a VM inside the client VNet
nslookup mystorage.blob.core.windows.net
# Private = resolves to a 10.x / private IP via privatelink CNAME
# Broken  = resolves to a public Microsoft IP

If that resolves to a public IP, you have your diagnosis and you can stop looking at the endpoint entirely. The problem is the Private DNS zone, and everything downstream — the zone name, the A record, the VNet link, the conditional forwarder — is now in scope.

The zone name has to match the sub-resource exactly

Every Azure PaaS service uses a specific privatelink zone, and the names are easy to get subtly wrong. Blob storage is privatelink.blob.core.windows.net. Key Vault is privatelink.vaultcore.azure.net. Azure SQL is privatelink.database.windows.net. Use the wrong zone, or put the A record in the right zone but forget to link it to the client’s VNet, and you get the exact silent-public-fallback symptom.

Prompt: “I’m privatizing a Key Vault with a Private Endpoint. Tell me the exact Private DNS zone name I need, confirm what the A record should point to, and which VNet(s) the zone must be linked to given my clients live in a spoke VNet that peers to a hub. List the read-only checks to verify each piece.”

AI is reliable at recalling the zone-name-to-sub-resource mapping, which is otherwise a documentation lookup every time. Verify the pieces it lists against your environment:

# Does the zone exist, and is it linked to the client's VNet?
az network private-dns zone show -g rg-dns -n privatelink.vaultcore.azure.net -o table
az network private-dns link vnet list -g rg-dns -z privatelink.vaultcore.azure.net -o table

# Does the A record point at the endpoint NIC IP?
az network private-dns record-set a list -g rg-dns -z privatelink.vaultcore.azure.net -o table

Hub-and-spoke topologies are where this goes wrong most often: the zone is linked to the hub VNet but the clients live in a spoke, so they never see the private record. The same careful, verify-each-hop approach runs through all the Azure networking and security work.

On-prem and custom DNS need a forwarder, not a host file

When clients resolve through custom DNS servers or from on-premises, the privatelink CNAME chain only resolves correctly if those resolvers forward to Azure-provided DNS (168.63.129.16) or an Azure DNS Private Resolver. Without that forwarder, on-prem clients chase the CNAME to the public endpoint. The fix is a conditional forwarder, not a static host-file entry that rots the moment the IP changes.

Prompt: “Our on-prem servers use corporate DNS and need to reach an Azure SQL database over its Private Endpoint. Explain how the privatelink CNAME resolves, what conditional forwarder I need so on-prem resolution returns the private IP, and why a static hosts entry is the wrong fix.”

Let AI explain the resolution chain — it’s genuinely confusing the first few times — and then implement the forwarder yourself against your DNS infrastructure. The companion review prompt that walks this whole checklist is in the prompts library.

Only lock the public door once private resolution works

Here is the move that turns a debugging session into an outage: disabling public network access on the PaaS resource before private resolution is confirmed. It feels like the responsible first step — lock it down — but if DNS still resolves to the public endpoint, you’ve just cut off every client at once, including the CI/CD and management tooling you need to fix it.

# Do this LAST, after nslookup confirms private resolution end to end
az storage account update -n mystorage -g rg-data --public-network-access Disabled

Prompt: “I’ve confirmed clients resolve the storage FQDN to the private endpoint IP and can read/write. Before I disable public network access, list everything that could still depend on public access — CI/CD, management tooling, other regions — so I don’t lock myself out, and give me a break-glass plan.”

The ordering is the whole discipline: provision the endpoint, fix the Private DNS zone and links, verify resolution from a real client, confirm connectivity, then disable public access. AI can sequence this and recall the zone names; you run the lookups and own the lockdown step. Get the order right and Private Link stops being a mystery and becomes a reliable boundary. There’s more in the Azure category, and the Private Endpoint review prompt is ready to copy from the prompts library.