Azure Private DNS lets you resolve custom domain names inside virtual networks without publishing those records to the public internet. A private zone can be linked to one or more virtual networks, including networks in different regions.
Understand the design
A private DNS zone stores records for a private domain. Resources usually need a virtual network link to resolve records from that zone. You can optionally enable auto-registration so Azure creates and updates VM records in the linked network. [1]
Do not use .local as the private zone name. Microsoft notes that not all operating systems support that domain. Choose a domain that fits your internal naming plan and does not create avoidable conflicts with public DNS. [1]
1. Create the private DNS zone
- In the Azure portal, search for Private DNS zones.
- Select Private DNS zone under Marketplace.
- Choose an existing resource group or create one.
- Enter the private zone name, such as
private.example.internal. - Choose the resource group location if required.
- Select Review + Create, then select Create.
Azure stores private zone data as a global resource. The zone is not dependent on a single virtual network or region, so it can be linked to multiple virtual networks. [2]
2. Prepare or select a virtual network
Use an existing virtual network or create one for testing. Ensure the network address space and subnets fit the rest of your Azure design. Keep test resources in a dedicated resource group so they can be removed safely later.
3. Link the virtual network
- Open the private DNS zone.
- Under DNS Management, select Virtual Network Links.
- Select + Add.
- Enter a link name.
- Select the subscription and virtual network.
- Optionally select Enable auto registration.
- Select Create.
Linked virtual networks can resolve records published in the zone. Auto-registration causes Azure to maintain VM A records when VMs are created, their private IP addresses change, or they are deleted. [2]
4. Add a private DNS record
- In the zone, open Recordsets.
- Select + Add.
- Enter a record name such as
db. - Choose the record type, such as A.
- Enter the private IP address.
- Save the record.
The resulting fully qualified name combines the record name and zone, such as db.private.example.internal. Use record types that match the service discovery design.
5. Test name resolution
Test from a resource inside the linked virtual network. Resolve the VM’s auto-registered name or the manual record you created. Microsoft’s quickstart uses a VM and a ping command to verify that the private name resolves to the expected private IP address. [2]
If resolution fails, check the virtual network link, the record name, the resource’s DNS configuration, and whether the test resource is actually in the linked network.
6. Link additional networks carefully
A single private zone can be linked to multiple virtual networks. This is useful for shared service discovery across regions, but it also broadens which networks can resolve the zone. Review the records and naming conventions before linking production and development networks to the same zone.
Common mistakes
- Creating the zone but forgetting the virtual network link.
- Using
.localas the private domain. - Enabling auto-registration without deciding which VM records should be published.
- Testing from a network that is not linked to the zone.
- Using overlapping private zone names without a clear split-horizon DNS design.


