Andrzej Kaczmarek Infrastructure & Cloud Architect
← All posts
azurenetworkingprivate-linkdns

Getting Private Endpoint DNS right at scale in Azure

Private endpoints solve network exposure; DNS is what actually breaks in enterprise rollouts. A practical design for centralized private DNS zones, zone groups and policy-driven automation across hub-and-spoke.

· 5 min read

Private endpoints are the easy part of a Private Link rollout — a few clicks and the PaaS service has a private IP in your VNet. What actually eats a sprint is DNS: application teams who can’t create records in a zone they don’t own, spokes that resolve the public endpoint instead of the private one, and a “temporary” hosts-file workaround that’s still there eight months later. Here’s the design that avoids all three.

The rule that decides everything else

Central networking or platform teams host the private DNS zones; application teams never get direct access to them. Application teams can deploy PaaS resources with private endpoints in their own subscriptions, but they have no permission to create records in the centrally hosted zones — by design, since letting every team edit privatelink.blob.core.windows.net is how you end up with conflicting records for the same name.

That means DNS record creation has to be automated on their behalf. That’s what the private DNS zone group on the private endpoint is for.

Zone groups: stop scripting DNS records by hand

Before zone groups existed, someone had to read the private endpoint’s NIC, extract the IP, and manually add an A record — a script most teams wrote once and then maintained forever. A private DNS zone group attaches a private endpoint to one or more private DNS zones with a durable link: create the endpoint, and the matching record appears; delete the endpoint, and the record disappears with it. No orphaned records, no drift.

Two constraints to design around:

  • A zone group supports up to five DNS zones, and only one zone per zone name — you can’t attach two different privatelink.blob.core.windows.net zone resources to the same group.
  • Adding multiple DNS zone groups to a single private endpoint isn’t supported — one zone group per endpoint, covering everything that endpoint needs.

Automating it for application teams: Azure Policy, not documentation

The pattern that actually holds up at scale is a DeployIfNotExists Azure Policy assigned at the management group or subscription level: application teams deploy their PaaS resource and private endpoint in their own subscription as normal, and within a few minutes the policy triggers, deploys the DNS zone group, and the record lands in the centrally-owned zone — with the RBAC on the private DNS zone belonging entirely to the platform team’s policy identity, not to the application team.

Two things worth calling out if you’re building this policy yourself:

  • The zone name has to be the exact one the service expects — privatelink.blob.core. windows.net for Storage blob, privatelink.vaultcore.azure.net for Key Vault, privatelink.database.windows.net for Azure SQL, and so on. These are documented per service and per subresource, and they don’t always match intuition (Key Vault uses vaultcore.azure.net, not vault.azure.net, for the private zone specifically).
  • If you already provision private endpoints through Bicep or Terraform, don’t also wire up the DNS zone group in your IaC once the policy is in place — you’ll get either a conflict or a redundant resource fighting the policy-managed one. Pick one owner: policy for a centralized model, or your pipeline if the team owns its own zone links.

Choosing between centralized and distributed resolution

Once records exist in the hub-hosted zones, spoke VNets still need to actually resolve them. Azure gives you two supported patterns, and mixing them inconsistently across spokes is the most common source of “works in one spoke, not the other” tickets:

Centralized (custom DNS). Every spoke VNet’s DNS setting points directly at the inbound endpoint of an Azure DNS Private Resolver deployed in the hub. Simple to reason about — one setting per VNet — but changing a spoke’s DNS setting requires rebooting every VM in it, so plan the cutover as a change window, not a live edit.

Distributed (forwarding rulesets). Spokes keep Azure-provided DNS and instead get a DNS forwarding ruleset linked to them, with a rule that forwards privatelink.* queries to the hub’s inbound endpoint. No VNet DNS setting changes, no reboot — but you’re now maintaining a ruleset instead of a per-VNet setting.

One landmine either way: only the VNet actually linked to the private DNS zone can resolve it through that zone’s automatic resolution. In the centralized model, that’s the hub — so the hub VNet must carry the zone link even though the actual clients live in the spokes. And never link a forwarding ruleset containing a rule that points at the inbound endpoint to that same hub VNet — that’s a DNS resolution loop, not a redundant safety net.

Hybrid and multi-region, briefly

For on-premises clients, the private resolver’s inbound endpoint is what your on-prem DNS servers conditionally forward privatelink.* (and the relevant public suffixes) to — the resolver itself isn’t authoritative for your on-prem domains, so it needs its own outbound forwarder rule pointing back at on-prem DNS for anything that isn’t Azure.

For multi-region PaaS with regional private endpoints (geo-redundant storage, SQL failover groups), be aware there’s no automated lifecycle management across regions the way zone groups handle a single endpoint — each regional private endpoint’s records need to be kept in sync manually as failover events happen. Budget for that as an ongoing operational task, not a one-time setup step.

The takeaway

The private endpoint is never where Private Link rollouts get stuck — DNS ownership and resolution path are. Keep the zones centrally owned, automate record creation with a DeployIfNotExists policy so application teams never touch DNS directly, pick centralized or distributed resolution deliberately (and consistently) across every spoke, and remember that only the VNet linked to a zone benefits from its automatic resolution. Get that model agreed once, in writing, and every future PaaS rollout stops being a networking ticket.

Sources & further reading: Private Link and DNS integration at scale, Azure Private Endpoint DNS integration scenarios, Azure Private Endpoint private DNS zone values, Private resolver architecture, Azure DNS Private Resolver endpoints and rulesets.