Well, everything described in Part I works perfectly fine when your VNETs are using Azure provided DNS Server.
But if you VNETs are using customs DNS servers, as in my case, things get a little tricky. You use custom DNS servers because you are living in a hybrid cloud solution and resources from Azure must also find resources from on premises data centers adn in this case, standard Azure provided DNS servers are of no help.
In this case, when resources are trying to resolve name for your web apps with private integration activated, no DNS server will know about them. And in this case, there at least two options available:
- Add a conditional resolver to your custom DNS server, as described here: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances#:~:text=The%20Azure%20DNS%20IP%20address,129.16. . An important thing to have in mind in this case is that traffic to Azure resolver with IP 220.127.116.11 should go over an Express Route gateway or VPN gateway, otherwise if coming on the public network it will be rejected.
- A simpler approach (tested and working) is to add the IP of the Azure resolver (18.104.22.168) in your list of custom DNS servers for the VNET. Don’t add it on the first position, as this might bring trouble in resolving on premises resources and also not on the third position or lower because this will increase the time needed for name resolution and potentially can throw timeout errors. Adding it on the second position looks like a reasonable compromise.