Private Endpoint DNS Failure¶

flowchart TD
    A[Service call returns NXDOMAIN] --> B[Check private DNS zone exists]
    B -->|Missing| C[Create private DNS zone]
    B -->|Exists| D{VNet link present?}
    C --> D
    D -->|No| E[Add VNet link to ACA VNet]
    D -->|Yes| F[Check DNS record A record exists]
    E --> F
    F -->|Missing| G[Add A record for private endpoint IP]
    F -->|Exists| H[DNS resolves correctly]
    G --> H

Symptom¶

• Container Apps can reach public internet targets, but a dependency behind a private endpoint fails with NXDOMAIN, Name or service not known, or timeout.
• A private endpoint exists, yet the app still resolves the public FQDN or nothing at all.
• The failure often appears right after a private endpoint or custom DNS rollout.

Typical evidence:

• [Observed] <account>.blob.core.windows.net or <registry>.azurecr.io does not resolve to a private IP from the app context.
• [Observed] A private DNS zone exists, but the Container Apps VNet is not linked.
• [Correlated] The incident starts after DNS zone, VNet link, or DNS forwarder changes.

Possible Causes¶

Diagnosis Steps¶

1. Inventory the private endpoint and the related private DNS zones.
2. Confirm the Container Apps VNet is linked to the right zone.
3. Test name resolution from the running app context.

az network private-endpoint show \
  --name "pe-storage" \
  --resource-group "$RG" \
  --output json

az network private-dns link vnet list \
  --resource-group "$RG" \
  --zone-name "privatelink.blob.core.windows.net" \
  --output table

az containerapp exec \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --command "python -c 'import socket; print(socket.getaddrinfo(\"mystorage.blob.core.windows.net\", 443))'"

Diagnostic interpretation:

• [Observed] Public IP resolution or no resolution at all points to DNS, not the target service.
• [Observed] Correct private IP resolution with continued timeouts shifts suspicion to NSG or route path.
• [Strongly Suggested] If one private service fails and another private service works, compare their zone names and link scopes first.

Resolution¶

1. Create or correct the service-specific private DNS zone.
2. Link the zone to the Container Apps VNet.
3. Ensure the expected A records exist for the private endpoint.
4. If custom DNS is in use, forward the relevant privatelink zones correctly.

az network private-dns zone create \
  --resource-group "$RG" \
  --name "privatelink.blob.core.windows.net"

az network private-dns link vnet create \
  --resource-group "$RG" \
  --zone-name "privatelink.blob.core.windows.net" \
  --name "link-aca-vnet" \
  --virtual-network "/subscriptions/<subscription-id>/resourceGroups/$RG/providers/Microsoft.Network/virtualNetworks/vnet-myapp" \
  --registration-enabled false

Prevention¶

• Treat private endpoint creation and DNS zone linkage as one deployment unit.
• Validate private name resolution from the same VNet path as the app.
• Document required privatelink zones for every private dependency.
• Re-test DNS whenever hub-spoke links, custom resolvers, or private endpoint records change.

See Also¶

• Private Endpoint DNS Failure Lab
• Private Endpoints
• Internal DNS and Private Endpoint Failure
• Deployment Networking Operations

Sources¶

• Azure private endpoint DNS configuration
• Networking in Azure Container Apps environment
• What is Azure Private DNS?