Skip to main content
Configuring DNS inside an Azure virtual network (VNet) is essential for enterprise and hybrid environments that require custom name resolution. This guide shows recommended architectures, Azure Private DNS zone usage, and step‑by‑step examples to get a simple test environment running. At a high level, the diagram below illustrates two Azure VNets (VNet1 and VNet2), each hosting VMs and a DNS server, plus an on‑premises DNS. DNS queries from on‑premises and between VNets can be forwarded to the appropriate DNS server or to Azure’s platform resolver at 168.63.129.16 when required.
The image depicts a network diagram for configuring DNS settings inside a virtual network (VNet), illustrating DNS queries flow between on-premises, DNS servers, and virtual machines across two VNets. It includes recommendations for secure DNS setup, such as enabling recursive resolution and securing the DNS server from the internet.
Key takeaways from the architecture diagram:
  • Each VNet can host its own DNS server (for example 10.1.0.4 in VNet1 and 10.2.0.4 in VNet2). VMs inside that VNet point to the local DNS server for resolution.
  • If a DNS server cannot resolve a name locally, it forwards queries across peering/site‑to‑site/ExpressRoute links or to Azure’s platform DNS resolver at 168.63.129.16 if configured.
  • Ensure appropriate firewall/NSG rules for DNS (UDP/TCP port 53) and that recursive resolution or forwarders are configured.
  • Do not expose internal DNS servers directly to the public internet; always place them behind network controls.
Design your DNS for recursive resolution using forwarders or direct recursion. Use hub‑and‑spoke or centralized DNS patterns: place DNS servers in a hub VNet and have spokes forward queries (via peering or conditional forwarders). Link the Private DNS zone to the hub instead of linking every spoke directly.
Essentials for a working custom DNS deployment
  • DNS servers must have records or forwarders for all relevant zones (private zones, conditional forwarders).
  • Allow UDP/TCP port 53 between clients, DNS servers, and across networks where resolution must traverse.
  • Secure internal DNS servers with NSGs, firewalls, or private endpoints — do not publish them to the public internet.
DNS traffic and port summary:
Do not publish internal DNS servers directly to the internet. Restrict access using NSGs, firewalls, or private connectivity and use Azure platform DNS (168.63.129.16) where appropriate.
Walkthrough: create a simple test environment This walkthrough creates a minimal foundation: resource group, two VNets with subnets, and an example public IP. Extend this to add NICs and VMs as needed. PowerShell example to create resource group, two VNets and subnets:
Create a Private DNS zone
  • In the Azure portal go to Private DNS zones and create a new zone (example: kodekloudint.com) in a resource group such as RG-AZ700-PRIV-DNS-01. Private DNS zones are global resources; the resource group location stores metadata only.
The image shows the "Review + Create" page for setting up a Private DNS Zone on the Microsoft Azure portal. It includes details like subscription, resource group, and DNS zone information.
Linking VNets to the Private DNS zone By default a private DNS zone is not linked to any virtual networks. To make a VNet resolve names in that zone, add a virtual network link.
  • A Virtual Network Link tells Azure that the zone (for example kodekloudint.com) will be used for name resolution by that VNet.
  • Enable “Auto registration” so that new VMs in the linked VNet automatically register host A records into the private zone.
In the portal, add a Virtual Network Link, select the target VNet, and enable auto‑registration as required.
The image shows the Microsoft Azure portal interface for adding a virtual network link, with options to configure virtual network details and enable auto registration.
After you create a virtual network link, the linked VNet can resolve records in the private DNS zone. Initially a private zone includes SOA and NS records only; with auto‑registration enabled, VM host A records appear automatically.
The image shows a Microsoft Azure portal displaying the "Virtual Network Links" section for the domain "kodekloudint.com," with a notification about creating a virtual network link.
Add manual record sets (optional) You can manually add records to a Private DNS zone — for example, an A record web.kodekloudint.com pointing to 192.168.10.10.
The image shows a Microsoft Azure portal interface, specifically the "Recordsets" section for a DNS zone, where a new A record is being added with an IP address of 192.168.10.10.
Over time you will see record types such as SOA, NS, manually created A records, and auto‑registered VM records listed in the zone.
The image shows the Microsoft Azure portal interface displaying DNS records for a private DNS zone, where various record sets are listed with their types, TTL, and values.
Testing from VMs
  • If a VM is in a VNet linked to the private DNS zone, nslookup on the VM should return records from that zone.
  • If a VM is in a VNet that is not linked, lookups for the private names will return NXDOMAIN.
Example: SSH to the East US VM (which has its VNet linked) and resolve the manually created web.kodekloudint.com record:
From the West US VM (before linking its VNet), the same lookup returns NXDOMAIN:
To fix that, add a Virtual Network Link for the West US VNet (enable auto‑registration if desired). After linking, the West US VM can resolve the East US VM’s auto‑registered record:
The image shows a Microsoft Azure portal interface displaying a private DNS zone overview for "kodeloudint.com" with details like resource groups, subscriptions, and virtual network links. A notification indicates the successful creation of a virtual network link.
Example after linking:
Important: name resolution does not guarantee reachability. If VNets are isolated (no peering, no VPN/ExpressRoute), DNS will resolve names but network traffic will not flow. To enable traffic, establish VNet peering or appropriate private connectivity. Summary and recommended practices
  • Use Azure Private DNS zones for private name resolution and link VNets with Virtual Network Links.
  • Enable auto‑registration for dynamic VM record creation in linked VNets.
  • For complex environments, use hub‑and‑spoke DNS placement and conditional forwarders to on‑premises DNS to avoid linking every spoke VNet to a zone.
  • Secure your DNS servers and network access; do not expose internal DNS servers to the internet.
  • Combine DNS configuration with proper network connectivity (peering, VPN, ExpressRoute) to provide both resolution and reachability.
Links and references For further examples on conditional forwarders and DNS forwarding between Azure and on‑premises, see the Azure DNS documentation and design guidance above.

Watch Video