DNS and routing in Microsoft Azure || Microsoft Azure Guide Series by Mohit Jaisal
Azure DNS allows us to host Domain Name System (DNS) domains in Azure. When using Azure DNS, we use Microsoft infrastructure for the name resolution, which results in fast and reliable DNS queries. Azure DNS infrastructure uses a vast number of servers to provide great reliability and availability of service. Using Anycast networking, each DNS query is answered by the closest available DNS server to provide a quick reply.
I will cover the following recipes in this Blog:
[1/11] Creating an Azure DNS zone
[2/11] Creating an Azure Private DNS zone
[3/11] Integrating a virtual network with a private DNS zone
[4/11] Creating a new record set in Azure DNS
[5/11] Creating a route table
[6/11] Changing a route table
[7/11] Associating a route table with a subnet
[8/11] Dissociating a route table from a subnet
[9/11] Creating a new route
[10/11] Changing a route
[11/11] Deleting a route
Getting ready
Before you start, open your browser and go to the Azure portal via https://portal.azure.com
[1/11] Creating an Azure DNS zone
To start using Azure DNS, we must first create a DNS zone. A DNS zone holds a DNS record for a specific domain, and it can hold records for a single domain at a time.A DNS zone will hold DNS records for this domain and possible subdomains. DNS name servers are set up to reply to any query on a registered domain and point to a destination.
How to do it…
In order to create a new Azure DNS zone with the Azure portal, we must follow these steps:
- In the Azure portal, select Create a resource and choose DNS Zone under networking services (or search for DNS Zone in the search bar).
- In the new pane, we must enter information for the Subscription, Resource group, and Name fields. If we select an existing resource group, the region will automatically be the same as the one for the resource group selected. Optionally, we can mark this zone if the child of an existing zone is hosted in Azure DNS. The name must be a Fully Qualified Domain Name (FQDN):
How it works…
A DNS zone is required to start using Azure DNS. A new DNS zone is required for each domain we want to host with Azure DNS, as a single DNS zone can hold information for a single domain. After we create a DNS zone, we can add records, recordsets, and route tables to a domain hosted with Azure DNS. Using these, we can route traffic and define destinations using an FQDN for Azure resources (and other resources as well).
Let’s move on to the next recipe to learn how to create a private DNS zone.
[2/11] Creating an Azure Private DNS zone
An Azure Private DNS zone operates very similarly to a DNS zone. However, instead of operating on public records, it operates inside a virtual network. It is used to resolve custom names and domains inside your Azure virtual network.
How to do it…
In order to create a new Azure DNS zone with the Azure portal, we must follow these steps:
- In the Azure portal, select Create a resource and choose Private DNS Zone under Networking services (or search for Private DNS Zone in the search bar).
- In the new pane, we must enter information for the Subscription, Resource group, and Name fields. If we select an existing resource group, the region will automatically be the same as the one for the resource group selected. The name must be an FQDN:
How it works…
When a virtual network is created, a default DNS zone is provided. The default DNS zone uses Azure-provided names, and we must use a private DNS zone to use custom names. A private DNS zone is also required for name resolution across virtual networks, as default DNS doesn’t support such an option.
Let’s move on to the next recipe to learn how to integrate a virtual network with a private DNS zone.
[3/11] Integrating a virtual network with a private DNS zone
When a private DNS zone is created, it is a standalone service that doesn’t do much on its own. We must integrate it with a virtual network in order to start using it. Once integrated, it will provide DNS inside the virtual network.
How to do it…
In order to add a new record to the DNS zone, we must use the following steps:
- In the Azure portal, locate Private DNS Zone.
- In Private DNS Zone, select Virtual network links and click Add:
3. In the new pane, fill in Link name, then select values for the Subscription and Virtual network fields (only virtual networks in the selected subscription will be available). Alternatively, we can provide the resource ID of our virtual network, rather than selecting options from the drop-down menu:
How it works…
Once the virtual network is linked to the private DNS zone, the zone can be used for name resolution inside the connected virtual network. For name resolution across multiple connected virtual networks, we must use a private DNS zone, as default DNS doesn’t support resolution across networks. The same applies if the network is connected to an on-premises network.
If we enable auto-registration under Configuration, newly created virtual machines will be automatically registered in the private DNS zone. Otherwise, we must add each new resource manually.
Let’s move on to the next recipe to learn how to create a new record set in Azure DNS.
[4/11] Creating a new record set in Azure DNS
When creating a DNS zone, we define what domain we’re going to hold records for. A DNS zone is created for a root domain defined with an FQDN. We can add additional subdomains and add records to hold information on other resources on the same domain.
How to do it…
In order to add a new record to the DNS zone, we must use the following steps:
1. In the Azure portal, locate DNS zone.
2. In Overview, select the option for adding a record set:
3. A new pane will open. Enter the name of the subdomain to which you want to add a record:
4. We need to select the type of record we want to add. The options are A, AAAA, CNAME, MX, NS, SRV, TXT, and PTR. The most common record type is A, so let’s select that one:
5. After we select the record type, we need to select an alias (aliases are available only for the A, AAAA, and CNAME types) and the TTL (Time-To-Live) option. Finally, we add a record destination. This depends on the record type, and in the case of record A, it’s going to be an IP address:
6. If we choose CNAME as the record type, we are not entering an IP address but an alias. When a query is made for the record, instead of an IP address, a URL is returned and the client is directed to this record:
7. Adding a single entry to our record creates a new recordset and a new record. We can add more records to the record set by adding additional IP addresses (in this case).
How it works…
A DNS record set holds information on the subdomain in the domain hosted with the DNS zone. In this case, the domain would be toroman.cloud , and the subdomain would be tested. This forms an FQDN, demo.toroman.cloud , and the record points this domain to the IP address we defined. The recordset can hold multiple records for a single subdomain, usually used for redundancy and availability.
Using CNAME and/or an alias can be done with Azure Traffic Manager. In this way, custom domain names can be used for name resolution, instead of the default names provided by Azure.
Let’s move on to the next recipe to learn how to create a route table.
[5/11] Creating a route table
Azure routes network traffic in subnets by default. However, in some cases, we want to use custom traffic routes to define where and how traffic flows. In such cases, we use route tables. A route table defines the next hop for our traffic and determines where the network traffic needs to go.
How to do it…
In order to add a new record to the DNS zone, we must use the following steps:
1. In the Azure portal, select Create a resource and choose Route Table under Networking services (or search for route table in the search bar).
2. In the new pane, we need to select options for Subscription, Resource group, and Region, and provide the name of the route table. Optionally, we can define whether we want to allow gateway route propagation (which is enabled by default):
How it works…
Network routing in Azure Virtual Network is done automatically, but we can use custom routing with route tables. Route tables use rules and subnet associations to define traffic flow in Virtual Network. When a new route table is created, no configuration is created — only an empty resource. After the resource is created, we need to define rules and subnets in order to use a route table for the traffic flow. We will show in the coming recipes in this chapter how we create and apply rules in route tables.
[6/11] Changing a route table
As mentioned in the previous recipe, creating a new route table will result in an emptyresource. Once a resource is created, we can change the settings as needed. Before we configure the routes and subnets associated with the route table, the only setting we can change is the Border Gateway Protocol (BGP) route propagation. We may change other settings after creation as well.
How to do it…
In order to change a route table, we must do the following:
1. In the Azure portal, locate Route table.
2. Under Settings, we may change the Propagate gateway routes settings in the Configuration pane at any time:
How it works…
Under the settings of the route table, we can disable or enable gateway route propagation at any time. This option, if disabled, prevents on-premises routes from being propagated via BGP to the network interfaces in a virtual network subnet. Under the settings, we can create, delete, or change routes and subnets. These options will be addressed in the coming recipes in this chapter.
Let’s move on to the next recipe, where you will learn how to associate a route table with a subnet.
[7/11] Associating a route table with a subnet
When a route table is created, it doesn’t do anything until it’s properly configured. There are two things we need to address: which resources are affected, and how. To define which resources are affected, we must make an association between a subnet and a route table.
How to do it…
In order to associate a subnet with a route table, we must do the following:
1. In the Azure portal, locate the Route table.
2. Under Settings, select the Subnets option. In the Subnets pane, select the Associate option to create a new association:
3. A new pane will open. There are two options available — selecting a virtual network and choosing a subnet that we want to associate the route table with. First, wemust select Virtual network. Selecting this option will list all the available virtual networks. Select the one you want to associate from this list:
4. After a virtual network is selected, we can proceed to select a subnet. The Subnet option will list all the subnets from the virtual network we selected in the previous step. Choose the subnet you want to associate from this list:
5. After both options are selected, we may proceed to create an association:
6. After a subnet has been associated, it will appear in a list of subnets under the route table:
How it works…
The route table, to be effective, must have two parts defined: the what and the how.
We define what will be affected by the route table with a subnet association. This is only one part of the configuration, as just associating a subnet to a route table will do nothing. We must create rules that will apply to this association. We’ll explain the rules in the following recipes in this chapter.
Let’s move on to a new recipe and learn how to dissociate a route table from a subnet.
[8/11] Dissociating a route table from a subnet
After we create an association and rules, those rules will apply to all resources on the associated subnet. If we want rules to no longer apply to a specific subnet, we can remove the association.
How to do it…
In order to remove the association between the subnet and the route table, we must do the following:
1. In the Azure portal, locate Route table.
2. Under Settings, select the Subnets option, and select the subnet you want to remove:
3. The subnet configuration pane will open. Select the Route table option. Note that this actually opens a subnet configuration. It’s a common mistake to confuse this pane with the association and to choose the Delete option. This will not only remove the association but also remove the subnet altogether:
4. The Azure portal will show a list of the available route tables for a specific subnet. Choose None:
5. After selecting None, click the Save button to apply the new settings. The route table association is removed from the subnet:
How it works…
At some point, we may have created rules in a route table that apply to multiple subnets. If we no longer want to apply one or more rules to a specific subnet, we can remove the association. Once the association is removed, the rules will no longer apply to the subnet. All rules will apply to all the associated subnets. If we need to make a single rule no longer apply to a specific subnet, we must remove the association.
In this recipe, we learned how to dissociate a route table.
Let’s move on to the next recipe and learn how to create a new route.
[9/11] Creating a new route
After we create a route table and the associated subnets, there is still a piece missing. We defined the route table that will be affected with subnet association, but we’re missing the part that defines how it will be affected. We define how associated subnets are affected using rules called routes. Routes define traffic routes, stating where specific traffic needs to go. If the default route for specific traffic is the internet, we can change this and reroute the traffic to a specific IP or subnet.
How to do it…
In order to create a new route, we must do the following:
1. In the Azure portal, locate Route table.
2. In the Route table pane, under Settings, select Routes. Select Add to add a new route:
3. In the new pane, we need to define values for the Route name and Address prefix (in CIDR format) fields for the destination IP address range and select an option for Next hop type. The options for this include Virtual network gateway, Virtual network, Internet, Virtual appliance, and None:
4. The last option, Next hop address, is active only when a virtual appliance is used. In that case, we need to provide the virtual appliance IP address in this field, and all traffic will go through the virtual appliance. Let’s choose Internet and provide a public IP address in the Address prefix field (the Address prefix option always depends on the Next hop type option):
How it works…
The route defines the traffic flow. All traffic from the associated subnet will follow the route defined by these rules. If we define that traffic will go to the internet, all traffic will go outside the network to an IP address range defined with an IP address prefix. If we choose for traffic to go to a virtual network, it will go to a subnet defined by the IP address prefix. If that virtual network gateway is used, all traffic will go through the virtual network gateway and reach its connection on the other side — either another virtual network or our local network. The Virtual appliance option will send all traffic to the virtual appliance, which then, with its own set of rules, defines where the traffic goes next.
Let’s move on to the next recipe and learn how to change a route.
[10/11] Changing a route
Route requirements may change over time. In such cases, we can either remove the route or edit it, depending on our needs. If a route needs to be adjusted, we can select the option to change the route and apply the new traffic flow at any time.
How to do it…
In order to change the existing route, we need to do the following:
1. In the Azure portal, locate Route table.
2. Under Settings, select Routes and select the route you want to change from the list of available routes:
3. A new pane will open. We can change the Address prefix (for the destination IP range) and Next hop type settings. If the Next hop type option is a virtual appliance, an option for Next hop address will be available:
How it works…
The requirements for a route may change over time. We can change a route and adjust it to suit new requirements as needed. The most common scenarios are that the traffic needs to reach a specific service when the service IP changes over time. For example, we may need to route all traffic through a virtual appliance, but the IP address of the virtual appliance changes over time. We may change the route in the route table to reflect this change and force the traffic flow through the virtual appliance. Another example is when traffic needs to reach our local network through a virtual network gateway — the destination IP address range may change over time, and we need to reflect these changes in the route once again. In this recipe, we learned how to change a route.
In the next recipe, we’ll learn how to delete a route.
[11/11] Deleting a route
As we have already mentioned, route requirements may change over time. In some cases, rules are no longer applicable and we must remove them. In such cases, changing the route will not complete the task and we will need to remove the route completely. This task may be completed by deleting the route.
How to do it…
In order to delete a route, we must do the following:
1. In the Azure portal, locate the Route table link.
2. Under Settings, select Routes and then select the route you want to delete:
3. A new pane will open. Select the Delete option and confirm your action:
4. After this action has been confirmed, you will return to the previous pane and the deleted route will no longer be listed:
How it works…
As our requirements change, we need to address the new requirements in our route tables. We can either edit routes or remove them to meet these new requirements. When multiple routes are used in a single route table, one of the routes may become obsolete, or even block new requirements. In such cases, we may want to delete a route to resolve any issues.
If this blog helps you and clears your concepts please appreciate it with your simple and beautiful comment. Thanks for your wonderful time.
Keep coding, Keep going………
