Unlock the mystery of Azure Private Endpoints and their confusing DNS behavior. Learn why your VM can’t connect and discover three real-world fixes, from a quick hack to the enterprise-grade solution.

Azure’s Private Endpoint Paradox: Why Your VM Can’t Find Your Database

I still remember the pager alert. It was 2 AM on a Tuesday, and our flagship application was throwing database connection errors. The weird part? We hadn’t deployed any new application code. A junior engineer, trying to be proactive, had followed a security hardening guide and locked down our Azure SQL database, `prod-db-01`, by creating a Private Endpoint. Everything looked right in the portal—the endpoint had an IP, it was in the correct VNet, and the network security groups were wide open. Yet, the application VM, `prod-app-vm-01`, sitting in the *exact same VNet*, couldn’t find it. For two hours, we chased ghosts in firewall logs until the caffeine kicked in and I remembered a similar nightmare from a past life. The problem wasn’t the network path; it was DNS. The VM was asking for the public address of the database, getting a public IP back, and then being blocked by the database firewall that was now (correctly) denying all public access. It’s one of the most common, hair-pulling, “welcome to Azure networking” moments I’ve ever seen.

The “Why”: Azure’s Split-Brain DNS Problem

So, what’s actually happening here? When you create a PaaS service like an Azure SQL Database or a Storage Account, it gets a public DNS name (e.g., prod-db-01.database.windows.net). By default, this name resolves to a public IP address.

When you create a Private Endpoint for that service, Azure does two things:

1. It carves out a private IP address (e.g., 10.5.1.4) from your Virtual Network (VNet) and assigns it to the endpoint.
2. It creates a CNAME record in a Private DNS Zone (e.g., privatelink.database.windows.net) that maps the original public name to this new private IP.

Here’s the catch: Your Virtual Machine doesn’t automatically know about this new Private DNS Zone. Unless you explicitly tell it to look there, it will query public DNS, get the public IP, and fail to connect. The VM is effectively “blind” to the private route you just created. Your infrastructure has a split personality—a public one and a private one—and your resources don’t know how to talk to the right one.

The Fixes: From Desperate to DevOps-Approved

Okay, enough theory. You’re on an outage call and you need to get this working. Here are three ways to solve the problem, ranging from “get it working NOW” to “build it right for the future.”

1. The Quick Fix: The `hosts` File Hack

This is the digital equivalent of using duct tape on a leaking pipe. It’s ugly, it’s not scalable, but it will get you out of a jam in minutes. You manually edit the `hosts` file on the virtual machine to force it to resolve the database’s DNS name to the private IP address of the endpoint.

How to do it:

1. SSH or RDP into your VM (e.g., `prod-app-vm-01`).
2. Find the private IP of your Private Endpoint in the Azure Portal. Let’s say it’s 10.5.1.4.
3. Edit the hosts file (/etc/hosts on Linux, C:\Windows\System32\drivers\etc\hosts on Windows) and add the following line:

# Temporary fix for Private Endpoint DNS issue - INC-12345
10.5.1.4 prod-db-01.database.windows.net

Warning: I cannot stress this enough. This is a temporary diagnostic tool, not a production solution. It’s a manual change that creates configuration drift. If the private IP ever changes, your application breaks again. Never, ever commit this to your VM image.

2. The Permanent Fix: The VNet Link

This is the way Azure intends for you to solve this. You simply link the Private DNS Zone that Azure created to the VNet where your application VM lives. This tells any resource within that VNet, “Hey, before you go out to public DNS, check this private zone first for any matching records.”

How to do it (Azure CLI):

Find the names of your Private DNS Zone, the VNet, and the resource group. Then, run this simple command:

az network private-dns link vnet create \
  --resource-group "rg-prod-databases" \
  --zone-name "privatelink.database.windows.net" \
  --name "link-to-prod-app-vnet" \
  --virtual-network "/subscriptions/your-sub-id/resourceGroups/rg-prod-apps/providers/Microsoft.Network/virtualNetworks/vnet-prod-apps" \
  --registration-enabled false

Once the link is created, the VM will automatically start resolving prod-db-01.database.windows.net to the private IP 10.5.1.4. No VM reboots needed. This is the idempotent, infrastructure-as-code solution you should be aiming for.

3. The ‘Enterprise’ Option: Centralized DNS Forwarding

What if you have dozens of VNets in a hub-spoke topology? Linking every single VNet to every single Private DNS Zone is a management nightmare. At this scale, you should use a centralized DNS model.

The concept:

• You designate a central “hub” VNet that contains a DNS server (like Azure Firewall acting as a DNS Proxy, or a pair of VMs running BIND/Windows DNS).
• You link all your Private DNS Zones only to this hub VNet.
• You configure all your other “spoke” VNets to use the central DNS server as their custom DNS provider.

Now, when `prod-app-vm-01` in a spoke VNet wants to find the database, its query goes to the central DNS server in the hub. That server knows about the private zone, resolves the name to the private IP, and sends the correct answer back. You manage DNS links in one place, not a hundred.

Pro Tip: This is overkill for a small environment. Don’t add this complexity unless you’re managing a sprawling network. But when you need it, it’s a lifesaver.

Comparison of Solutions

So next time you’re staring at a “Cannot connect to server” error after enabling a Private Endpoint, take a breath. It’s probably not your firewall. It’s almost always DNS. Now you know exactly how to fix it.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions