Custom DNS Causing Storage Account Connectivity Failure in Azure Container Apps

Hi @Sharma, Ritika

Thank you for reaching out to Microsoft Q&A.

This issue occurs because when a custom DNS server is configured at the Virtual Network level used by Azure Container Apps, Azure no longer automatically uses its built‑in platform DNS for name resolution. Azure Container Apps rely on Azure DNS to resolve critical service endpoints such as Azure Storage account FQDNs and Private Endpoint records. If the custom DNS server is not properly configured to resolve or forward these Azure‑specific domains, DNS resolution for endpoints like <storage-account>.table.core.windows.net fails, resulting in transient connectivity errors such as “Resource temporarily unavailable”. This is why the setup works with Azure default DNS but breaks immediately after switching to custom DNS.

Refer below points to resolve this issue or this is the workaround:

Configure DNS forwarding to Azure Platform DNS (mandatory)

When using custom DNS servers, ensure that they forward unresolved DNS queries to the Azure recursive resolver IP:

168.63.129.16

This is required so Azure service FQDNs (including Storage Accounts and Private Endpoints) can be resolved correctly from within the Container Apps environment.

Ensure Private DNS zone for Storage Account is configured correctly

If the Storage Account uses a Private Endpoint, verify that the following Private DNS zone exists and is correctly linked to the VNet used by Azure Container Apps:

• privatelink.table.core.windows.net Make sure the A‑record for <storage-account> points to the Private Endpoint’s private IP address and there are no stale or duplicate DNS records.

Do not mix Azure DNS and custom DNS IPs in VNet DNS settings Avoid configuring both custom DNS IPs and 168.63.129.16 directly in the VNet DNS server list. Mixing them can cause inconsistent DNS resolution because requests may randomly hit different upstream resolvers. Use only custom DNS servers and handle Azure DNS resolution through forwarding.

Allow Azure Platform DNS traffic (Consumption plan specific) For Azure Container Apps running on the Consumption plan, network security rules must allow traffic to Azure Platform DNS (168.63.129.16). Blocking this IP or the AzurePlatformDNS service tag can break internal resolution even if custom DNS is configured.

Validate DNS resolution from the container

From a container console inside the Container App, validate name resolution:

nslookup <storage-account>.table.core.windows.net 
nslookup <storage-account>.privatelink.table.core.windows.net

Both should resolve to the expected private IP address.

Yes. When a virtual network that hosts an Azure Container Apps environment uses custom DNS, the DNS servers must be configured so that all required Azure FQDNs (including storage account endpoints and private endpoints) can still be resolved. If this isn’t done, calls such as <storage-account>.table.core.windows.net:443 will fail with transient “resource temporarily unavailable” or connection errors.

Key requirements and checks for custom DNS with Azure Container Apps:

1. Configure DNS forwarders to Azure DNS
   • For VNets using custom DNS, the DNS servers must forward unresolved queries to the Azure recursive resolver at 168.63.129.16.
   • Without this forwarder, names like <storage-account>.table.core.windows.net or the private-link zone records for the storage account can’t be resolved from the Container Apps environment.
   • This requirement is explicitly called out for Container Apps environments:
     • If the VNet uses a custom DNS server, configure the DNS server to forward unresolved DNS queries to 168.63.129.16.
2. Don’t block Azure DNS in NSGs/firewalls (for Consumption plan)
   • For Container Apps environments on the Consumption plan, traffic to Azure Platform DNS must be allowed:
     • Allow the AzurePlatformDNS service tag, which includes 168.63.129.16.
     • Blocking this breaks environment functionality even if custom DNS is configured.
   • For Dedicated workload profiles, AzurePlatformDNS can be blocked only if custom DNS is fully and correctly configured to handle all required lookups.
3. Avoid mixing Azure DNS and custom DNS in VNet settings
   • If the VNet DNS server list mixes custom DNS IPs and 168.63.129.16, different components (nodes vs. pods/containers) may send queries to different upstream servers.
   • As seen with AKS/CoreDNS, random selection of upstream DNS can cause intermittent failures when some servers can resolve private endpoints and others cannot.
   • Recommended pattern:
     • In VNet DNS settings: list only custom DNS servers.
     • On those custom DNS servers: configure forwarders to 168.63.129.16.
4. Ensure private endpoint zones and records are correctly configured on custom DNS
   • For storage account private endpoints, custom DNS must be able to resolve the storage FQDNs to the private IPs in the VNet.
   • This is typically done by:
     • Hosting the corresponding Private DNS zones (for example, privatelink.table.core.windows.net) and linking them to the VNet, or
     • Replicating the required records into the custom DNS and forwarding anything else to 168.63.129.16.
   • If DNS resolution is incorrect, the guidance is to review custom DNS settings and validate that DNS configuration is correct for private link resources.
5. Verify DNS resolution from inside a container app
   • Deploy a simple test container app and exec into it.
   • Check /etc/resolv.conf to confirm the expected DNS servers are present.
   • Use tools like nslookup or dig (if available in the image) to resolve <storage-account>.table.core.windows.net and confirm it returns the private IP from the private endpoint subnet.
6. General DNS troubleshooting steps
   • Confirm the VNet used by the Container Apps environment is actually configured to use the intended custom DNS servers (VNet → DNS servers in the portal).
   • If using private endpoints, verify that DNS resolution returns the private IP address in the private endpoint subnet for the storage account FQDN.
   • If resolution is incorrect, update custom DNS or, for testing, temporarily add host entries mapping the storage FQDN to the private IP.

If these DNS-forwarding and NSG/firewall requirements are met and the private endpoint DNS records are correctly configured, Container Apps should be able to resolve and connect to the Storage Account table service over its private endpoint without the connectivity failures observed.

References:

• Private endpoints and DNS for virtual networks in Azure Container Apps environments
• Troubleshoot a container app
• Can't get private IP address of an Azure Container Registry FQDN
• Troubleshoot DNS resolution failures from inside the pod but not from the worker node
• Troubleshoot network connectivity
• Deploy a container group with custom DNS settings
• Troubleshoot connection to a project with a private endpoint (classic)