Private endpoints only work if their records land in the right central zone, and in a landing zone the people creating the endpoints aren’t allowed to write to that zone.
CAF’s Private Link and DNS integration at scale guidance starts from that conflict. Private DNS zones are hosted centrally with the hub, and only networking and identity administrators can manage records in them. Workload teams can create resources in their own subscriptions but have no permissions in the connectivity subscription, so they can’t create the records their private endpoints need. Policy closes the gap:
- The platform team creates the privatelink zones (for example privatelink.blob.core.windows.net) in the connectivity subscription and links the hub to them. Use the recommended zone names, because automatic record configuration only works with them.
- A Deny policy stops PaaS services being created with public endpoints.
- A Deny policy stops anyone creating a private DNS zone with the privatelink prefix, so teams can’t create their own copies; workload teams set “Integrate with private DNS zone” to No.
- A DeployIfNotExists policy watches for private endpoints of a given service and deploys a privateDnsZoneGroup that links the endpoint to the central zone. Records then follow the endpoint’s lifecycle and are removed when it is deleted.
The DeployIfNotExists assignment’s managed identity needs the Private DNS Zone Contributor role on the subscription and resource group holding the zones, because the endpoint and the zone are in different subscriptions. CAF recommends built-in policies where available, and the Azure landing zone policy set includes an initiative for this, Deploy-Private-DNS-Zones (“Configure Azure PaaS services to use private DNS zones”), made of periodically updated built-ins. Chapter 10: Governance at scale with Azure Policy covers DeployIfNotExists remediation and its identities. Figure 9.2 follows a record from the endpoint to an on-premises lookup.
Failure modes
| Symptom | Cause Learn documents | Fix |
|---|---|---|
| Endpoint created but name resolves to the public IP | The workload created its own privatelink zone, or DNS integration in IaC competed with policy | Deny privatelink zones outside the platform; don’t integrate DNS in IaC when the DeployIfNotExists approach is used |
| Records never appear | The policy’s managed identity lacks rights on the central zone | Assign Private DNS Zone Contributor where the zones live |
| On-premises clients can’t resolve endpoints | No conditional forwarders for the public service zones to the resolver’s inbound endpoint | Add conditional forwarders for each private endpoint public DNS zone |
| NXDOMAIN for a public resource of the same type | The private zone answers for that service and has no record | Enable fallback to internet on the zone’s virtual network link, or add an A record (not recommended) |
| One endpoint’s record disappears | One zone associated with two different services’ private endpoints | One zone per service type; don’t mix services in a zone |
| Multi-region endpoints drift | Regional private endpoints for the same PaaS instance need manual record maintenance | Plan an operational process; there is no automated lifecycle for this case |
Common pitfall: Letting workload pipelines create private DNS zone groups in their own code while the platform’s DeployIfNotExists policy does the same - CAF says that with the policy approach you shouldn’t integrate DNS in IaC; the policy, with the right role on the central zones, owns the records.