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!
Hi sc2317 ,
ad 1) you can create Private Endpoints in Spoke VNets (creating them in a Hub is a pattern one could consider only for shared resources that are "consumed" from several Spokes. Azure Landing Zone methodology recommends creating them in spokes (landing zones). As long as the routing is configured correctly (prefixes from your spokes are advertised to on-prem), you are good to go. There is however a complex topic that needs to be addressed - hybrid DNS. This article explains it well.
ad 2) you could in theory create such zone in your on-prem DNS, but the maintenance of records will become a manual (tedious) process, which doesn't scale. Imagine creating new records in this way every time someone enables a Private endpoint in your Azure tenant. With Conditional forwarding, you configure it once and it works regardless of how many private endpoints will be created.
ad 3) Private DNS zones have two key benefits: it is a managed service (you don't need to host any infrastructure) and the lifecycle management of records (record sets) is done via ARM, so you can reuse the same tool you have for Infrastructure as Code (JSON ARM, Bicep, Terraform, PowerShell) also for your DNS configuration. Also, your Azure resources (e.g., VMs in spokes) wouldn't be able to resolve those private endpoints correctly (unless you extend your on-prem DNS infrastructure with that "new zone" to Azure VNets = configure custom DNS to use your servers instead of Azure DNS).
ad 4) The combination of conditional forwarding for "blob.core.windows.net" (in your on-prem DNS) + DNS resolvers in Azure Hub VNet + Private DNS zone for Azure Blob (linked to the Hub VNet) + Spoke VNets configured to use 'custom DNS' (pointing to those Hub Resolvers) will ensure that you can resolve correctly both storage accounts with private endpoint enabled as well as those with a public endpoint only.
As a final note, I believe that the most scalable design for Hybrid DNS is described in these two articles: DNS for on-premises and Azure - Cloud Adoption Framework | Microsoft Docs and Private Link and DNS integration at scale - Cloud Adoption Framework | Microsoft Docs.
I hope it helps.