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.

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)

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:

Creating an Azure Resource Group

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.

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.

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

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

Azure private DNS zone

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.

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

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.

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

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

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

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.

Are you an IT pro? Apply for membership!

Your question was not answered? Ask in the forum!

1+

Users who have LIKED this post:

  • avatar
Share
0 Comments

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2019

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account