Private DNS Zones

• What an Azure Private DNS zone is and how it differs from network connectivity
• How to create a Private DNS zone in the Azure portal
• How to link virtual networks and enable auto-registration
• How to validate name resolution from Linux VMs (nslookup)
• CLI commands to create a quick test VM

• Enable resolution of hostnames across VNets without exposing records to the public internet
• Centralize private DNS records (e.g., *.internal.company.com) for multiple VNets
• Integrates with Azure services such as Azure Private Link

• VNet A and VNet B are separate VNets with their own address spaces and internal DNS domains.
• By default, VMs in the same VNet can resolve each other’s hostnames (for example, vm-01 → vm-02).
• To resolve hostnames across VNets (for example, vm-01 → vm-06), create a Private DNS zone (for example, kodekloud-int.com) and add virtual network links to that zone.
• Virtual network links make a VNet aware of a Private DNS zone. Optionally enable auto-registration so Azure automatically creates A records for VMs in the linked VNet.
• Important: Private DNS zones only provide DNS name resolution — they do not provide network connectivity. To enable traffic flow between VNets, configure VNet peering or VPN/gateway connectivity.

​

Portal: create a Private DNS zone

1. In the Azure portal, search for Private DNS zones and click Create.
2. Enter the DNS zone name (e.g., kodekloud-int.com) and select a subscription and resource group.
3. Create the zone. Note that Private DNS zones are global resources — you do not choose a region.

​

Reusing existing VMs for the demo

​

Inspect the Linux VM DNS configuration and test resolution

1. SSH to a workload VM and inspect resolver configuration (Ubuntu often uses systemd-resolved with a local stub resolver at 127.0.0.53).

ssh kodekloud@172.191.131.27
# enter password when prompted

kodekloud@workload-a-vm-1:~$ cat /etc/resolv.conf
# Example output (systemd-resolved stub resolver)
nameserver 127.0.0.53
options edns0

kodekloud@workload-a-vm-1:~$ nslookup workload-a-vm-2
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   workload-a-vm-2.hnv5wu0qr4nejnur5qdmnwjryh.bx.internal.cloudapp.net
Address: 192.168.1.5

kodekloud@workload-a-vm-1:~$ nslookup dns-demo-vm
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find dns-demo-vm: SERVFAIL

​

Create a temporary VM for testing (Azure CLI)

az account set --subscription '2cda1881-8c1e-4c15-be23-a00a708afaf3'

az group create -n dns-demo -l eastus

{
  "id": "/subscriptions/2cda1881-8c1e-4c15-be23-a00a708afaf3/resourceGroups/dns-demo",
  "location": "eastus",
  "name": "dns-demo",
  "properties": {
    "provisioningState": "Succeeded"
  }
}

az vm create -g dns-demo -n dns-demo-vm --image Ubuntu2204 --admin-username kodekloud --admin-password 'VMP@55word12'

{
  "id": "/subscriptions/.../resourceGroups/dns-demo/providers/Microsoft.Compute/virtualMachines/dns-demo-vm",
  "powerState": "VM running",
  "privateIpAddress": "10.0.0.4",
  "publicIpAddress": "13.127.46.171",
  "resourceGroup": "dns-demo"
}

​

Create virtual network links for the Private DNS zone

1. Open the Private DNS zone (e.g., kodekloud-int.com).
2. Click Virtual network links → Add.
3. Provide a link name, select the VNet to link, and enable Auto registration if desired.
4. Repeat for each VNet to be able to resolve names in the zone.

• The link name is for administration only.
• Auto-registration creates A records for VMs in the linked VNet. If auto-registration is disabled, create A records manually or configure DNS forwarding.

​

Validate cross-VNet resolution

kodekloud@workload-a-vm-1:~$ nslookup dns-demo-vm
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find dns-demo-vm: SERVFAIL

kodekloud@workload-a-vm-1:~$ nslookup dns-demo-vm.kodekloud-int.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   dns-demo-vm.kodekloud-int.com
Address: 10.0.0.4

• Verify the Private DNS zone shows the expected A records (Private DNS zone → Overview / Records).
• Confirm VNets are linked and show a successful link status in the Private DNS zone blade.
• Ensure VMs use Azure DNS or configure DNS forwarding to Azure.
• Remember: DNS resolution succeeds only if the zone/records exist and the querying VM can reach the DNS service (network connectivity still required separately).

​

Quick reference: Private DNS zone vs network connectivity

​

Recap

• Private DNS zones enable private DNS resolution across VNets when you create virtual network links.
• Enable auto-registration to automatically populate A records for eligible VMs (Azure DNS + VM agent).
• Private DNS zones do not create network links — use VNet peering or VPN/gateway solutions to enable traffic.
• Common usage includes service isolation, internal-only hostnames, and Azure Private Link integrations.

​

Links and references

• Azure Private DNS overview
• Virtual network peering overview
• Azure VPN Gateway overview
• Azure Private Link overview