Skip to main content
In this lesson you’ll learn how to configure DNS inside Azure Virtual Networks (VNets) using your own DNS servers and Azure Private DNS Zones. This setup is common in enterprise and hybrid environments where you need custom name resolution, consistency with on‑premises DNS, or host name auto‑registration. At a high level, the architecture looks like this: two Azure VNets (VNet1 and VNet2), each running VMs and a local DNS server (10.1.0.4 in VNet1 and 10.2.0.4 in VNet2). An on‑premises DNS can forward queries into Azure. Each VM uses the local custom DNS server. That DNS server resolves local names and forwards queries it cannot resolve either to other DNS servers over peering/S2S or to Azure’s platform resolver at 168.63.129.16 for Azure service names.
A network diagram showing how to bring your own DNS into two Azure VNets, with custom DNS servers (10.1.0.4 and 10.2.0.4), DNS query forwarding between VNets over an S2S link, and queries sent to Azure (168.63.129.16). The image also calls out best practices like enabling recursive resolution, allowing DNS traffic on port 53, providing host name resolution, and securing the DNS server.
Best practices
  • Configure DNS servers for recursive resolution and add forwarders where needed (to Azure DNS or on‑prem/third‑party resolvers).
  • Allow DNS traffic (UDP/TCP port 53) through relevant NSGs, firewalls, and VNet/NVA routes.
  • Keep DNS servers internal to trusted networks — do not expose authoritative DNS servers directly to the public internet.
Do not expose your authoritative DNS servers directly to the public internet. Restrict DNS access to trusted networks to reduce risk.
Using your own DNS servers in Azure gives you centralized control and compatibility with existing infrastructure, but requires correct configuration of forwarding, recursion, and security to avoid resolution failures. When configured correctly, you get seamless name resolution across on‑premises, multiple VNets, and Azure services. Next, we walk through a practical example using the Azure Portal and two VMs (one in East US and one in West US), plus an Azure Private DNS Zone that both VNets can use. Prerequisites
  • Two VNets in separate regions (East US, West US), each with a subnet and a Linux VM.
  • Appropriate NSG rules allowing DNS traffic between VMs and DNS servers.
  • An Azure subscription with permissions to create VNets, VMs, and Private DNS Zones.
You can create a basic environment with the following PowerShell snippet. It defines variables, creates a resource group, two VNets and subnets, and a public IP for VM1. (Extend this snippet as needed to create NICs and VM resources.) 
# Variables
$resourceGroup = "rg-az700-private-dns"
$locationEUS = "eastus"
$locationWUS = "westus"
$username = "kodekloud"
$password = "@dminP@55w0rd"

# VM 1 (East US)
$vmName1 = "vm-az700-eus-01"
$vnetName1 = "vnet-az700-eus"
$subnetName1 = "subnet-az700-eus"
$ipName1 = "ip-az700-eus"
$nicName1 = "nic-az700-eus"
$addressPrefix1 = "10.10.0.0/16"
$subnetPrefix1 = "10.10.1.0/24"

# VM 2 (West US)
$vmName2 = "vm-az700-wus-01"
$vnetName2 = "vnet-az700-wus"
$subnetName2 = "subnet-az700-wus"
$ipName2 = "ip-az700-wus"
$nicName2 = "nic-az700-wus"
$addressPrefix2 = "10.20.0.0/16"
$subnetPrefix2 = "10.20.1.0/24"

# Create Resource Group
New-AzResourceGroup -Name $resourceGroup -Location $locationEUS

# Create Subnets
$subnet1 = New-AzVirtualNetworkSubnetConfig -Name $subnetName1 -AddressPrefix $subnetPrefix1
$subnet2 = New-AzVirtualNetworkSubnetConfig -Name $subnetName2 -AddressPrefix $subnetPrefix2

# Create VNETs
New-AzVirtualNetwork -Name $vnetName1 -ResourceGroupName $resourceGroup -Location $locationEUS -AddressPrefix $addressPrefix1 -Subnet $subnet1
New-AzVirtualNetwork -Name $vnetName2 -ResourceGroupName $resourceGroup -Location $locationWUS -AddressPrefix $addressPrefix2 -Subnet $subnet2

# Create Public IPs
New-AzPublicIpAddress -Name $ipName1 -ResourceGroupName $resourceGroup -Location $locationEUS -AllocationMethod Static
Creating a Private DNS Zone
  • Purpose: provide a common internal namespace (e.g., corecloudint.com or kodekloudint.com) that VMs across VNets can resolve.
  • Note: Private DNS Zones are global resources; the resource group location only stores metadata.
Create the zone in the Azure Portal (or via CLI/PowerShell) and review + create:
A screenshot of the Microsoft Azure portal on the "Create Private DNS Zone" Review + Create page showing basics like subscription (Kodekloud Labs), resource group, location, and the DNS zone name. The page shows zero record sets and virtual network links, with the Create button visible at the bottom.
Linking VNets to the Private DNS Zone (Virtual Network Link)
  • Creating the Private DNS Zone is not sufficient by itself for VMs to resolve names. You must create Virtual Network Links to associate a VNet with the Private DNS Zone.
  • When you add a Virtual Network Link you can enable auto‑registration. With auto‑registration, Azure automatically creates A records for VM hostnames in the Private DNS Zone when VMs are created in that VNet.
When adding a virtual network link, select the target VNet and enable auto‑registration if you want VM A records registered automatically:
A screenshot of the Microsoft Azure portal showing the "Add Virtual Network Link" form for a private DNS zone, with fields for Link name, Subscription (Kodekloud Labs), Virtual Network (vnet-az700-eus) and a checked "Enable auto registration" option. Buttons for "Create" and "Cancel" are visible at the bottom.
After creating a virtual network link and enabling auto‑registration, records appear in the Private DNS Zone automatically. You can also add records manually for custom entries (for example, add an A record “web” → 192.168.10.10). Viewing record sets in the Private DNS Zone:
A screenshot of the Microsoft Azure portal showing the Private DNS zone "kodekloudint.com" Recordsets page. It lists DNS record types (SOA and A) with TTL values and IP addresses (e.g., 10.10.1.4 and 192.168.10.10).
Testing name resolution from VMs
  • From a VM in an East US VNet that is linked to the private zone and has auto‑registration enabled, run nslookup to confirm the zone resolves:
Example: connect to the East US VM and resolve the web record: 
ssh kodekloud@172.174.2.101
kodekloud@vm-az700-eus-01:~$ nslookup web.kodekloudint.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   web.kodekloudint.com
Address:        192.168.10.10
If a VNet is not linked to the Private DNS Zone, lookups for that zone will return NXDOMAIN. First, you can verify VMs in the portal for observability:
A screenshot of the Microsoft Azure portal on the "Compute infrastructure | Virtual machines" page showing two listed VMs (vm-az700-eus-01 and vm-az700-wus-01) with details like location, status (Running), OS (Linux), size, and public IP addresses.
Example: West US VM failing to resolve before linking its VNet: 
ssh kodekloud@20.253.255.34
kodekloud@vm-az700-wus-01:~$ nslookup web.kodekloudint.com
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find web.kodekloudint.com: NXDOMAIN
Fix: create a Virtual Network Link for the West US VNet and enable auto‑registration. After the link exists, the West US VNet can resolve records in the Private DNS Zone. The portal will show the zone record sets (including any auto‑registered VM A records):
Screenshot of the Microsoft Azure portal showing the Private DNS zone "kodekloudint.com" Recordsets page. It lists DNS records (an SOA and A records), e.g., vm-az700-eus-01 → 10.10.1.4 and web → 192.168.10.10, with a notification about creating a virtual network link.
After linking both VNets, nslookup from the West US VM shows the East US VM’s FQDN resolved: 
kodekloud@vm-az700-wus-01:~$ nslookup vm-az700-eus-01.kodekloudint.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   vm-az700-eus-01.kodekloudint.com
Address:        10.10.1.4
Important note about connectivity
  • Name resolution and network connectivity are separate concerns. Resolving an IP address does not imply the VNets are connected.
  • To enable cross‑VNet traffic you must configure VNet peering, site‑to‑site VPN, or ExpressRoute as required.
DNS planning checklist (quick reference)
ItemRecommendation
Zone typeUse Azure Private DNS Zones for internal name resolution across VNets
VNet linkingCreate Virtual Network Links; enable auto‑registration for VM A records
Custom DNS serversUse when you need on‑prem integration or specialized resolution behaviour
SecurityAllow DNS ports (UDP/TCP 53) internally; block public access to authoritative servers
ForwardingConfigure forwarders to Azure resolver (168.63.129.16) or on‑prem as needed
Next steps and additional guidance
  • If you require cross‑VNet connectivity, configure VNet peering or VPN/ExpressRoute.
  • If using custom DNS servers, ensure they have proper records or forwarding rules, can perform recursive queries, and are secured from public access.
  • Consider a hub‑spoke DNS topology: centralize DNS (and other shared services) in a hub VNet and link spokes to the hub’s Private DNS Zone(s).
Use a hub‑spoke architecture to centralize DNS: host DNS in a hub VNet and link spokes to the Private DNS Zone(s). This reduces the number of virtual network links and centralizes name management.
Links and references This guide walked through the architecture, best practices, and a portal‑driven example of using Azure Private DNS Zones and Virtual Network Links to provide consistent, secure name resolution across multiple VNets.

Watch Video