Private Endpoints and DNS: The Part of Azure Everyone Gets Wrong Once

There is a rite of passage in Azure: the day a private endpoint deploys green, the portal shows "Approved", and your app still connects over the public internet. Nothing is broken — except DNS, which is to say, everything.

Why it happens

A private endpoint gives your PaaS resource a NIC in your VNet. But the service's hostname — mystorageacct.blob.core.windows.net — still resolves to the public IP unless something rewrites the answer. That something is the privatelink DNS zone:

Public DNS:  mystorageacct.blob.core.windows.net
             → CNAME mystorageacct.privatelink.blob.core.windows.net
             → (public A record)  ← what you get without private DNS

Private DNS: privatelink.blob.core.windows.net zone, linked to your VNet
             → A record 10.20.4.7  ← what you want

If the client's VNet can't see the private zone, the CNAME chain falls through to the public record. Green checkmarks everywhere; traffic on the internet.

The architecture that scales

One privatelink zone per service, centralized in the connectivity subscription, linked to the hub, resolved through a hub DNS layer:

1. Azure DNS Private Resolver in the hub VNet (or DNS on your NVA).
2. Every spoke's VNet DNS points at the resolver.
3. All privatelink.* zones live in one resource group, linked to the hub VNet only.
4. On-premises DNS conditionally forwards privatelink.* to the resolver's inbound endpoint.

Automate the A-record, or drift wins

The A-record should be created by the private endpoint deployment, via a privateDnsZoneGroup — never by hand:

resource dnsGroup 'Microsoft.Network/privateEndpoints/privateDnsZoneGroups@2024-01-01' = {
  parent: privateEndpoint
  name: 'default'
  properties: {
    privateDnsZoneConfigs: [{
      name: 'blob'
      properties: { privateDnsZoneId: blobZoneId }
    }]
  }
}

Pair it with a deny policy on public network access for the PaaS services in Corp landing zones, and the failure mode inverts: misconfigured DNS now breaks loudly in testing instead of silently in production.

The five-minute diagnosis

# From a VM inside the spoke:
nslookup mystorageacct.blob.core.windows.net
# Private IP (10.x)  → DNS is correct
# Public IP          → zone link or forwarding is broken; walk the chain above

Every Azure network review I've done in the last three years has found at least one private endpoint resolving publicly. Check yours this week — it's a one-command audit and an afternoon fix.