Azure-docs: Impossible to implement DNS integration in more than a single subscription

[tomcooperca]

In order to integrate with on-premises networking either through ExpressRoute or VPN, central DNS name servers are required. When attempting to integrate private endpoints with this design, virtual network links are required to be added to private DNS zones in order for these name servers to resolve private endpoint FQDNs.

It's currently impossible to add virtual network links to multiple private DNS zones that share the same name. Since private endpoint for Azure services all use one common private DNS zone, this makes integration impossible.

It is also not possible to use a single, centralized and global pre-created private DNS zone such as one residing in a network hub when a private endpoint is created in another subscription. This limits this design to only work for Azure services (such as Azure SQL and storage) that are deployed in a single subscription and linked to the network hub's DNS virtual network.

There is no support for bring-your-own-DNS through the use of customer private DNS zones.

What is the solution recommended by Microsoft when integrating private endpoint services with on-premises networking? The only option available today is customer owned private DNS zones and managing all DNS records manually and centrally.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: b006a616-2f2f-8ecf-8b80-fd0a3cc62090
• Version Independent ID: 92c54dc6-8ddf-b1f7-4a58-d61b8cd7fe25
• Content: What is an Azure Private Endpoint?
• Content Source: articles/private-link/private-endpoint-overview.md
• Service: private-link
• GitHub Login: @malopMSFT
• Microsoft Alias: allensu

[VikasPullagura-MSFT]

@tomcooperca
Thanks for the feedback! We are currently investigating and will get back on this.

[SubhashVasarapu-MSFT]

@tomcooperca , Appreciate your patience. We have assigned this issue to the respective product owner to provide valuable insights.

[malopMSFT]

Hi Tom

The suggested DNS integration for this scenario is listed here:
https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-dns#virtual-network-and-on-premises-workloads-using-a-dns-forwarder

Recommendation is to use a single zone for all VNets, using a single DNS forwarder Link on the main VNet only.

As you described, this will need other VNets creating Private Endpoints to reference the same zone for a given service domain, this is supported in all clients like portal, PS, CLI and templates, please give it a try on the portal release on early May to cover this.

please-close

[tomcooperca]

Hi @malopMSFT,
The solution described does not work when deploying PL-enabled services in more than one subscription. There is no option when creating a service with a private link to select an Azure Private DNS zone that isn't in the same subscription in the portal. See the below error message when attempting to implement the recommendations by adding the virtual network link to the duplicate private zone:

Failed to create virtual network link 'hub-vnet'. Error: A virtual network cannot be linked to multiple zones with overlapping namespaces. You tried to link virtual network with 'privatelink.azurecr.io' and 'privatelink.azurecr.io' zones.

All the examples & documentation do not extend beyond a single subscription view, which is not a realistic design for a large enterprise tenant.

Steps to reproduce:

1. In a hub subscription (hub1), create a private DNS zone with the corresponding Azure PL zone. In this example, we will deploy two ACR resources and will use the zone privatelink.azurecr.io.
2. Create a virtual network in hub1 to simulate the network attachment point of the DNS forwarders. This vnet is called hub-vnet and CIDR used is 10.0.1.0/24
3. In a spoke subscription (spoke1), create a private endpoint enabled service such as ACR. It will attach to a spoke vnet called spoke1-vnet and use a range of 10.0.2.0/24. During creation of the private endpoint, select Yes for "Integrate with Private DNS zone". Notice that in the drop-down, the private DNS zone created in hub1 does not appear.
4. After resource is created, a new private DNS zone will appear in the resource group. A virtual network link can be added to this zone to the hub-vnet
5. In a second spoke subscription (spoke2), create a second private link enabled service. Again, during private endpoint creation, no selection of the hub1 private DNS zone is available. Another matching private DNS zone will be created in the 2nd resource group.
6. Upon attempting to add a virtual network link to the 2nd created private DNS zone, the deployment will be rejected with the error above.

What is the recommended path forward here? This use case is not at all covered in the documentation. As stated in the original issue, the current documented solutions work for a single subscription without multiple spoke vnets & resources but that is not a realistic usage scenario in any large environment.

[malopMSFT]

Our doc has the following:
A single private DNS zone is required for this configuration. Creating multiple zones with the same name for different virtual networks would need manual operations to merge the DNS records.

The error listed indicates that there's already an existing zone associated with the VNet which creates a conflict on DNS resolution.

Portal has support to select the zone from a different subscription during Private Endpoint creation.

[pietervogelaar]

@tomcooperca For Azure Key Vault I had the same situation. The comment above from @malopMSFT about a single private DNS zone pointed me in the right direction.

We have one hub subscription with several spokes. In the hub subscription I created one private DNS zone called privatelink.vaultcore.azure.net. This private DNS zone will get vault DNS records from the hub and subscription spokes.

You have to create a private endpoint for the Azure Key Vault and then with a DNS zone group you integrate it with the private DNS zone in the hub subscription. Integration means Azure will automatically insert a DNS record and remove it once the Key Vault is removed.

Example private endpoint:

az network private-endpoint create \
  --resource-group foo-lab-keyvault \
  --connection-name foo-lab-keyvault \
  --name foo-lab-keyvault \
  --location westeurope \
  --subnet /subscriptions/e82...718/resourceGroups/foo-lab-rg-network/providers/Microsoft.Network/virtualNetworks/foo-lab-vnet/subnets/foo-lab-snet-vip \
  --private-connection-resource-id /subscriptions/e82...718/resourceGroups/foo-lab-keyvault/providers/Microsoft.KeyVault/vaults/foo-lab-keyvault \
  --group-id vault

Example private endpoint dns zone group:

az network private-endpoint dns-zone-group create \
   --resource-group foo-lab-keyvault \
   --endpoint-name foo-lab-keyvault \
   --name foo-lab-keyvault \
   --private-dns-zone /subscriptions/835...210/resourceGroups/foo-hub-rg-network/providers/Microsoft.Network/privateDnsZones/privatelink.vaultcore.azure.net \
   --zone-name privatelink.vaultcore.azure.net