I85PREP
⌘ K
Azure AZ-700 study materials
Azure AZ-700 study resources

Private Endpoint Name Resolution Across Spokes and On-Premises

Azure AZ-700 · Put your knowledge to work in context.

All case studies

Private Endpoint Name Resolution Across Spokes and On-Premises

Contoso has a hub (10.10.0.0/22) peered to spoke1 (10.11.0.0/24) and spoke2 (10.12.0.0/24). Storage account stcontoso01 has a blob private endpoint in hub subnet snet-pe (10.10.2.0/24) with private IP 10.10.2.5. The zone privatelink.blob.core.windows.net is linked to the hub VNet only and contains the A record for stcontoso01. Hub VMs resolve stcontoso01.blob.core.windows.net to 10.10.2.5. Spoke VMs use Azure-provided DNS and resolve it to the public IP, and their traffic to the public IP is blocked by an NSG. On-premises servers conditionally forward privatelink.blob.core.windows.net to a domain controller in the hub and resolve correctly. A partner at 203.0.113.0/24 must keep uploading over the public endpoint.

1. Explain why the spokes fail and compare the remediation options.

Read the worked answer

Cause: a private DNS zone is only authoritative for the VNets it is linked to. Azure-provided DNS (168.63.129.16) answers from the perspective of the VNet where the query originates. Spoke1/spoke2 are not linked to the zone, so the query falls through to public resolution and returns the storage account's public IP, which the NSG then blocks.

Remediation options:

  1. Link the zone to spoke1 and spoke2 (registration off). Simplest, no infrastructure. Cost: every new spoke needs a link, and it does not help on-premises or hybrid clients generically.
  2. Central DNS forwarder in the hub - point spokes' DNS servers at a forwarder (or the hub DCs) that resolves via the hub's linked zone. Scales to many spokes and covers on-premises with the same conditional forwarder. Cost: you now own highly available DNS; two forwarders in different availability zones are mandatory.
  3. Azure DNS Private Resolver inbound endpoint in the hub - managed replacement for the DIY forwarder, and it removes the need for on-premises clients to route to a DC. Higher cost, but no VM to patch.

Do not 'fix' this by allowing the spokes to reach the public endpoint - that defeats the purpose of the private endpoint and re-opens data exfiltration.

2. The partner must keep using the public endpoint while everyone else is blocked. How do you configure the storage account, and what else must be true?

Read the worked answer

A private endpoint and public access are not mutually exclusive.

  • Set publicNetworkAccess = Enabled and configure the storage firewall: default action Deny, with a virtual network rule or IP rule for 203.0.113.0/24.
  • Keep the private endpoint in place; private endpoint traffic is allowed regardless of the public firewall default action once the PE connection is approved.
  • Confirm the partner actually egresses from that range; a single NAT IP changing quarterly is a support ticket waiting to happen - require a documented, stable range.

Also verify:

  • On-premises clients that resolve to 10.10.2.5 must have a route to that address (VPN/ExpressRoute plus the hub-spoke path). Name resolution to a private IP with no route is the most common 'private endpoint is broken' false alarm.
  • Do not disable 'Allow trusted Microsoft services' unintentionally - some platform integrations depend on it.
  • Diagnostic logs must record the caller IP so you can prove the partner is the only public consumer.

3. A second storage account is added in West Europe and must be reachable from all the same clients. What must change in DNS, and what will you check first when it does not resolve?

Read the worked answer

DNS: the private DNS zone name is fixed per service (privatelink.blob.core.windows.net). The new account's private endpoint simply adds a second A record (stcontoso02) to the same zone - do not create a second zone. What must be true:

  • The zone is linked to every VNet whose clients need to resolve it (hub plus both spokes, or the forwarder path is in place).
  • The record is created by the private endpoint's DNS zone group - verify the A record exists and its TTL, not just that the PE is 'Approved'.
  • On-premises conditional forwarding still targets the hub resolver; nothing new is needed there.

Check order when it fails:

  1. nslookup stcontoso02.blob.core.windows.net from the failing client - public IP, NXDOMAIN, or private IP? That single answer splits DNS from routing.
  2. Effective routes on the client NIC for 10.10.x - a correct private IP with no route looks identical to a DNS failure to the application.
  3. The PE's target sub-resource (blob vs dfs vs file) - a mismatch resolves and connects but returns 400/403.
  4. Whether the zone group was created after the PE; pre-existing PEs often have no A record until you add the zone group.