If you would like to read the other parts in this article series please go to:
Exchange server relies heavily on DNS for internal communication with Active Directory, support to the internal clients, and also on the Public DNS which is responsible for supporting external clients mail flow from external servers located on the Internet.
Microsoft Azure is able to host Public DNS domains, and the service name is Azure DNS. Companies can take advantage of Microsoft Azure infrastructure and move their Public DNS zones. There are several advantages in using Azure instead of your regular DNS Provider, for example: same authentication that you already have in Microsoft Azure to manage DNS. All DNS queries will be done to the closest available DNS Server in the Azure infrastructure, avoid single point of failure where the service provides high availability and resilience.
Azure DNS is currently in preview, which means that is not recommended in production workloads. As soon as the service is moved to GA (General Availability) all production workloads can be moved to it. If you haven’t done so, please keep an eye on MSExchange.org Blogs, as soon as the service becomes available, we will blog about it.
In the current Azure DNS Preview, the service supports the most common record types including A, AAAA, CNAME, MX, NS, SOA, SRV and TXT. From the Exchange/Skype for Business Administrator perspective, the service is able to provide all the resources required to support Exchange and Skype for Business Services.
When managing Public DNS, the exchange administrator has to forward a series of entries to allow clients to connect to the messaging system, external SMTP servers to send messages and regular protection (SPF, DKIM and etc.).
The goal of this article series is to build muscle memory to manage DNS using Azure DNS, and we will use a zone called infralab.org. We will use a simple scenario (Figure 01) with the basic DNS records that are required to get that domain going. Throughout this article, we will be using bogus IP addresses (10.10.10.10, 188.8.131.52 and so forth) and the goal is to manage the DNS records and not the data itself, so don’t worry about the IPs being added but focus on the process to get them there.
Moving your domain to Microsoft Azure…
Microsoft Azure has two deployment models available for Cloud Administrators: Service Management Model also known as Classic, and Resource Manager Deployment (ARM). Azure DNS only supports Resource Manager Deployment, and for new services like the Azure DNS Preview, usually we have the PowerShell interface first and afterwards the feature shows up on the Azure Portal.
Before starting our journey through PowerShell, we need to install the Microsoft Azure PowerShell, and these are the recommend steps to complete such task.
- Open https://azure.microsoft.com, go to the bottom and click on Downloads
- In the new page, go to the Command-line tools section and click on Windows Install located on the PowerShell column
- Download and run the application. The following page will be displayed (Figure 02), click on Install, and follow the installation process using default settings. The entire process may take a few minutes
In order to connect to Microsoft Azure and manage Azure DNS, open a PowerShell session as administrator, and run the Login-AzureRMAccount cmdlet. In the new window enter the credentials to access the service/subscription, as shown in Figure 03.
Azure DNS is supported on the Resource Manager Deployment model, and for that reason all cmdlets will have the prefix AzureRM for the noun portion of the cmdlet.
Now that we are connected with Microsoft Azure, our first step is to create a Resource Group where we will place all DNS zones for the Azure DNS service. During the creation of a Resource Group we can define the name and the Azure location (Figure 04).
New-AzureRMResourceGroup –Name RG-DNS –Location “East US”
There are many benefits in having a resource group just for DNS. We can use RBAC (Role Based Access Control) at that level billing reports just for the DNS, and monitor/auditing at the Resource Group level. However, the Resource Group is just a container for the future DNS zones that we will be adding to the Azure DNS.
In order to create a new zone, the following cmdlet can be used, as shown in Figure 05. Afterwards, we list all the existent zones in the newly created resource group.
$NewZone = New-AzureRMDNSZone –Name Infralab.org –ResourceGroupName RG-DNS
Get-AzureRMDNSZone –ResourceGroupName RG-DNS | fl
After creating the first zone in Azure DNS, we need to identify the servers that will host this new zone in Microsoft Azure infrastructure, and those servers are assigned during the zone creation. The information located on the Records line (Figure 06) is the one that we need to have in order to perform a DNS Delegation (move the zone from your current provider to Azure DNS)..
Get-AzureRMDNSRecordSet –ZoneName infralab.org –ResourceGroupName RG-DNS –RecordType NS
At this point in the game, we have a Resource Group created in Microsoft Azure, and the first DNS Zone. Our next step is to go to the DNS registrar and change the Name Servers to the servers that are hosting our new zone in Azure DNS.
In this current provider, we have the option to edit the Name Servers and we will be adding all the names provided by Azure DNS, as shown in Figure 07. Click on Save and wait a few hours for the propagation of that information. Basically from now on all the queries to that public domain will go to Azure DNS which means that Azure DNS is in production for that specific zone.
After performing the DNS change, we can use nslookup or any page that performs DNS queries on the internet to find out if the new settings are in place. Using nslookup we can run the following commands (Figure 08) listed below which will use Google DNS Resolvers to check the information.
After this point, all changes that we perform on Azure DNS will be available for that domain. In the next article of this series we will be start managing DNS records using PowerShell.
Import and Exporting DNS Zones…
In this article we are creating a new zone from scratch, however we may want to move existent production DNS zones into Azure DNS. There are a couple of ways of doing that, as follows:
- Manual process, just create a copy of your current zone and replicate the information in Azure DNS. That process should be done before the DNS delegation
- Import process, in this case we can use Azure CLI (Command Line Interface) which is available for Windows, Linux and Mac and it allows to play with import/export process of a zone (although some DNS Registrar do not use the same format and we need to change the file before importing)
Since the Manual process requires just the ability to manage DNS records and we will cover that in full details in the second article of this series, but for now we will focus on the Import/Export process using Azure CLI.
In order to install the Azure CLI, we will be opening the already installed Microsoft Web Platform Installer. We will be adding Microsoft Azure Cross-platform Command Line Tools and after that click on Install to start the installation process, use default values to complete the installation.
After installation, open command prompt and run the following commands to perform the authentication and change the deployment model to arm.
azure config mode arm
Using your current DNS provider, export the zone to a local file (most of the DNS providers do that, if not open a ticket with them). In our example we will save the zone on the C:\Temp\infralab.org.zone file. In order to import the file, run the following command, as shown in Figure 11.
RG-DNS is the Resource Group name, and test.ca is the zone name in Azure DNS (we used a different zone just for this import process).
Azure network dns zone import rg-dns test.ca C:\Temp\infralab.org.zone
In some cases, we may want to export the zone for a backup purposes, in that case the following command can be used (Figure 12), and the exported file is shown in the same image.
Azure network dns zone export rg-dns infralab.org C:\Temp\Azure-infralab.org
In this first article of our series about Azure DNS we covered the process of moving a Public Domain to Microsoft Azure using PowerShell. Keep in mind that a DNS zone created in Azure DNS is not complete until we configure the DNS records (DNS Delegation) pointing out to Microsoft Azure servers, in that sense, we can create any zone in our Azure DNS subscription but it will only become valid for the external world when the DNS delegation is complete.
In our next article, we will be covering the process to manage Azure DNS using PowerShell which will include managing records A, MX, TXT, and so forth.
If you would like to read the other parts in this article series please go to: