Azure Private Endpoint DNS configuration

When you're connecting to a private link resource using a fully qualified domain name (FQDN) as part of the connection string, it's important to correctly configure your DNS settings to resolve to the allocated private IP address. Existing Microsoft Azure services might already have a DNS configuration to use when connecting over a public endpoint. This configuration needs to be overridden to connect using your private endpoint.

The network interface associated with the private endpoint contains the complete set of information required to configure your DNS, including FQDN and private IP addresses allocated for a particular private link resource.

You can use the following options to configure your DNS settings for private endpoints:

  • Use the host file (only recommended for testing). You can use the host file on a virtual machine to override the DNS.
  • Use a private DNS zone. You can use private DNS zones to override the DNS resolution for a particular private endpoint. A private DNS zone can be linked to your virtual network to resolve specific domains.
  • Use your DNS forwarder (optional). You can use your DNS forwarder to override the DNS resolution for a particular private link resource. If your DNS server is hosted on a virtual network, you can create a DNS forwarding rule to use a private DNS zone to simplify the configuration for all private link resources.


Is not recommended to override a zone that's actively in use to resolve public endpoints. Connections to resources won't be able to resolve correctly without DNS forwarding to the public DNS. To avoid issues, create a different domain name or follow the suggested name for each service below.

Azure services DNS zone configuration

Azure services will create a canonical name DNS record (CNAME) on the public DNS service to redirect the resolution to the suggested private domain name. You can override the resolution with the private IP address of your private endpoints.

Your applications don't need to change the connection URL. When trying to resolve using a public DNS service, the DNS server will now resolve to your private endpoints. The process does not affect your existing applications.


Private networks already using the private DNS zone for a given type, can only connect to public resources if they don't have any private endpoint connections, otherwise a corresponding DNS configuration is required on the private DNS zone in order to complete the DNS resolution sequence.

For Azure services, use the recommended zone names as described in the following table:

Private link resource type / Subresource Private DNS zone name Public DNS zone forwarders
Azure Automation / (Microsoft.Automation/automationAccounts) / Webhook, DSCAndHybridWorker
Azure SQL Database (Microsoft.Sql/servers) / SQL Server
Azure Synapse Analytics (Microsoft.Sql/servers) / SQL Server
Storage account (Microsoft.Storage/storageAccounts) / Blob (blob, blob_secondary)
Storage account (Microsoft.Storage/storageAccounts) / Table (table, table_secondary)
Storage account (Microsoft.Storage/storageAccounts) / Queue (queue, queue_secondary)
Storage account (Microsoft.Storage/storageAccounts) / File (file, file_secondary)
Storage account (Microsoft.Storage/storageAccounts) / Web (web, web_secondary)
Azure Data Lake File System Gen2 (Microsoft.Storage/storageAccounts) / Data Lake File System Gen2 (dfs, dfs_secondary)
Azure Cosmos DB (Microsoft.AzureCosmosDB/databaseAccounts) / SQL
Azure Cosmos DB (Microsoft.AzureCosmosDB/databaseAccounts) / MongoDB
Azure Cosmos DB (Microsoft.AzureCosmosDB/databaseAccounts) / Cassandra
Azure Cosmos DB (Microsoft.AzureCosmosDB/databaseAccounts) / Gremlin
Azure Cosmos DB (Microsoft.AzureCosmosDB/databaseAccounts) / Table
Azure Database for PostgreSQL - Single server (Microsoft.DBforPostgreSQL/servers) / postgresqlServer
Azure Database for MySQL (Microsoft.DBforMySQL/servers) / mysqlServer
Azure Database for MariaDB (Microsoft.DBforMariaDB/servers) / mariadbServer
Azure Key Vault (Microsoft.KeyVault/vaults) / vault
Azure Kubernetes Service - Kubernetes API (Microsoft.ContainerService/managedClusters) / management privatelink.{region} {region}
Azure Search (Microsoft.Search/searchServices) / searchService
Azure Container Registry (Microsoft.ContainerRegistry/registries) / registry
Azure App Configuration (Microsoft.AppConfiguration/configurationStores) / configurationStore
Azure Backup (Microsoft.RecoveryServices/vaults) / vault privatelink.{region} {region}
Azure Event Hubs (Microsoft.EventHub/namespaces) / namespace
Azure Service Bus (Microsoft.ServiceBus/namespaces) / namespace
Azure IoT Hub (Microsoft.Devices/IotHubs) / iotHub
Azure Relay (Microsoft.Relay/namespaces) / namespace
Azure Event Grid (Microsoft.EventGrid/topics) / topic
Azure Event Grid (Microsoft.EventGrid/domains) / domain
Azure Web Apps (Microsoft.Web/sites) / sites
Azure Machine Learning (Microsoft.MachineLearningServices/workspaces) / workspace
IoT Hub (Microsoft.Devices/IotHubs) / IotHub
SignalR (Microsoft.SignalRService/SignalR ) / signalR
Azure Monitor (Microsoft.Insights/privateLinkScopes) / azuremonitor
Cognitive Services (Microsoft.CognitiveServices/accounts) / account
Azure File Sync (Microsoft.StorageSync/storageSyncServices) / afs
Azure Data Factory (Microsoft.DataFactory/factories ) / dataFactory
Azure Data Factory (Microsoft.DataFactory/factories ) / portal

DNS configuration scenarios

The FQDN of the services resolves automatically to a public IP address. To resolve to the private IP address of the private endpoint, you must change your DNS configuration accordingly.

DNS is a critical component to make the application work correctly by successfully resolving the private endpoint IP address.

Based on your preferences, the following scenarios are available with DNS resolution integrated:

Virtual network workloads without custom DNS server

This configuration is appropriate for virtual network workloads without a custom DNS server. In this scenario, the client queries for the private endpoint IP address to the Azure-provided DNS service Azure DNS will be responsible for DNS resolution of the private DNS zones.


This scenario uses the Azure SQL Database-recommended private DNS zone. For other services, you can adjust the model using the following reference: Azure services DNS zone configuration.

To configure properly, you need the following resources:

The following screenshot illustrates the DNS resolution sequence from virtual network workloads using the private DNS zone:

Single virtual network and Azure-provided DNS

This model can be extended to multiple peered virtual networks that are associated to the same private endpoint. This can be done by adding new virtual network links to the private DNS zone for all peered virtual networks.


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.


if you're using a private endpoint in a hub-and-spoke model from a different subscription, reuse the same private DNS zone on the hub.

In this scenario, there's a hub and spoke networking topology with the spoke networks sharing a common private endpoint, and all the spoke virtual networks are linked to the same private DNS zone.

Hub and spoke with Azure-provided DNS

On-premises workloads using a DNS forwarder

For on-premises workloads to resolve an FQDN of a private endpoint into the private IP address, you must use a DNS forwarder to deploy the resolution of the Azure service public DNS zone in Azure.

The following scenario is appropriate for an on-premises network that has a DNS forwarder in Azure, which in turn is responsible for resolving all the DNS queries via a server-level forwarder to the Azure-provided DNS


This scenario uses the Azure SQL Database-recommended private DNS zone. For other services, you can adjust the model using the following reference: Azure services DNS zone configuration.

To configure properly, you need the following resources:

The following diagram illustrates the DNS resolution sequence from an on-premises network that uses a DNS forwarder deployed in Azure, where the resolution is made by a private DNS zone linked to a virtual network:

On-premises using Azure DNS

This configuration can be extended for an on-premises network that already has a DNS solution in place.  The on-premises DNS solution needs to be configured to forward DNS traffic to Azure DNS via a conditional forwarder that references the DNS forwarder deployed in Azure.


 This scenario uses the Azure SQL Database-recommended private DNS zone. For other services, you can adjust the model using the following reference: Azure services DNS zone configuration

To configure properly, you need the following resources:

The following diagram illustrates the DNS resolution sequence from an on-premises network that conditionally forwards DNS traffic to Azure, where the resolution is made by a private DNS zone linked to a virtual network.


 The conditional forwarding must be made to the recommended public DNS zone forwarder. For example: instead of

On-premises forwarding to Azure DNS

Virtual network and on-premises workloads using a DNS forwarder

For a general approach that's suitable for workloads that need access to a private endpoint from virtual and on-premises networks, you must use a shared DNS forwarder to make the resolution of the Azure service public DNS zone deployed in Azure.

The following scenario is appropriate for an on-premises network that has a DNS forwarder in Azure, and virtual networks that need access to the private endpoint located in a shared hub network.

This DNS forwarder is responsible for resolving all the DNS queries via a server-level forwarder to the Azure-provided DNS service


A single private DNS zone is required for this configuration. All client connections made from on-premises and peered virtual networks must  also use the same private DNS zone.


This scenario uses the Azure SQL Database-recommended private DNS zone. For other services, you can adjust the model using the following reference: Azure services DNS zone configuration.

To configure properly, you need the following resources:

The following diagram illustrates the DNS resolution sequence from an on-premises and virtual network that uses a DNS forwarder deployed in Azure, where the resolution is made by a private DNS zone linked to a virtual network:

Hybrid scenario

Next steps