Forum Discussion
Private Endpoint to Azure Blob Storage from On-Premise
Hi sc2317 ,
I was on holidays from 20th December, so I couldn't respond earlier.
ad 1) in a scenario, where your on-prem DNS zone is not AD-integrated DNS (hosted on domain controllers), then it is correct you need to setup a conditional forwarding rule on your DNS Forwarders in Azure for those zones, otherwise your Azure VMs and other resources won't be able to resolve those names. Of course, you also need to make sure that DNS traffic from the forwarders to your on-prem is not blocked by a firewall.
ad 2) again, if your on-prem DNS is AD-integrated, the simplest solution is to extend your on-prem AD to Azure, where you can setup one or several replica domain controllers on Azure VMs. Those DCs can become your DNS Forwarders, able to resolve on-prem zones as well as Azure Private DNS zones. If your on-prem DNS is not hosted on Windows Servers (let's say you use BIND), your DNS Forwarders on Azure could be anything. I've seen a minimalistic Linux distro configured with a DNS forwarding for that purpose. You might be able to use a standalone Windows Server with DNS server role as well (I haven't seen this scenario in practice).
ad 3) It is definitely a recommended practice to centralize this configuration and both provision all Private Link DNS zones in a Hub subscription as well as link those zones with Hub VNets. Since your Spoke VNets need to be configured with Custom DNS pointing to your DNS Forwarders in the Hub, any links between Spoke VNets and DNS zones will be ignored!
Many thanks for your response, it has clarified many points along with best practices to be used for this kind of solution. However, I have few more further queries after reading the relevant documents.
1) This https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/private-link-and-dns-integration-at-scale says that, If the DNS forwarders in Azure are not authoritative for customer's corporate domains (for example, Active Directory domain names), they should have conditional forwarders for the customer's corporate domains, pointing to the on-premises DNS Servers. Can you please confirm if it is mandatory to make the solution work ?
2) Is it required to put, DNS forwarders in Azure in AD domain ? or can we just keep it in workgroup ?
3) Documentation says to create private DNS zones in central subscription where hub vnet will be deployed ? Is it best practice or is it good to use separate private DNS zone linked to spoke vnet in which private endpoint will be deployed ?
Hi sc2317 ,
I was on holidays from 20th December, so I couldn't respond earlier.
ad 1) in a scenario, where your on-prem DNS zone is not AD-integrated DNS (hosted on domain controllers), then it is correct you need to setup a conditional forwarding rule on your DNS Forwarders in Azure for those zones, otherwise your Azure VMs and other resources won't be able to resolve those names. Of course, you also need to make sure that DNS traffic from the forwarders to your on-prem is not blocked by a firewall.
ad 2) again, if your on-prem DNS is AD-integrated, the simplest solution is to extend your on-prem AD to Azure, where you can setup one or several replica domain controllers on Azure VMs. Those DCs can become your DNS Forwarders, able to resolve on-prem zones as well as Azure Private DNS zones. If your on-prem DNS is not hosted on Windows Servers (let's say you use BIND), your DNS Forwarders on Azure could be anything. I've seen a minimalistic Linux distro configured with a DNS forwarding for that purpose. You might be able to use a standalone Windows Server with DNS server role as well (I haven't seen this scenario in practice).
ad 3) It is definitely a recommended practice to centralize this configuration and both provision all Private Link DNS zones in a Hub subscription as well as link those zones with Hub VNets. Since your Spoke VNets need to be configured with Custom DNS pointing to your DNS Forwarders in the Hub, any links between Spoke VNets and DNS zones will be ignored!
- Hi David,
Many thanks for your inputs, Once again, thanks for your time to explain this and making me understand this whole configuration in best possible way.- Thanks for your feedback, Sumit. I am happy I could help. Have a great day going forward 🙂
- Hi David,
While implementing the configuration, I came across one more setting that raises doubt.
Lets say, If I implement the solution with DNS (Not AD Integrated) forwarders in Azure VNET and private endpoint in same VNET linked to private dns zone "privatelink.blob.core.windows.net". I assume everything will work with respect to private endpoint. However, I am not sure about what should I do for following:
1) What DNS suffix should I use for DNS forwarders in Azure. Should I leave it to default ?
2) What DNS servers should I use on VNET ? Should I leave it to default or use on-premise DNS as application in on-premise will use this private endpoint.