Design Azure Private DNS Zones when using Private Links or any other scenario

Hi,

Private Endpoints and Private Links are powerful services provided by Azure to allow you access PaaS services (Azure SQL, Azure Storage including Data Lake Gen2, Azure Web App…) via an IP address in your own network (your own Virtual Network).

See here an introduction of Private Endpoints / Private Links: https://buildwindows.wordpress.com/2019/09/17/introduction-of-azure-private-endpoints/

Supported Azure PaaS Services: https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-overview#private-link-resource

1- Is using Azure Private DNS a requirement ?

Unlike many are thinking, using Azure Private DNS is not required if you want to use PE/PL, but it’s recommended as it provides first party integration allowing your PE Private IP record to be automatically created in Private DNS zone, for future DNS resolution

2- What Zone name do i need to use for PE/PL ?

Microsoft is ‘weirdly’ recommending using a specific Zone name for PE/PL (The full list can be found here). The following table shows some DNS zones for some services:

Private Link resource type	Subresource	Zone name
SQL DB (Microsoft.Sql/servers)	Sql Server (sqlServer)	privatelink.database.windows.net
Azure Synapse Analytics (Microsoft.Sql/servers)	Sql Server (sqlServer)	privatelink.database.windows.net
Storage Account (Microsoft.Storage/storageAccounts)	Blob (blob, blob_secondary)	privatelink.blob.core.windows.net
Storage Account (Microsoft.Storage/storageAccounts)	Table (table, table_secondary)	privatelink.table.core.windows.net
Storage Account (Microsoft.Storage/storageAccounts)	Queue (queue, queue_secondary)	privatelink.queue.core.windows.net

Source: Microsoft

I’m saying ‘weirdly’ because we have found a scenario where this is unsupported.

The following picture shows:

• Project Source: A VM deployed to VNET Source
• Project A: A Storage Account SA1 with a PE/PL in VNET A and registered in the Private DNS Zone privatelink.blob.core.windows.net
• Project B: A Storage Account SA2 with a PE/PL in VNET B and registered in another Private DNS Zone privatelink.blob.core.windows.net (In fact Project A and Project B are independent, and it’s supported to create multiple private dns zones with the same name

Issue:

• If VM in VNET source wants to solve SA1 PL, the solution is to link VNET Source to the prive DNS Project A – privatelink.blob.core.windows.net, so any resource in VNET Source can solve privatelink.blob.core.windows.net records
• If VM in VNET source wants to solve SA2 PL, the solution is to link VNET Source to the prive DNS Project B – privatelink.blob.core.windows.net, so any resource in VNET Source can solve privatelink.blob.core.windows.net records –> This is not supported since a VNET cannot be linked to 2 Private Zones with the same name

-> Microsoft recommendation is not recommended in fact, because this will create future issues. It’s like creating VNETs with the same address space, and then to peer them : Unsupported

3- Design Azure Private DNS Zones

The design recommendation is simple: Each Project (The scope of how resources are managed by the same team) must have its own DNS Zone.

In order to achieve this, you can use the following rules:

• Choose a base domain (root domain) to be used by all the company’s projects. For example, your company came is CLOUDCASE, your root domain can be cloudcase.azure
• Ask each project to create a Private DNS Zone using the format {project name or project code}.RootDomain or *.{project name or project code}.RootDomain
  • Project Avalon (code AVAL) can only create Private DNS zones like
    • avalon.cloudcase.azure
    • aval.cloudcase.azure
    • dev.aval.cloudcase.azure
  • Project DEVON(code DEVO) can only create Private DNS zones like
    • devon.cloudcase.azure
    • devo.cloudcase.azure
    • uat.devo.cloudcase.azure

That’s it. Now you are sure that all your proejcts have unique private dns zones. I highly recommend that you create Azure Policies that enforce your naming conventions

HINT

Creating a PE/PL via the Azure Portal currently only shows the Private DNS zones with the recommended names, which makes you believe that a different naming is not supported.

In order to ‘hijack’ this behavior, use different deployment method than the Portal (ARM templates), or continue with the wizard and stop in the last step (do not deploy).

• Click Download a template for automation

• Click Deploy

• Go to Private Dns Name and type a existing Private DNS Zone and the Resource Group. Then click Purchase