A Comprehensive Guide to Azure Private Link and Private Endpoint DNS Integration: In-Depth Scenarios and Best Practices

Azure Private Link and Private Endpoints have revolutionized how organizations securely connect to Azure services within their virtual networks by providing private IP connectivity. However, enabling this connectivity requires careful DNS integration to ensure that application workloads resolve service names to private IP addresses rather than public endpoints.

This article offers a comprehensive and practical exploration of Azure Private Link DNS integration scenarios, including virtual networks, peered networks, and on-premises environments. We cover best practices, configuration steps, and real-world examples to help intermediate and advanced Azure architects and network administrators design secure, efficient, and reliable DNS resolution for private endpoints.

Understanding Azure Private Link and Private Endpoints

Azure Private Link allows you to access Azure PaaS services (like Azure SQL Database, Azure Storage, and more) and your own services privately over a private IP address within your Virtual Network (VNet). Private Endpoints are the network interfaces that connect you privately to these services.

When you create a Private Endpoint, Azure allocates a private IP address within your VNet. However, the associated service’s Fully Qualified Domain Name (FQDN) still resolves to its public IP address by default. To route traffic correctly to the private IP, DNS resolution must be aligned to resolve the FQDN to the private IP.

Why is DNS Integration Critical?

DNS is the cornerstone for successful Private Endpoint connectivity:

Resolution to Private IP: The service FQDN must resolve to the Private Endpoint’s IP.
Avoid Public Exposure: Prevents accidental connectivity to the service’s public endpoint, maintaining isolation and security.
Supports Hybrid Architectures: Enables on-premises and peered VNets to resolve private endpoints correctly.

Misconfigured DNS leads to application failures or traffic exposure over public internet.

DNS Configuration Scenarios for Azure Private Endpoints

Azure supports several DNS integration architectures depending on your environment:

Virtual Network workloads without Azure Private Resolver
Peered Virtual Network workloads without custom DNS
On-premises workloads using DNS forwarder without Azure Private Resolver
Azure Private Resolver for on-premises workloads
Azure Private Resolver with on-premises DNS forwarder
Azure Private Resolver for virtual network and on-premises workloads

Each scenario has unique considerations and configuration steps.

1. Virtual Network Workloads Without Azure Private Resolver

This is the simplest scenario where workloads inside a single VNet use Azure’s default DNS service (168.63.129.16).

Setup:
- Create a Private DNS Zone matching the Azure service’s private link zone, for example, privatelink.database.windows.net for Azure SQL.
- Link the Private DNS Zone to the client VNet.
- Azure automatically creates A records mapping the service FQDN to the Private Endpoint IP.
How it Works: When a workload queries the service FQDN, Azure DNS resolves it to the private IP within the VNet.
Best Practice: Use the recommended private DNS zones provided by Azure per service to avoid conflicts.

# Example: Linking Private DNS Zone to Virtual Network
az network private-dns link vnet create \
  --resource-group MyResourceGroup \
  --zone-name privatelink.database.windows.net \
  --name MyDNSLink \
  --virtual-network MyVNet \
  --registration-enabled false

2. Peered Virtual Network Workloads Without Azure Private Resolver

In hub-and-spoke or multi-VNet architectures, workloads in peered VNets need to resolve private endpoints in a shared hub.

Setup:
- Use a single Private DNS Zone linked to all VNets (hub and spokes).
- Avoid creating multiple zones with the same name to prevent record conflicts.
How it Works: The linked DNS zone provides consistent resolution across all peered VNets.
Best Practice:
- In multi-subscription or hub-and-spoke topologies, centralize Private DNS Zones in the hub.
- Link all spoke VNets to this zone to simplify management.

# Link Private DNS Zone to Spoke VNet
az network private-dns link vnet create \
  --resource-group MyResourceGroup \
  --zone-name privatelink.database.windows.net \
  --name SpokeDNSLink \
  --virtual-network SpokeVNet \
  --registration-enabled false

3. On-Premises Workloads Using DNS Forwarder Without Azure Private Resolver

When on-premises clients need to resolve Private Endpoint FQDNs, DNS forwarding is essential.

Setup:
- Deploy a DNS forwarder VM or managed service (e.g., Azure Firewall DNS proxy) inside an Azure VNet linked to the Private DNS Zone.
- Configure your on-premises DNS servers with conditional forwarders pointing to this Azure DNS forwarder for the private zone.
Important:
- Conditional forwarding should target the public DNS zone (e.g., database.windows.net), not the private zone (privatelink.database.windows.net).
How it Works: On-premises DNS forwards private endpoint queries to the Azure DNS forwarder, which resolves them correctly.
Example: Your on-prem DNS server forwards all database.windows.net queries to Azure DNS forwarder at 10.1.0.4.

4. Azure Private Resolver for On-Premises Workloads

Azure Private Resolver is a fully managed service that eliminates the need for DNS forwarder VMs.

Setup:
- Deploy Azure Private Resolver in a VNet connected to your on-premises network.
- Link Private DNS Zones to the resolver’s VNet.
- Configure on-premises DNS with conditional forwarders pointing to Azure Private Resolver.
Advantages:
- Removes maintenance overhead of DNS forwarder VMs.
- Provides high availability and scalability.
How it Works: Azure Private Resolver proxies DNS queries from on-premises to Azure DNS, returning private IP addresses for Private Endpoints.

5. Azure Private Resolver with On-Premises DNS Forwarder

For environments with existing DNS infrastructure:

On-premises DNS forwards queries for relevant zones to Azure Private Resolver.
Azure Private Resolver resolves private endpoint queries using linked Private DNS Zones.

This hybrid approach supports complex DNS topologies while leveraging Azure’s managed resolver.

6. Azure Private Resolver for Virtual Network and On-Premises Workloads

In hybrid environments where workloads from both Azure VNets and on-premises need private endpoint access:

Deploy Azure Private Resolver in a shared hub VNet.
Link the Private DNS Zone to the resolver’s VNet.
Link VNets and configure on-premises DNS conditional forwarders to use the resolver.

This unified design simplifies DNS management and ensures consistent, secure resolution across environments.

Practical Example: Configuring Private DNS for Azure SQL Private Endpoint in Hub-and-Spoke

Consider a hub VNet with a Private Endpoint for Azure SQL and two spoke VNets with client workloads.

Create the Private DNS Zone:

az network private-dns zone create --resource-group HubRG --name privatelink.database.windows.net

Link Hub and Spoke VNets:

az network private-dns link vnet create --resource-group HubRG --zone-name privatelink.database.windows.net --name HubDNSLink --virtual-network HubVNet --registration-enabled false

az network private-dns link vnet create --resource-group HubRG --zone-name privatelink.database.windows.net --name Spoke1DNSLink --virtual-network Spoke1VNet --registration-enabled false

az network private-dns link vnet create --resource-group HubRG --zone-name privatelink.database.windows.net --name Spoke2DNSLink --virtual-network Spoke2VNet --registration-enabled false

Create the Private Endpoint in Hub VNet:

az network private-endpoint create --resource-group HubRG --vnet-name HubVNet --subnet PrivateEndpointSubnet --name SqlPrivateEndpoint --private-connection-resource-id <Azure SQL resource ID> --group-ids sqlServer

Verify DNS resolution:

From a VM in Spoke1 VNet:

nslookup <sql-server-name>.database.windows.net

The response should resolve to the Private Endpoint IP address.

Best Practices for Azure Private Endpoint DNS Integration

Use Separate Private DNS Zones per Service: Avoid mixing records from different Azure services in the same zone.
Link All Relevant VNets to the Private DNS Zone: This ensures consistent resolution across peered VNets.
Avoid Overriding Public DNS Zones: Don’t override zones actively used for public resolution to prevent resolution failures.
Leverage Azure Private Resolver for Hybrid Scenarios: Reduces operational overhead and provides scalability.
Use DNS Zone Groups for Management: Automate DNS record management tied to Private Endpoints.
Test DNS Resolution Thoroughly: Validate from all client locations and networks.

Conclusion

Azure Private Link and Private Endpoints offer a secure way to access Azure services privately, but effective DNS integration is essential. By understanding and implementing the detailed DNS scenarios and best practices covered here, organizations can ensure seamless, secure connectivity across virtual networks and on-premises environments.

Whether using Azure’s default DNS, custom DNS forwarders, or Azure Private Resolver, aligning DNS configuration with your network topology ensures your applications reliably resolve service endpoints to private IPs, enhancing security and performance.

Additional Resources

Author: Joseph Perez