Private Endpoint DNS
Configure DNS for private endpoints — the resolution chain, recommended zone names, integration patterns for Azure-only and hybrid environments.
Private Endpoint DNS
Private endpoints are only useful if DNS resolves the service FQDN to the private IP. Without proper DNS, your application connects to the public IP and bypasses the private endpoint entirely. This module is critical for the exam.
🎬 Video coming soon
Private Endpoint DNS Configuration
Private Endpoint DNS Configuration
~12:00The private endpoint gives you a private IP. But applications still use the public FQDN. Without proper DNS, the FQDN resolves to the public IP — traffic goes over the internet, completely bypassing your private endpoint. You need DNS configured so the FQDN resolves to the private IP instead.
The DNS Resolution Chain
When you create a private endpoint for Azure SQL Database (mydb.database.windows.net), here’s what happens to DNS:
Step 1: Client queries mydb.database.windows.net
↓
Step 2: CNAME redirect → mydb.privatelink.database.windows.net
↓
Step 3: A record in private DNS zone → 10.20.5.4 (private IP)Without the private DNS zone: Step 2 still creates the CNAME, but Step 3 resolves to the public IP because there’s no private zone to override it. The traffic goes over the internet.
With the private DNS zone: The zone privatelink.database.windows.net contains an A record for mydb pointing to 10.20.5.4. Resolution completes to the private IP.
This two-step CNAME chain is how Microsoft makes private endpoints transparent — existing connection strings (mydb.database.windows.net) work without modification.
Recommended Private DNS Zone Names
Each Azure service has a specific zone name. The exam tests that you know these:
| Azure Service | Private DNS Zone Name |
|---|---|
| Azure SQL Database | privatelink.database.windows.net |
| Azure Blob Storage | privatelink.blob.core.windows.net |
| Azure File Storage | privatelink.file.core.windows.net |
| Azure Table Storage | privatelink.table.core.windows.net |
| Azure Queue Storage | privatelink.queue.core.windows.net |
| Azure Key Vault | privatelink.vaultcore.azure.net |
| Azure Web Apps | privatelink.azurewebsites.net |
| Azure Cosmos DB (SQL API) | privatelink.documents.azure.com |
| Azure Monitor | privatelink.monitor.azure.com |
| Azure Container Registry | privatelink.azurecr.io |
Exam Tip: You don’t need to memorise every zone name, but know the pattern:
privatelink.{service-specific-domain}. The most commonly tested are SQL Database, Blob Storage, and Key Vault.
Integration Patterns
Pattern 1: Azure-Only (Simplest)
When all resources are in Azure with no on-premises connectivity:
- Create the private DNS zone (e.g.,
privatelink.database.windows.net) - Link the zone to your VNet(s) — resolution links
- Enable auto-registration when creating the private endpoint (it creates the A record automatically)
- All VMs in linked VNets resolve the FQDN to the private IP
Pattern 2: Hybrid with DNS Private Resolver (Recommended)
When on-premises servers also need to resolve private endpoints:
On-Prem Server
↓ (DNS query: mydb.database.windows.net)
On-Prem DNS
↓ (conditional forwarder for database.windows.net)
DNS Private Resolver Inbound Endpoint (in Azure VNet)
↓ (checks private DNS zone)
Returns 10.20.5.4 (private IP)
↓ (traffic flows over VPN/ER)
Private Endpoint NIC in AzureSteps:
- Deploy DNS Private Resolver with an inbound endpoint
- Create private DNS zones and link to the resolver’s VNet
- Configure on-premises DNS to forward Azure-specific zones to the resolver’s inbound IP
- On-prem servers resolve the private IP and connect over VPN/ExpressRoute
Pattern 3: Legacy — Forwarder VMs
Before DNS Private Resolver existed, the pattern was:
- Deploy two DNS forwarder VMs in Azure (for HA)
- Configure them to forward to Azure DNS (168.63.129.16)
- Link private DNS zones to the forwarder VMs’ VNet
- Point on-premises DNS conditional forwarders to the VM IPs
This still works but is not recommended for new deployments. DNS Private Resolver is the managed replacement.
| Aspect | Azure-Only (Private DNS Zones) | Hybrid with Private Resolver | Hybrid with Forwarder VMs (Legacy) |
|---|---|---|---|
| Management | Fully managed — link zones to VNets | Managed service — deploy resolver with inbound endpoint | You manage DNS VMs, OS patching, and availability |
| High availability | Built-in (Azure DNS is zone-redundant) | Built-in (managed service with SLA) | You must deploy and maintain two VMs minimum |
| On-premises resolution | Not supported — Azure VNets only | Yes — on-prem forwards to resolver inbound IP | Yes — on-prem forwards to VM IPs |
| Performance | Low latency within Azure | Low latency, optimised for Azure DNS queries | Depends on VM sizing and load |
| Cost | Very low (zone hosting plus queries) | Per-hour for resolver endpoints | VM compute costs (always running) |
| Recommended for | Pure Azure environments | New hybrid deployments (recommended) | Existing deployments only — migrate to Private Resolver |
Common DNS Mistakes
Exam Tip — The #1 Private Endpoint Mistake: Creating a private endpoint without configuring DNS means the FQDN still resolves to the public IP. Your application connects over the internet, completely bypassing the private endpoint.
Always verify DNS resolution after creating a PE:
- From Azure VM:
nslookup mydb.database.windows.netshould return the private IP- If it returns a public IP, the private DNS zone is missing or not linked to the VNet
Other common mistakes:
- Forgetting to link the private DNS zone to all VNets that need resolution
- Not configuring conditional forwarders for on-premises DNS
- Using custom DNS servers on the VNet without forwarding to 168.63.129.16
Common Private DNS Zone Mistakes
These three mistakes cause most private endpoint DNS issues on the exam and in real life:
1. Zone not linked to the VNet: You create the private DNS zone but forget to link it to the VNet where your VMs live. The VMs query Azure DNS, but Azure DNS does not check unlinked zones. Fix: create a VNet link from the zone to every VNet that needs resolution.
2. Auto-registration confusion: Auto-registration is for VM A records (VM name to IP). It is NOT required for private endpoints. Private endpoints create their own A records when you enable “Integrate with private DNS zone” during PE creation. Do not confuse the two features.
3. On-premises DNS not forwarding: Your Azure VMs resolve fine, but on-prem servers still get the public IP. Fix: configure conditional forwarders on your on-prem DNS to forward privatelink zones to a DNS Private Resolver inbound endpoint (or legacy forwarder VMs).
On-Premises DNS for Private Link Service
When you create a Private Link service (exposing your own custom service), the DNS pattern differs:
- There’s no automatic CNAME chain (that’s only for Azure PaaS services)
- The consumer creates a private DNS zone and manually adds an A record for the custom FQDN
- Or the consumer uses their own DNS infrastructure to create the mapping
Key Takeaways
- DNS is critical — without it, private endpoints are bypassed
- The CNAME chain (FQDN → privatelink.FQDN → private IP) makes PE transparent
- Each Azure service has a specific recommended private DNS zone name
- Hybrid environments need DNS Private Resolver or forwarder VMs
- Always verify DNS resolution returns the private IP after PE creation
Test Your Knowledge
Ravi creates a private endpoint for Azure SQL but his application still connects via the public IP. What's the most likely cause?
Aisha's on-premises servers need to resolve Azure private endpoint FQDNs. What's the recommended approach?
Next up: Service Endpoints: When and How — The simpler alternative to private endpoints and when each is appropriate.