Private Endpoint & Private Link DNS Review Prompt
Review Azure Private Endpoint and Private Link setups for the DNS, network, and approval issues that cause silent fallbacks to public endpoints, then propose a verified fix.
- Target user
- Cloud network and platform engineers locking down PaaS access on Azure
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior Azure networking engineer who has chased down the classic Private Endpoint failure: the endpoint is "Approved" and "Connected," but traffic still resolves to the public IP because Private DNS is wired wrong. You reason from DNS resolution, NIC IPs, and zone links. I will provide: - The PaaS resource being privatized (Storage, Key Vault, SQL, Cosmos, etc.) and its public-access setting — [TARGET_RESOURCE] - The Private Endpoint config — subnet, the private IP assigned to the endpoint NIC, target sub-resource (e.g. blob, vault, sqlServer) — [PE_CONFIG] - Private DNS zone config — which zone(s), the A records, and the virtual-network links — [DNS_CONFIG] - How clients resolve DNS — custom DNS servers, Azure-provided DNS, conditional forwarders, on-prem resolution — [DNS_RESOLUTION_PATH] - The symptom — what resolves to what (`nslookup`/`dig` output), and whether traffic still reaches the public endpoint — [SYMPTOM] Your job: 1. **Confirm the failure mode** — is the endpoint NIC IP correct, is the connection Approved, and most importantly does the client resolve the PaaS FQDN to the private IP or the public one? Most "private endpoint not working" tickets are DNS, not network. 2. **DNS zone correctness** — verify the right Private DNS zone name for the sub-resource (e.g. `privatelink.blob.core.windows.net`, `privatelink.vaultcore.azure.net`), that it has an A record pointing at the endpoint NIC IP, and that it's linked to the VNet the client lives in. 3. **Resolution path** — for custom DNS or on-prem clients, confirm conditional forwarders point at the Azure DNS resolver / a DNS Private Resolver so the privatelink CNAME chain resolves to the private zone, not public. 4. **Lock the public door** — recommend disabling public network access on the PaaS resource only after private resolution is confirmed working end to end, and note any firewall/selected-network rules that need to stay for break-glass. 5. **Cross-region / cross-VNet** — flag missing VNet links and hub-spoke topologies where the zone is linked to the wrong VNet. Output as: (a) the confirmed root cause with the resolution evidence; (b) the read-only DNS checks to run (`nslookup <fqdn>` from inside the VNet) before and after; (c) the exact fix commands in safe order; (d) a note on what breaks if public access is disabled before DNS is right. Use only what I provided. If the nslookup output or zone links aren't shown, ask — don't assume the DNS path.
Why this prompt works
Private Endpoint failures are almost always DNS failures wearing a networking costume. The endpoint shows “Approved” and “Connected,” the NIC has a private IP, and yet traffic keeps hitting the public endpoint — because the client is still resolving the PaaS FQDN to its public address. This prompt puts that reality front and center: the first job is to check what the client actually resolves the FQDN to, not to inspect the endpoint in isolation. That reframing alone resolves the majority of “Private Link isn’t working” tickets, because it points the investigation at the Private DNS zone and resolution path instead of the network.
The detail that makes this prompt grounded is sub-resource awareness. Each Azure PaaS service uses a specific privatelink zone — privatelink.blob.core.windows.net for blob storage, privatelink.vaultcore.azure.net for Key Vault, and so on — and getting the zone name or the A record wrong produces exactly the silent public-fallback symptom. By requiring the target resource, sub-resource, and zone configuration, the prompt can verify the specific zone is right and linked to the VNet the client lives in, which is where hub-spoke topologies routinely go wrong.
The guardrails encode the single most dangerous move in this work: disabling public network access before private resolution is confirmed. It is tempting to lock the public door as the first step, but if DNS still resolves to the public endpoint you’ve just cut off every client, including the management and CI/CD tooling you need to fix it. By requiring confirmed private resolution before lockdown, the prompt lets you tighten access fully while keeping the change safe and reversible.