Azure Private Endpoint DNS Configuration

In this article

1. Azure services DNS zone configuration
2. DNS configuration scenarios
3. Virtual network workloads without custom DNS server
4. On-premises workloads using a DNS forwarder
5. Virtual network and on-premises workloads using a DNS forwarder
6. Private DNS zone group
7. Next steps

It's important to correctly configure your DNS settings to resolve the private endpoint IP address to the fully qualified domain name (FQDN) of the connection string.

Existing Microsoft Azure services might already have a DNS configuration for a public endpoint. This configuration must be overridden to connect using your private endpoint.

The network interface associated with the private endpoint contains the information to configure your DNS. The network interface information includes FQDN and private IP addresses for your 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 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 private link resource. Create a DNS forwarding rule to use a private DNS zone on your DNS server hosted in a virtual network.

Important

It 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.

Important

Existing Private DNS Zones tied to a single service should not be associated with two different Private Endpoints as it will not be possible to properly resolve two different A-Records that point to the same service. However, Private DNS Zones tied to multiple services would not face this resolution constraint.

Azure services DNS zone configuration

Azure creates a canonical name DNS record (CNAME) on the public DNS. The CNAME record redirects the resolution to the 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 resolving to a public DNS service, the DNS server will resolve to your private endpoints. The process doesn't affect your existing applications.

Important

• 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.
• Private endpoint private DNS zone configurations will only automatically generate if you use the recommended naming scheme in the table below.

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

1To use with IoT Hub's built-in Event Hub compatible endpoint. To learn more, see private link support for IoT Hub's built-in endpoint

Note

In the above text, {regionCode} refers to the region code (for example, eus for East US and ne for North Europe). Refer to the following lists for regions codes:

• All public clouds

{regionName} refers to the full region name (for example, eastus for East US and northeurope for North Europe). To retrieve a current list of Azure regions and their names and display names, use az account list-locations -o table.

Government

Note

In the above text, {region} refers to the region code (for example, eus for East US and ne for North Europe). Refer to the following lists for regions codes:

• US Gov

{regionName} refers to the full region name (for example, eastus for East US and northeurope for North Europe). To retrieve a current list of Azure regions and their names and display names, use az account list-locations -o table.

China

1To use with IoT Hub's built-in Event Hub compatible endpoint. To learn more, see private link support for IoT Hub's built-in endpoint

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, change your DNS configuration.

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:

• Azure Private Endpoint DNS configuration
  • Azure services DNS zone configuration
    • Government
    • China
  • DNS configuration scenarios
  • Virtual network workloads without custom DNS server
  • On-premises workloads using a DNS forwarder
  • Virtual network and on-premises workloads using a DNS forwarder
  • Private DNS zone group
  • Next steps

Note

Azure Firewall DNS proxy can be used as DNS forwarder for On-premises workloads and Virtual network workloads using a DNS forwarder.

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 168.63.129.16. Azure DNS will be responsible for DNS resolution of the private DNS zones.

Note

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:

• Client virtual network
• Private DNS zone privatelink.database.windows.net with type A record
• Private endpoint information (FQDN record name and private IP address)

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

You can extend this model to peered virtual networks associated to the same private endpoint. Add new virtual network links to the private DNS zone for all peered virtual networks.

Important

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.

Important

If you're using a private endpoint in a hub-and-spoke model from a different subscription or even within the same subscription, link the same private DNS zones to all spokes and hub virtual networks that contain clients that need DNS resolution from the zones.

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

On-premises workloads using a DNS forwarder

For on-premises workloads to resolve the FQDN of a private endpoint, use a DNS forwarder to resolve the Azure service public DNS zone in Azure. A DNS forwarder is a Virtual Machine running on the Virtual Network linked to the Private DNS Zone that can proxy DNS queries coming from other Virtual Networks or from on-premises. This is required as the query must be originated from the Virtual Network to Azure DNS. A few options for DNS proxies are: Windows running DNS services, Linux running DNS services, Azure Firewall.

The following scenario is for an on-premises network that has a DNS forwarder in Azure. This forwarder resolves DNS queries via a server-level forwarder to the Azure provided DNS 168.63.129.16.

Note

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:

• On-premises network
• Virtual network connected to on-premises
• DNS forwarder deployed in Azure
• Private DNS zones privatelink.database.windows.net with type A record
• Private endpoint information (FQDN record name and private IP address)

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

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

Note

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:

• On-premises network with a custom DNS solution in place
• Virtual network connected to on-premises
• DNS forwarder deployed in Azure
• Private DNS zones privatelink.database.windows.net with type A record
• Private endpoint information (FQDN record name and private IP address)

The following diagram illustrates the DNS resolution from an on-premises network. DNS resolution is conditionally forwarded to Azure. The resolution is made by a private DNS zone linked to a virtual network.

Important

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

Virtual network and on-premises workloads using a DNS forwarder

For workloads accessing a private endpoint from virtual and on-premises networks, use a DNS forwarder to resolve the Azure service public DNS zone deployed in Azure.

The following scenario is for an on-premises network with virtual networks in Azure. Both networks access 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 168.63.129.16.

Important

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.

Note

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:

• On-premises network
• Virtual network connected to on-premises
• Peered virtual network
• DNS forwarder deployed in Azure
• Private DNS zones privatelink.database.windows.net with type A record
• Private endpoint information (FQDN record name and private IP address)

The following diagram shows the DNS resolution for both networks, on-premises and virtual networks. The resolution is using a DNS forwarder. The resolution is made by a private DNS zone linked to a virtual network:

Private DNS zone group

If you choose to integrate your private endpoint with a private DNS zone, a private DNS zone group is also created. The DNS zone group is a strong association between the private DNS zone and the private endpoint that helps auto-updating the private DNS zone when there is an update on the private endpoint. For example, when you add or remove regions, the private DNS zone is automatically updated.

Previously, the DNS records for the private endpoint were created via scripting (retrieving certain information about the private endpoint and then adding it on the DNS zone). With the DNS zone group, there is no need to write any additional CLI/PowerShell lines for every DNS zone. Also, when you delete the private endpoint, all the DNS records within the DNS zone group will be deleted as well.

A common scenario for DNS zone group is in a hub-and-spoke topology, where it allows the private DNS zones to be created only once in the hub and allows the spokes to register to it, rather than creating different zones in each spoke.

Note

Each DNS zone group can support up to 5 DNS zones.

Note

Adding multiple DNS zone groups to a single Private Endpoint is not supported.

Next steps

• Learn about private endpoints