Private Endpoint DNS at Scale in a Hub-and-Spoke Manufacturer

Root causes, in likelihood order:

1. Spoke VNet links missing or removed from the privatelink zones - VMs in a spoke use the Azure-provided resolver and never see the zone unless the spoke is linked to it.
2. Zone sprawl - with 14 duplicate zones, the private endpoint's A record lands in one zone and the client VNet is linked to another. Resolution is non-deterministic, which explains the 'worked last week' pattern.
3. On-premises path - ExpressRoute does not carry Azure private DNS. On-premises clients need a resolver in Azure and conditional forwarders for the privatelink namespaces.
4. Forced tunnelling through the hub firewall - if DNS is proxied or blocked by a rule change, everything downstream breaks silently.

Design:

• One authoritative set of privatelink.* zones owned by the platform team in a dedicated subscription; every spoke linked, autoregistration off.
• Azure DNS Private Resolver in the hub: an inbound endpoint for on-premises queries, and a forwarding ruleset for on-premises namespaces, so spokes and on-premises share one resolver path.
• Remove application-team permission to create private DNS zones via custom role or Azure Policy. Zone ownership, not DNS technology, is the actual failure here.
• Automate endpoint-plus-record-plus-link as a single platform pipeline module so a correct deployment is also the easiest one.

Policy is necessary but not sufficient - teams routed around it because the compliant path was slower than the exception.

• Policy shape: Deny on publicNetworkAccess = Enabled for Storage, SQL, Key Vault and Service Bus, plus Deny on creation of privatelink zones outside the platform scope. Roll out in Audit for one sprint, publish the non-compliant list per owning team, then switch to Deny. Going straight to Deny before the private DNS path works produces outages and loses you the political argument.
• Existing resources: remediation tasks driven from IaC, not portal edits, so drift does not reappear next week.
• Fix the incentive: the reason for 'get unblocked' was almost certainly a multi-day wait for a VNet link or a DNS record. Ship a self-service module that creates the private endpoint, the DNS record and the spoke link in one pull request, reviewed within hours. When the compliant path is faster than the workaround, enforcement becomes uncontroversial.
• Visible exceptions: a documented, expiring exception process tracked in the risk register, with automated expiry. Covert exceptions are the ones that persist.
• Detect the remainder: Defender for Cloud alerts on public exposure of storage and database resources, routed to the owning team rather than the SOC inbox, so the feedback loop is short.

Answer honestly about what changed, then about what remains.

• What genuinely changed: with private endpoints, spoke-to-PaaS traffic goes over the private endpoint NIC in or peered to the spoke. It does not traverse the hub firewall unless you deliberately route it there. Any claim that firewall inspection still covers that traffic is wrong, and you should say so before audit does.
• What the firewall still buys: controlled internet egress with FQDN-aware rules, TLS inspection for suspicious destinations, IDPS on north-south and any inter-spoke flows you route through the hub, segmentation between ExpressRoute/on-premises and spokes, and a single authoritative flow-log source for the SOC.
• What you lose by removing it: FQDN-based egress control unless replaced, a central inspection point for on-premises-originated traffic, and a straightforward answer to a regulator asking where network segmentation is enforced.
• Decision rule: measure first. If post-migration byte counts show the majority of formerly inspected traffic now bypasses the hub, the Premium justification is a compliance and egress-control argument, not a capacity one. Keep Premium where IDPS or TLS inspection is contractually or regulatorily required and downgrade to Standard where it is not - but if you downgrade, state in writing how egress filtering and east-west segmentation are now achieved.