In this article, We will explore how Azure Private DNS works, why it is critical for Private Link (PaaS) services, and I will walk you through a complete tutorial on setting up a “Split-Horizon” DNS architecture.
Table of Contents
Private DNS Zone Azure
What Actually Is an Azure Private DNS Zone?
Technically speaking, Azure Private DNS provides a reliable, secure DNS service to manage and resolve domain names in a virtual network without the need to add a custom DNS solution.
When you create a public DNS record (like www.google.com), that record is propagated to thousands of servers worldwide. Anyone can read it.
When you create a Private DNS Zone, that record exists only within the boundaries of the Virtual Networks (VNets) you specify.
Global Resource, Regional Effect
One concept that often confuses is the scope.
- Is it regional? No. Azure Private DNS Zones are Global resources. You create the zone once (e.g., in your main subscription), and you can link it to a VNet in “East US” and another VNet in “West US 2.”
- The Benefit: This means you don’t need to replicate DNS data across regions. If you update a record for a server in Texas, your application in New York knows about it instantly.
The Critical Use Case: Private Endpoints & PaaS
Before we get to the tutorial, you need to understand the #1 driver for using this service in 2026: Azure Private Link.
In the modern Azure security model, we are moving away from “Service Endpoints” and toward “Private Endpoints.” This means your Azure SQL Database or Storage Account gets a private IP address (e.g., 10.0.1.5) inside your VNet.
But here is the catch: Your application connection string still says my-db.database.windows.net.
If you don’t handle DNS correctly, your application will try to resolve that name, get the public IP, and fail because you blocked public access.
Azure Private DNS Zones solve this by hijacking that request.
- App asks: “Where is my-db.database.windows.net?”
- Azure Private DNS says: “Actually, look at my-db.privatelink.database.windows.net.”
- Azure Private DNS resolves: “That is at 10.0.1.5.”
Without Private DNS Zones, using Private Endpoints effectively is a nightmare of “hosts” file hacks that you simply cannot manage at scale.
Tutorial: Building a Split-Horizon DNS Architecture
Let’s get hands-on. I am going to walk you through a real-world scenario.
The Scenario:
We are “azurelessons.” We have a public website (azurelessons.com) hosted on Azure App Service. However, we also have an internal employee portal that we want to be accessible at internal.azurelessons.com.
- Public users should see a “Not Found” error if they try to visit the internal site.
- VPN/Internal users should see the portal.
This is called Split-Horizon DNS: The same domain name behaves differently depending on who is asking.
Prerequisites
- An Azure Subscription.
- A Resource Group (I’ll use
RG-Core-Infra). - A Virtual Network (
VNet-Main) where your internal VMs live.
Step 1: Create the Private Zone
Step 2: Link the Virtual Network
Check out How to Create a Private DNS Zone in Azure for both the steps.
Why Auto-registration?
This is my favorite feature for maintaining sanity. If you check this, any time you spin up a Virtual Machine in VNet-Main, Azure will automatically create an A-record for it in this zone. If you create a VM named admin-box, you can instantly ping admin-box.techcorp.com without touching DNS.
Step 3: Create the “Internal” Record
Now, let’s create the record for our internal portal.
- Go to Overview in the DNS zone.
- Click + Record set.
- Name:
internal(This createsinternal.techcorp.com). - Type:
A. - IP Address: Enter the private IP of your internal web server (e.g.,
10.5.0.4). - Click OK.
Step 4: The Testing Phase
This is where the magic becomes visible.
Test A (From your Laptop/Public Internet):
Open a command prompt on your home computer and type:
nslookup internal.techcorp.com
- Result: NXDOMAIN (Non-existent domain).
- Why: Public DNS servers have no idea this record exists. This is secure.
Test B (From a VM inside Azure):
RDP into a VM located inside VNet-Main. Open PowerShell and type:
nslookup internal.techcorp.com
- Result:
10.5.0.4. - Why: Azure recognizes you are on the “inside” and serves the record from the Private Zone.
You have just successfully deployed Split-Horizon DNS.
Advanced Architecture: The Hub and Spoke Model
In most US enterprises, you won’t just have one VNet. You will have a “Hub” (for firewall and VPN) and many “Spokes” (for applications).
If you put the Private DNS Zone in the “Hub,” how do the “Spokes” read it?
The Golden Rule of Linking:
You can link a single Private DNS Zone to multiple Virtual Networks.
I typically link my core Private DNS Zones to every VNet in the organization.
- Hub VNet: Linked (Auto-registration ENABLED).
- Spoke A VNet: Linked (Auto-registration ENABLED).
- Spoke B VNet: Linked (Auto-registration ENABLED).
Now, a server in Spoke A can resolve server-in-spoke-b.techcorp.com instantly. This flattens your name resolution strategy across the entire enterprise without complex routing.
Troubleshooting Common Headaches
Here are the top three issues I encounter.
1. The “Snowflake” Custom DNS Server
Symptom: You configured the Private Zone correctly, but your VM still can’t resolve the name.
Cause: Check the DNS settings on the Virtual Network itself.
If your VNet is configured to use a “Custom” DNS server (like an old Domain Controller at 10.0.0.4), the VM will ignore Azure Private DNS entirely.
Fix: You must forward DNS requests from your Custom DNS server to Azure’s recursive IP (168.63.129.16) to unlock the Private Zone.
2. The Private Endpoint Naming Trap
Symptom: You are using Private Link for SQL. You created a zone named mysqldb.privatelink.database.windows.net but it isn’t working.
Cause: You likely didn’t link the VNet to this specific zone.
Fix: Private Link zones are just standard Private DNS Zones. They require Virtual Network Links just like any other zone.
3. Resolution Latency
Symptom: It works, but it takes 5 seconds to resolve.
Cause: Usually improper DNS suffix search lists on the client OS (Linux is notorious for this).
Fix: Ensure your VM’s /etc/resolv.conf or Windows adapter settings are clean and prioritizing the Azure DNS suffix.
Pricing:
Private DNS is surprisingly cheap.
- Per Zone: Approx $0.50 per month.
- Per Million Queries: Approx $0.40.
For a mid-sized US company with 50 VNets and moderate traffic, your total bill for Private DNS might be $5.00 a month.
Compare this to running two Windows Server VMs for DNS, which could cost $300+ per month in compute and licensing. The ROI is immediate.
Conclusion
Azure Private DNS Zones are not just a convenience; they are a foundational component of a secure cloud architecture. They allow you to decouple your applications from static IP addresses, enable secure connectivity to PaaS services via Private Link, and handle internal routing with the same ease as public DNS.
If you are currently managing internal IPs in spreadsheets or maintaining legacy DNS servers just for your Azure VMs, stop. Spin up a Private Zone, link your networks, and you are done.
You may also like the following articles:
I am Rajkishore, and I am a Microsoft Certified IT Consultant. I have over 14 years of experience in Microsoft Azure and AWS, with good experience in Azure Functions, Storage, Virtual Machines, Logic Apps, PowerShell Commands, CLI Commands, Machine Learning, AI, Azure Cognitive Services, DevOps, etc. Not only that, I do have good real-time experience in designing and developing cloud-native data integrations on Azure or AWS, etc. I hope you will learn from these practical Azure tutorials. Read more.
