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.
11 comments
-
Anonymous
commented
Hello,
After some time spent with the support team (thanks to them), we realized that the private DNS feature had a different behavior depending on what was using it. Of course, the private DNS zone was linked to a VNET and on this vnet we had some App Service plans with function apps. The function apps couldn't make use of the private DNS: "non existent domain" was yieleded by nameresolver in the function app console. The business goal was to use azure private DNS zones to resolve on-prem adresses within 10.x.y.z/8 range that are reacheable through a VPN.
With the support team we then deployed a VM in the same VNET as the app service plan and it worked !
We had some other VNETs with function apps that were able to use the private DNS zones, so we compared and ..... the vnet where function apps couldnt resolve private zones had a vnet gateway setup instead of a plain regional vnet integration. This looks to prevent private DNS zones to be used, too bad.
So now we have several options:
- rework the existing VNET and routing to remove the VNET gateway. Difficult as it is in prod
- add a VM used by the function app to perform DNS queries. Extra cost, maintenance , ...
- use on-prem existing DNS through VPN. We will use this most likely, despite the fact we wanted a loosely coupled infra on Azure.As a conclusion, it could be great if all services could provide the same experience no matter the service using it, especially as the same VNET provides different experiences depending on the attached endpoint.
-
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/
-
hsakoh
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 Bellée
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
-
hsakoh
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!