Configuring Azure Private DNS

The Domain Name System (DNS) is pretty much at the heart of all systems. If DNS does not work, things almost always stop working. This of course also applies to the cloud and systems deployed to it. If you would like to learn more about the basics of DNS, read up on it on one of the largest public DNS provider's websites. People reference a DNS zone as "private DNS" if this zone is not accessible from the internet.

Author
Recent Posts

David O´Brien

David has been a consultant for over 10 years and reinvented himself a couple of times, always staying up to date with the latest in technology around automation and the cloud. He is a multi-year Microsoft MVP for Azure, a cloud architect at XIRUS in Australia, a regular speaker at conferences, and IT trainer.

Latest posts by David O´Brien (see all)

Deploying an AWS EC2 Windows VM via PowerShell - Mon, Dec 16 2019
Creating an AWS VPC with PowerShell - Fri, Nov 15 2019
Configuring Azure Private DNS - Mon, Nov 11 2019

Azure Private DNS

Azure Private DNS was released into general availability on October 8 and is backed by the general Azure DNS service-level agreement (SLA). By default, Azure virtual machines (VMs) receive an internal DNS name out of the box from the domain internal.cloudapp.net. For a lot of services and customers this can be enough, but others quickly find themselves wanting name resolution across virtual networks (VNets) for example. One scenario is where previously custom DNS services had to be deployed, like Windows DNS or Linux BIND servers. These are expensive solutions to a problem the platform should be able to solve for us with some API calls.

Deploying a private DNS zone

Instead of using the abovementioned internal.cloudapp.net domain, we want our VMs to register on the private DNS zone xirus.com.au. We will be following these steps to accomplish this:

create an Azure resource group
deploy an Azure VNet
deploy an Azure private DNS zone
deploy two Azure VMs
verify DNS resolution

To make this process simpler to follow and more realistic, we will use the Azure PowerShell module for our deployments. To create the Azure resource group "rg-dns" in our subscription in the Australia Southeast region, we will execute this cmdlet here:

New-AzResourceGroup -Name rg-dns -Location "australiasoutheast"

Creating an Azure Resource Group

Into this new resource group, we will next deploy an Azure VNet. For this, you can follow the instructions over on the Azure VNet article. Just make sure you provide the correct values. For simplicity's sake, here are the cmdlets.

New-AzVirtualNetwork -Name vnet -AddressPrefix 192.168.0.0/16  ResourceGroupName rg-dns -Location "australiasoutheast"
$vnet = Get-AzVirtualNetwork -Name vnet -ResourceGroupName rg-dns
$subnetConfig = New-AzVirtualNetworkSubnetConfig -Name servers -AddressPrefix 192.168.1.0/29
$vnet.Subnets.Add($subnetConfig)
Set-AzVirtualNetwork -VirtualNetwork $vnet

Note that this will create a VNet with one subnet (name: servers) with exactly three IP addresses available in the subnet. Now we can create the private DNS zone. Azure ships the PowerShell module to create the zone as a standalone module right now, which means you need to install it separately.

Install-Module -Name Az.PrivateDns

Once this completes, we can use the following cmdlet to create the zone:

$zone = New-AzPrivateDnsZone -Name private.xirus.com.au -ResourceGroupName rg-dns

DNS zones are global resources, so there is no region attached to the resource.

Azure private DNS zone

For VMs to be able to register in this zone, the VNet needs to be "linked" to the zone as a registration network. This means that for any VMs deployed into this network, a DNS record will be created and managed over time by the DNS zone.

$vnetLink = New-AzPrivateDnsVirtualNetworkLink -ZoneName private.xirus.com.au -ResourceGroupName rg-dns -Name "vnetLink" -VirtualNetworkId $vnet.id  EnableRegistration

We can then browse to the DNS zone in the Azure portal and check that the VNet is linked to the DNS zone.

Azure DNS VNet link

Testing Azure Private DNS

To test our new private DNS zone, we need to deploy VMs. Use the following PowerShell cmdlets to deploy two small Linux VMs for testing purposes. Be aware though that this will very likely incur costs on your side.

New-AzVm -ResourceGroupName rg-dns -VirtualNetworkName $vnet.name -SubnetName servers -Name test01 -Image UbuntuLTS -Location australiasoutheast -Size Standard_B2s
New-AzVm -ResourceGroupName rg-dns -VirtualNetworkName $vnet.name -SubnetName servers -Name test02 -Image UbuntuLTS -Location australiasoutheast -Size Standard_B2s

This will deploy two small Linux VMs. Both will have a public IP address attached to them so that we can SSH to them for our final test. PowerShell will also ask you to input an admin user name and password to create on each VM. The deployments will only take one or two minutes for each VM.

Azure VM information

After completing this, we will first check if the resources have actually registered themselves in our private DNS zone. We will use Get-AzPrivateDnsRecordSet -ZoneName private.xirus.com.au -ResourceGroupName rg-dns for that.

Get DNS records via PowerShell

We can see the VM names and that the records were auto-registered. That's a good start. Now let's test if the names actually resolve by connecting to the test01 VM's public DNS name and trying to resolve the test02.private.xirus.com.au name. For that, we use test01's public DNS name as in the "Azure VM information" picture above and SSH to it using our admin user name, i.e., ssh adobrien@test01‑ed9154.australiasoutheast.cloudapp.azure.com. Now that we are connected, we can use nslookup test02.private.xirus.com.au to check what the name will resolve to.

Test Azure private DNS zone

As expected, the name resolves to the internal IP. We can also still use the default domain name of test02.internal.cloudapp.net, and it will resolve to the same IP.

Advanced private DNS scenarios

For more advanced scenarios, I recommend reading the official Microsoft documentation. Do not forget to clean up after you test this new feature by deleting the Azure resource group we deployed. This will make sure you do not pay for resources you do not require any longer.