Web App and Private DNS zone support
Web App support for using Azure Private DNS Zones without a DNS server to forward requests through. We are able to resolve the private dns queries from a VM that uses Azure provided dns and linked Private DNS zone, but the Web App is not able to do the same when using regional vnet integration. We must set the vnet to use a VM or on-prem DNS server that forwards requests to the Azure DNS IP, which is then able to return the private dns records. For a PaaS implementation, this seems clunky. The use case is to send Web App traffic across an ExpressRoute circuit, to the backend, while using URLs rather than private IPs.
MB
shared this idea
Hi everyone,
To integrate with an Azure DNS private zone, you will need to add the following two app settings:
WEBSITE_DNS_SERVER with value 168.63.129.16
WEBSITE_VNET_ROUTE_ALL with value 1
For more information, please see the doc article below. For any follow-up questions, please use the doc Q&A field at the bottom of the article.
10 comments
-
Anonymous
commented
Below comments indeed work. I wrote a blog with a complete example here: https://erwinstaal.nl/posts/securing-your-azure-db-connection-using-azure-private-link/
-
sakoh
commented
It has been added to the document.
https://docs.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet#azure-dns-private-zonesWEBSITE_DNS_SERVER with value 168.63.129.16
WEBSITE_VNET_ROUTE_ALL with value 1 -
Preston Rodriguez
commented
This does not work when using Gateway VNET integration
-
Chris Bellee
commented
I just wanted to say that I’ve confirmed sakoh’s solution works. I’ve posted an ARM template deployment example on my github.
https://github.com/cbellee/app-svc-vnet-sql-private-endpoint
-
sakoh
commented
Today, I set up the following four points and tried them
1. Create a Private DNS Zone and connect it to VNET(privatelink.blob.core.windows.net)
2. Set the VNET DNS to 168.63.129.16
3. Configure WebApps to Regional VNET Integration
4. Set WEBSITE_VNET_ROUTE_ALL of WebApps to 1I got PrivateIP from KUDU(nameresolver xxxx.blob.core.windows.net)
I was also able to access it from the PrivateIP side using curl in KUDU.It seems to be important to set both 2 and 4
-
Matt Prigge
commented
Though I know this issue doesn't directly refer to P2S VPNs, the same problem exists there. Having Private DNS work for this as well would be fantastic. Otherwise, as others have alluded to, it's just not that useful.
-
James
commented
Has there been any discussions about this?This seems like such a great feature to add to reduce the complexity and cost of adding DNS servers in my VNET. I also just got bit by this issue and must now go back to adding DNS servers.
-
Mark
commented
This is one of a few shortcomings that I have found in Azure. I understand that this is an emerging technology however it appears that a few components have been rushed to market. Private DNS zone resolution for app services is exactly what my organization needs from a security posture perspective and I was anticipating that this would be the solution, and it simply does not work. From the app service console I can see the hostfile but I cannot edit it. I would rather use a hostfile in this scenario than the two options I have listed below. The remaining options I see are –
1) Build a VM and run DNS, point the vNet to the custom DNS server.
- Yes this would work however it defeats the purpose of PaaS in my opinion. This introduces the need to manage, patch, update a server etc..
2) Publish the private IP Azure components in public DNS.
- Yes this also works but it is not good practice in my opinion. -
John Hyde
commented
Hi, just been running around trying to do the same form a function app! Be good to get this working soon as it would be really usefull.
Thanks
J -
David Sandbrand
commented
Agreed. I just spent a bunch of time fighting with MS on this when the vNet had a private DNS zone.
The workaround was to create a VM on the vNet that runs DNS services, and then manually override the web app to use that VMs internal IP as the DNS server. So clunky, and introduces many failure points.
If the app is truly integrated with the vNet, then the DNS queries will be routed through the vNET.
The amount of traffic this involves is miniscule, and without it, the advertised benefit of "Securely access resources available in or through your Azure VNet." isn't really possible or true!