Allow defining DNS zone IP to deployment scripts container #18600
Description
Is your feature request related to a problem? Please describe.
Currently, using deploymentScripts DNS names correctly in private networking (see docs), seems to rely on the DNS zone IP obtained from the VNet.
In our architecture, VNets use a custom DNS resolver (Azure Firewall within our Virtual WAN hub). Not all VNets are directly linked to the private DNS zones—they are only peered to the vWAN hub. DNS entries for private endpoints are managed by policy and created automatically, but this process has a delay of 10–15 minutes.
As a result, deployment scripts fail in this setup because the container cannot resolve names and gets stuck in the Waiting state. We managed to make it work by directly linking the DNS zone to our landing zone VNet and opening firewall rules, but this conflicts with our DNS/networking architecture. Therefore, we cannot use deploymentScripts due to this limitation.
Lack of deployment scripts currently prevents us from performing certain data plane operations within the pipeline. This leaves us with two undesirable options:
- Break the deployment execution into multiple phases and run Azure CLI scripts in between.
- Accept that the first run against a fresh environment fails, and only the second run succeeds after DNS propagation and data plane operations are completed.
Describe the solution you'd like
Deployment scripts should work althogh DNS entries are created by policy and direct DNS zone IP cannot be accessed, but it is instead behind Azure Firewall within vWAN Hub. See the expected network topology regarding DNS from Azure Virtual Wan Hub documentation.