Azure Container Apps fails to resolve both GHCR and Azure Container Registry (server misbehaving)

Hi @Adamazi Juemma

Thank you for reaching out to Microsoft Q&A.

Based on the behavior described, this does not appear to be an ACR permission issue, managed identity issue, or image availability issue. The key indicator is that both GHCR (ghcr.io) and Azure Container Registry fail with the same error:

lookup <registry-fqdn> on 100.100.x.x:53:
server misbehaving

Since the failure occurs before authentication and image pull operations begin, Azure Container Apps is unable to resolve the registry hostname through the DNS path used by the Container Apps Environment. The fact that the same image deploys successfully in a non-VNet-integrated environment further suggests the issue is isolated to the networking/DNS configuration of the VNet-integrated Container Apps Environment. Microsoft's ACA guidance states that when custom DNS is configured, unresolved queries must ultimately reach the Azure recursive resolver (168.63.129.16), and blocking or misrouting DNS traffic can prevent Container Apps from resolving required service endpoints such as ACR, Microsoft Container Registry, Key Vault, and Entra ID.

Additionally, there have been reports of DNS resolution problems specifically affecting VNet-integrated ACA environments where DNS lookups fail from within the ACA infrastructure while the same names resolve successfully from VMs or other resources in the VNet.

Refer below points for further troubleshooting:

1. Validate DNS from within the Container Apps environment
   • Deploy a temporary test container and run:

          nslookup ghcr.io
          nslookup <acr-name>.azurecr.io
          cat /etc/resolv.conf
     

   • Verify which DNS server is being used and whether resolution succeeds from inside ACA.
2. Verify custom DNS forwarding
   • Ensure the custom DNS server forwards unresolved queries to:

          168.63.129.16
     

   • Confirm forwarding applies to all query types and is not restricted to specific zones.
3. Check DNS recursion and root hints

• The error "server misbehaving" is frequently returned when the upstream DNS server cannot complete recursion or resolve root queries.
  • Confirm the DNS server can successfully resolve public endpoints when queried by ACA infrastructure, not just from the DNS server itself.

1. Review firewall, DNS appliance, or DNS proxy logs
   • If Azure Firewall, Infoblox, Windows DNS, or another DNS appliance is in the path, verify that outbound TCP/UDP 53 traffic and recursive lookups are not being filtered.
2. Confirm required Azure endpoints are not being overridden
   • Ensure no private DNS zone, conditional forwarder, or wildcard zone is unintentionally overriding public registry domains such as:

          ghcr.io
          *.azurecr.io
          mcr.microsoft.com
     

   • ACA relies on successful resolution of these endpoints during image pulls.
3. Compare with a working environment
   • If another ACA environment deploys successfully, compare:
   • VNet DNS settings
   • Custom DNS server list
   • Conditional forwarders
   • Workload Profile vs Consumption architecture
   • NSG/Firewall rule