Skip to main content
This article explains how to integrate Azure Private Endpoints with DNS so clients can resolve service names to private IPs. It covers two common scenarios:
  • Virtual network workloads that use Azure-provided DNS (no custom DNS servers).
  • On-premises clients that cannot reach Azure’s internal DNS IP and therefore require a DNS resolver or forwarding solution.
These approaches ensure that service FQDNs such as acsql1.database.windows.net resolve to the private endpoint IP and that clients communicate privately over the Azure backbone or site-to-site connectivity.

​
Scenario A — Virtual network workloads (Azure-provided DNS)

When a VM or other resource inside an Azure virtual network uses Azure-provided DNS (the default), DNS resolution for private endpoints follows this flow:
  1. The client sends the DNS query to the Azure-provided DNS server (clients inherit this DNS setting from the VNet).
  2. Azure DNS checks the Private DNS zones linked to that VNet (for example, privatelink.database.windows.net).
  3. If a matching record exists (for example, acsql1 in privatelink.database.windows.net), Azure DNS returns the private response.
  4. The client receives the private name (a CNAME to the privatelink zone plus an A record to the private endpoint IP) and connects directly to the service via the private endpoint.
Example DNS response a client may receive: 
Response: CNAME azsql1.privatelink.database.windows.net
A azsql1.privatelink.database.windows.net 10.5.0.5
Because the client receives the private IP, traffic goes through the private endpoint instead of the public service IP. This pattern is the same for Private Link-enabled services such as Azure SQL, Azure Storage, or other PaaS services.
A diagram of Azure DNS and private endpoint flow showing a client VM in a virtual network resolving a privatelink.database.windows.net private DNS zone via Azure-provided DNS and recursive resolvers. The resolution maps to a private endpoint (10.5.0.5) that connects privately to an Azure SQL instance (azsql1.database.windows.net).
Important note: this setup works only for clients that can reach the Azure-provided DNS service (168.63.129.16) from inside Azure VNets.

​
Scenario B — On-premises clients (need a DNS resolver/forwarder)

On-premises clients cannot query the Azure internal DNS IP address (168.63.129.16) because it is not reachable outside Azure. To allow on-premises systems to resolve Private Link names to private IPs, use an Azure Private DNS Resolver or deploy your own DNS servers inside Azure and configure conditional forwarding. Key components of the resolver-based approach:
  • Azure Private DNS Resolver is deployed into an Azure VNet and exposes:
    • Inbound endpoints: where on-premises or external DNS servers forward queries.
    • Outbound endpoints: used by the resolver to query recursive DNS servers as needed.
  • Link the resolver’s VNet to the Private DNS zones that contain privatelink records.
  • Configure a conditional forwarder on your on-premises DNS servers to forward queries for Azure service domains (e.g., database.windows.net, blob.core.windows.net) to the resolver’s inbound endpoint.
  • The resolver answers requests for privatelink records and returns private IPs across your VPN or ExpressRoute connection.
A network architecture diagram showing on-premises servers and desktops connecting to Azure via ExpressRoute/site-to-site gateway and using Azure DNS Private Resolver for DNS forwarding. It highlights inbound/outbound resolver endpoints, virtual network peering, Azure Private DNS, and spoke VNets with VMs.

​
How the resolver-based flow works (step-by-step)

  1. An on-premises or Azure client issues a DNS request; on-premises DNS servers forward relevant queries to the Azure Private DNS Resolver via a conditional forwarder.
  2. The resolver checks its linked Private DNS zones for a matching privatelink record (for example, acsql1.privatelink.database.windows.net).
  3. If the record exists, the resolver returns the private answer to the client. If not, the resolver forwards the query to recursive DNS servers using its outbound endpoints.
  4. The client then connects directly to the private endpoint IP returned in the DNS response via VPN/ExpressRoute or within Azure.
This pattern is DNS forwarding: you forward queries for targeted Azure service domains to the resolver so that they resolve to Private Endpoint addresses.
A network diagram showing how Azure virtual networks and on-premises workloads use a DNS forwarder / Azure DNS Private Resolver to resolve a private SQL Server endpoint. It shows VNet peering and VPN/ExpressRoute links between client VMs, a subnet with the private resolver, and a private endpoint for sql-server.database.windows.net.

​
Quick comparison

ScenarioWhen to useKey configuration
Virtual network (Azure-provided DNS)Resources inside Azure VNets that use default Azure DNSLink Private DNS zone to VNet; Azure-provided DNS resolves privatelink records
On-premises (DNS resolver/forwarder)On-prem clients that cannot reach 168.63.129.16Deploy Azure Private DNS Resolver or Azure DNS-forwarding VMs; configure conditional forwarders from on-prem DNS to resolver; link resolver VNet to Private DNS zone
Best practices and reminders
Use a conditional forwarder on your on-premises DNS servers to forward queries for Azure service domains (for example, database.windows.net or blob.core.windows.net) to the Azure Private DNS Resolver. Also ensure the resolver’s virtual network is linked to the appropriate Private DNS zones.
Remember: the Azure internal DNS address 168.63.129.16 is only reachable from within Azure VNets. On-premises systems cannot query it directly — use a resolver or DNS forwarder instead.
If you configure conditional forwarders correctly and link the resolver’s VNet to the Private DNS zones created for private endpoints, both Azure and on-premises clients will resolve private endpoint addresses and connect privately to the service.

Watch Video