It doesn’t matter how secure your Internet application’s inner workings are or the security layers you have designed to protect your infrastructure. Yes, you can have multifactor authentication to connect to Microsoft Azure. But if the DNS that your clients rely on to get to your application is from a DNS registrar that protects it with just a single password, you’re in potential trouble. In this article, we are going over the process of moving your public domain from a DNS registrar to Microsoft Azure and use infrastructure-as-code (IAC) to add an extra layer of security to the entire process.
Covering the basics
The first step is to create a resource group to store all our future DNS zones. We can have as many as we want in a single resource group. In this article, we are going to use a single resource group.
If you want to manage a zone within the application, you may want to place your application resource group’s zone.
Here’s how to do it. Logged in to the Azure Portal, click or search resource groups, click on Add, select a subscription, define a name and click on Review+Create.
This step has to be done after the zone is created. Make sure that you copy the name servers from your zone because they do change among zones. They are the name servers responsible for the current zone, and we need to configure that in our DNS registrar sites.
As soon as we have the DNS zone created in Azure (hold on, we are going over the creation in a bit), we need to go where our DNS zone is registered and change the name server to use the values that we gathered from Azure Portal (name servers).
One last piece of advice, make sure that you secure access to your DNS registrar very secure, using a strong password, using multifactor authentication, and monitoring any changes to your public DNS zones.
Managing DNS with infrastructure-as-code
The first step is to understand what we need to provide to our ARM template to build and maintain our public DNS. We can tackle the management of the domain in several ways. The most common is creating a set of files (template and parameters) per domain that we want to manage. A second option is to keep all domains in the same file.
In this article, we will focus on the organization and a set of files for each domain. In the diagram below is how we are going to set it up to our domain pconsolidated.ca.
The second piece that we need to define is what kind of information we need to manage our domain zone. We will configure the domain zone FQDN in the domainZone parameter, and we will create two arrays for each type of DNS entries (we will start with CNAME records).
Both arrays (one per type of record) must be aligned. The name convention that we will use is record-<Type>-name and record-<type>-address. We need to add the values in the proper order in both locations.
For example: add www in the record-A-name array and the Public IP (something like 200.248.0.0) in the record-a-Address. When we have multiples, we need to ensure that they follow the same order in both arrays.
The result in the parameters area will be something similar to this code listed below.
After having the template created, we need to build the parameters file. We are going to create one called pconsolidate.ca.json and provide the values. The expected results at the end of this article are the creation of the following DNS records:
- pconsolidated.ca pointing to app1.azurefd.net (CNAME)
- pconsolidated.ca pointing to app2.azurefd.net (CNAME)
- pconsolidated.ca pointing out to 10.10.10.10 (A Record)
- pconsolidated.ca pointing out to 20.20.20.20 (A Record)
The process to create a zone in an ARM template is just a few lines long. The only thing that we need is the fully qualified domain name (FQDN) of the domain that we are planning to create. The entire code to create the zone is depicted in the image below.
The process to create records (A or CNAMES) are similar, but they require their own piece of code. In the example below, we are creating all our A records. There are three important key items on that code that we need to understand.
Item 1 is where we define the name. We will get the FQDN of the domain and the name of the record that we will add. Since that is the first iteration (hold on, we will get there in two paragraphs), the first entry based on our parameters file will be www.pconsolidated.ca.
The value of that new A record is defined in Item 2. Since that is still the first iteration, we will get the first value of the record-A-address array, which is 10.10.10.10.
Item 3 is the brains of the operation. That is the copy function in the ARM Template. Basically, we will repeat the code in the brackets (the very first and the last brackets) for the number of items that we have in our array (in our case, two iterations).
Securing Azure DNS with IAC: More to do
In this article, we covered the basic design of our ARM template to build the public DNS zones in Microsoft Azure and the steps required to configure the DNS registrar to leverage Azure DNS. In our next article in this series, we will put our code to the test by creating a release pipeline and check some of the security features that we can introduce. We are going to cover the process to create several zones as well in this same framework.
Featured image: Shutterstock
