Forum Discussion
Private Endpoint to Azure Blob Storage from On-Premise
Hi,
I am working on solution to implement private endpoint for traffic from on-premise(DNS solution already in place) to Azure Blob Storage solution. I have referred below link(On-premises workloads using a DNS forwarder) from Microsoft which gives an overview of how we can configure. However, I have some queries so can someone please suggest.
1) In this article, private endpoint is created in hub VNET with VPN/Expressroute connection, but is it mandatory or can we create private endpoint in other Spoke VNET with peering to hub VNET ?
2) Is it mandatory to setup Conditional DNS forwarder in Azure or can we achieve the required solution by just creating new DNS zone(blob.core.windows.net) in on-premise DNS server and create A-record pointing to private endpoint IP ?
3) If its possible(As mentioned in 2nd point) to create required solution using DNS zone in on-premise DNS server, then do we still need Private DNS Zore linked to VNET ?
4) If conditional forwarder(blob.core.windows.net) is mandatory(for DNS solution already in place), then would there be any issues with users already using other storage accounts(With no Private endpoint) on public endpoint because those storage accounts will also have name "storageaccountname.blob.core.windows.net" ? I believe there will be no issues, because when query will go to internal DNS server(If users are connected on office VPN) then DNS forwarder in Azure will forward query to Microsoft IP 168.63.129.16 which will resolve it to storage accounts public IP.
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.
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 link 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!
