I'm working with a hub-spoke network setup in Azure. In my hub VNet, I have an Azure Firewall, a DNS Private Resolver, and several linked Private DNS Zones. My spoke VNet, which includes a subnet for a Container App Environment and another for Private Endpoints, is peered with the hub VNet and configured to use a custom DNS server pointing to the private IP of the DNS Private Resolver. Recently, while trying to deploy a Container App job with an image from an Azure Container Registry (ACR), I ran into a problem. I have a private endpoint for the ACR in the same spoke VNet, and the necessary records are set up in my Private DNS Zone. However, during deployment, I received an error indicating that the DNS lookup for my ACR's URI failed: 'dial tcp: lookup .westeurope.data.azurecr.io on 100.100.238.243:53: no such host'. I'm wondering if the Container App Environment is ignoring the DNS settings for the VNet. This configuration works for other PaaS services like Key Vault and Storage Accounts, but not for my Container App Environment. Any insights would be appreciated!
4 Answers
It sounds like you might need to check the DNS records for your ACR's private endpoint. You typically need two DNS records for it: one for .westeurope.data.azurecr.io and another for .azurecr.io, both pointing to unused private IPs from the relevant subnet. Make sure those records are set up correctly!
You might want to verify that the personalized DNS settings in your spoke network are configured with the correct forwarders. Ideally, the spoke should point back to your hub's DNS resolver. If this isn’t configured right, it’s likely not resolving the private DNS correctly and the requests are not getting forwarded to your resolver.
It seems your Container App Environment isn’t resolving the private endpoint for the ACR properly. Double-check that the private DNS entries are in the correct zone and also confirm that this zone is linked with the DNS Private Resolver in your setup. If you have connectivity, try querying the private DNS resolver directly from outside the Container App Environment to see if it resolves correctly.
Thanks! I figured out that the problem was indeed DNS-related. I appreciate the help!
I found out that both private DNS zones (privatelink.azurecr.io and westeurope.data.privatelink.azurecr.io) were properly linked to my hub VNet, but the A records for the private endpoint were mistakenly created in the wrong zone. Azure seems to only check for records in the westeurope.data.privatelink.azurecr.io zone, and since those A records were not present, it resulted in an NXDOMAIN error. Adding the A record manually fixed the problem for me.
Thanks for the tip! I actually found out that both records were created, but they ended up in the wrong DNS zone. So that was causing the issue!