Recently I helped a customer with app service implementations. The web app service was deployed under isolated App Service Environment (ASE) and connected with enterprise VNets between on-prem servers and Azure subscriptions. When the Application tried to connect to the on-prem SQL DBs, it threw out an exception – the SQL DB name can’t be resolved. I checked the ASE vnet’s DNS settings and it looks all good to me and DNS settings points to the correct internal DNS servers. But what caused the issue?
Firstly, I worked with the app team and test using DB server IP instead of DB server name and re-run the app, it’s successfully connected and retrieved SQL data and this can approve that the issue is related with name resolutions (most likely to be DNS issue) rather than network access.
Next, I tried to verify the traffic flow. Through the Kudu console, I managed to run “nslookup” under the cmd console, I can see the below result, web app is using MS DNS server 168.63.129.16 instead of internal DNS servers. Believe or not, Web app didn’t inherit the DNS settings from ASE connected VNet, which is the root cause I am afraid.
After researching on MSDN blog, I found a way to manually overwrite the MS default DNS settings for web app service, the solution is to add AppKeys “Website_DNS_Server= primary DNS server IP”, “Website_DNS_ALT_Server=secondary DNS server IP” under the App Settings, this makes sense now since web app is a PaaS application and we don’t have the control of the underlying infrastructure.
After adding App Keys “Website_DNS_Server=primary/secondary servers IP” and restarted the web app service, the web app started to use the correct internal DNS server to resolve SQL host names now. 😊