Hybrid DNS Patterns for Private Endpoints in Multi‑Site Setups

Introduction / Issue:

In multi‑site and hybrid environments, clients sometimes resolve Azure PaaS FQDNs to public endpoints instead of the Private Endpoint (PE) IP, breaking connectivity when public access is disabled and creating audit exceptions. The root cause is DNS—Private Endpoints require clients to resolve the original service name to a private IP registered in Private DNS zones; any gap in overrides or forwarding results in intermittent failures.

Why we need to do / Cause of the issue:

  • Private Endpoints depend on DNS overrides for the recommended “privatelink.*” namespaces (for example, privatelink.blob.core.windows.net, privatelink.database.windows.net, privatelink.vaultcore.azure.net).
  • On‑prem DNS typically does not know Azure Private DNS zones; without conditional forwarding to Azure, lookups fall back to public DNS.
  • If a VNet uses custom DNS, Azure’s built‑in resolver is bypassed; without forwarding rules, private zones won’t resolve.
  • Operational sprawl: multiple subscriptions/regions and app teams often duplicate zones or miss VNet links, causing drift and failures.
  • Overlapping namespaces: linking a VNet to more than one private zone with the same namespace (e.g., two privatelink.blob.core.windows.net zones) leads to errors and ambiguity.
  • During cutovers, stale caches and missing records cause intermittent outages and failed health checks.

How do we solve:

Pattern A — Centralized Private DNS + On‑Prem → Azure via Azure DNS Private Resolver (Inbound)

  1. Create Private DNS zones once per required namespace (e.g., privatelink.blob.core.windows.net, privatelink.database.windows.net, privatelink.vaultcore.azure.net) in a central subscription.
  2. Link each zone to the hub VNet and to every spoke VNet that hosts clients or Private Endpoints (resolution links, no autoregistration for PaaS zones).
  3. Deploy Azure DNS Private Resolver in the hub VNet with an Inbound Endpoint (dedicated /28 subnet).
  4. Configure on‑prem DNS conditional forwarders for each privatelink.* zone to the inbound endpoint IP.
  5. Automate PE A‑record creation using Private DNS Zone Groups and, optionally, Azure Policy to prevent drift.
  6. Validate with nslookup from on‑prem and spokes; confirm the FQDN resolves to the PE private IP.

# Example – Create zones and links (Bash / Azure CLI):
az network private-dns zone create -g RG-NET -n privatelink.blob.core.windows.net
az network private-dns zone create -g RG-NET -n privatelink.vaultcore.azure.net
az network private-dns link vnet create -g RG-NET -z privatelink.blob.core.windows.net -n hub-link \
-v /subscriptions/<sub>/resourceGroups/RG-HUB/providers/Microsoft.Network/virtualNetworks/VNET-HUB –registration-enabled false
az network private-dns link vnet create -g RG-NET -z privatelink.blob.core.windows.net -n spoke1-link \
-v /subscriptions/<sub>/resourceGroups/RG-SPOKE1/providers/Microsoft.Network/virtualNetworks/VNET-SPOKE1 –registration-enabled false
az network dns-resolver create -g RG-NET -n pr-hub –location eastus \
–virtual-network /subscriptions/<sub>/resourceGroups/RG-HUB/providers/Microsoft.Network/virtualNetworks/VNET-HUB
az network dns-resolver inbound-endpoint create -g RG-NET –dns-resolver-name pr-hub -n pr-inbound \
–ip-configurations “[{“subnet”: { “id”: “/subscriptions/<sub>/resourceGroups/RG-HUB/providers/Microsoft.Network/virtualNetworks/VNET-HUB/subnets/SNET-PR-INBOUND” }}]”

Pattern B — Azure ↔ On‑Prem Two‑Way Resolution (Inbound + Outbound + Rulesets)

  1. Keep Pattern A for all privatelink.* namespaces.
  2. Add a Private Resolver Outbound Endpoint and a DNS Forwarding Ruleset to forward Azure→on‑prem domains (e.g., corp.contoso.local) to on‑prem DNS IPs.
  3. Link the ruleset to all VNets that need Azure→on‑prem resolution, including VNets using custom DNS.
  4. Test both directions: on‑prem→Azure PEs and Azure→on‑prem service names.

# Example – Outbound endpoint + ruleset (Bash / Azure CLI):
az network dns-resolver outbound-endpoint create -g RG-NET –dns-resolver-name pr-hub -n pr-outbound \
–subnet “/subscriptions/<sub>/resourceGroups/RG-HUB/providers/Microsoft.Network/virtualNetworks/VNET-HUB/subnets/SNET-PR-OUTBOUND”
az network dns-resolver forwarding-ruleset create -g RG-NET -n pr-ruleset –location eastus
az network dns-resolver forwarding-rule create -g RG-NET –ruleset-name pr-ruleset -n corp-rule \
–domain-name corp.contoso.local –enabled true –target-dns-servers 10.1.1.10 10.1.1.11
az network dns-resolver ruleset link create -g RG-NET –ruleset-name pr-ruleset -n hub-link \
–virtual-network “/subscriptions/<sub>/resourceGroups/RG-HUB/providers/Microsoft.Network/virtualNetworks/VNET-HUB”

Validation & Troubleshooting:

  • From on‑prem: nslookup <account>.blob.core.windows.net <inbound-endpoint-ip> → returns the PE private IP.
  • From a spoke VM: nslookup <vault>.vault.azure.net → resolves via private zone (verify VNet link if not).
  • Check Private DNS zone links for each VNet; ensure no overlapping namespaces across zones.
  • If a VNet uses custom DNS, verify forwarding to the Private Resolver or to Azure’s recursive resolver.
  • Flush caches on critical clients during cutover; plan TTLs to minimize stale records.

Operational Guardrails & Automation:

  • Standard zone catalog: maintain an approved list of privatelink.* zones and publish to app teams.
  • Use Private DNS Zone Groups and Azure Policy to auto‑create and protect A‑records for PEs.
  • Centralize Private DNS zones and the Private Resolver in the hub; link spokes and on‑prem consistently.
  • Create dashboards: track lookup failures, resolver latency, and number of PE records per zone.
  • Run periodic audits for duplicate/overlapping zones and missing VNet links.

Multi‑Region & Multi‑Site Considerations:

  • One private zone per namespace across regions; link all regional VNets that host clients or PEs to the same zone for consistency.
  • Private Resolver is managed and zone‑aware; if required, deploy per‑region resolvers and keep the central zone set.
  • Follow hub‑and‑spoke architecture to avoid per‑spoke DNS servers and simplify growth.

Conclusion:

  • Centralizing Private DNS zones, implementing Azure DNS Private Resolver (Inbound for on‑prem→Azure and Outbound + rulesets for Azure→on‑prem), and automating A‑records with zone groups/policy creates a repeatable hybrid DNS pattern.
  • The result is consistent private resolution across sites, fewer failed lookups, reduced outage minutes during cutovers, and alignment with enterprise hub‑and‑spoke best practices.
Recent Posts