Name resolution scenarios and options

Name resolution scenarios and options

DNS servers host records that translate human-readable domain names into machine-readable IP addresses (used by computers to communicate with each other). For example, Figure shows the DNS server for the azurecourses.xyz domain zone, which has a single A record that translates the www.azurecourses.xyz hostname into the IP address 1.2.3.4. Clients that want to communicate with the web server called www.azurecourses.xyz can make a DNS request to their DNS resolver to translate the name into an IP address. The DNS resolver will then go through an iterative process to make a record request to the DNS server.

Figure – DNS server and name resolution

To facilitate network communications, there are two name resolution scenarios that we will cover:

• Internal name resolution: Providing name resolution for private/internal clients hosted in our virtual networks
• External name resolution: Providing name resolution for public/internet clients that need to access our public/internet-facing applications and services

Let’s start with the internal scenario and the options that we have to implement this.

Internal name resolution scenarios and options

Azure virtual network workloads need to be able to resolve internal and external domain names to IP addresses. A comprehensive Azure internal name resolution implementation should cover the translation of domain names for the following scenarios:

• Scenario 1 – name resolution for resources within the same virtual network

• Scenario 2 – name resolution for resources in different virtual networks

• Scenario 3 – name resolution for resources in connected on-premises networks (hybrid)

• Scenario 4 – name resolution for public domain names from VNet resources

Figure shows an example of this. By making name resolution requests to its DNS resolver (server), VM1 (deployed into Azure VNET-1) should be able to resolve the private IP address for VM2 (deployed into a separate subnet in the same Azure VNet), it should be able to resolve the private IP address for VM3 (deployed into another Azure VNet), it should be able to resolve the private IP address for VM4 (deployed into a connected on-premises network), and it should also be able to resolve public IP addresses for internet domain names. Of course, implementing these scenarios depends on what you are trying to achieve with your network architecture.

Figure – Internal name resolution for Azure workloads

So, what options can we implement to cover these scenarios? Which we can implement Azure virtual network internal name resolution scenarios:

Azure-provided name resolution

This is the default name resolution option for virtual network workloads. Anytime we create a new virtual network in Azure, the platform configures it to use this default option (Figure 2.9) and assigns a unique private DNS suffix to it in the <auto_generated_random_id>.internal. cloudapp.net format. Azure’s DHCP will also assign this DNS suffix to each VM in the virtual network to ensure that each host is resolvable within the VNet, using a Fully Qualified Domain Name (FQDN) of <vm _name>.<auto_ generated_random_id>.internal.cloudapp.net. If this does not make sense to you, don’t worry too much about it, as you will explore this in an upcoming hands-on exercise.

 

Figure  – Default VNet DNS server configuration

This default Azure-provided DNS server uses a virtual IP address of 168.63.129.16 to receive and respond to name resolution requests, as shown in Figure . This IP limits the number of requests from each VM to 1,000 requests per second. Anything above this gets throttled and queued.

Figure – Azure-provided DNS

The main advantage of this option is that it works out of the box, and we do not need to provision or manage our own DNS service for VMs within a VNet to resolve each other’s names. However, in terms of capabilities, it is quite limited! For example, it can only cover scenario 1 (name resolution for resources within the same virtual network) and scenario 4 (name resolution for public domain names from VNet resources) out of the four scenarios that we listed earlier.

There are other limitations with this option, including the following:

•      We have no ability to customize the configuration. For example, we cannot modify the auto- generated default DNS suffix assigned to our VNet (which is not very user-friendly). We cannot manually add additional DNS records to it beyond what is auto-registered. We cannot configure DNS forwarding for it so that it can resolve names using other internal DNS servers.

•    We cannot enable or configure logging capabilities. DNS logs may contain insights that could be used to detect active threats.

•      There is no WINS or NetBIOS support.

That’s a lot of limitations! Alright, that’s enough theoretical information – let’s get our hands dirty and explore this option in an Azure environment.

In the next hands-on exercise, you will explore the first option for internal name resolution in Azure – Azure-provided DNS.

 

A hands-on exercise – exploring Azure-provided name resolution

In this exercise, you will review and test the capabilities of the Azure-provided DNS option. Here are the tasks that we will complete in this exercise:

•      Task 1: Review and test the default name resolution option

Task 1 – reviewing and testing the default name resolution option

The steps are as follows:

1. In the Azure portal, in the search area at the top of the screen, type CoreServicesVNet 

and click on the virtual network resource that was created in the previous exercise.

Figure – Select the CoreServicesVnet resource

 

2.   In the CoreServicesVnet blade, click on DNS servers (in the Settings section). You should see here that the virtual network is configured as Default (Azure-provided). Leave the configuration as it is.

Figure – Review the default DNS server configuration

1.                  3. Go back to the SSH session that you previously opened in WebVM (if the session is closed, reconnect to it again). Review the default DNS client configuration with the following command:

You should see here that the virtual machine is configured to send name resolution requests to a virtual IP address of 168.63.129.16. You should also see the auto-generated DNS suffix here (it is not very user-friendly, is it? And remember that we cannot customize this name). Both values were provided to the client by Azure’s DHCP.

Figure 1 – Review the default DNS configuration for a VM

4.        Use the following commands to resolve the hostnames of VMs in the same virtual network as WebVM:

All the names should resolve successfully, as shown in the following screenshot. It works out of the box! Also, note that we didn’t need to specify the FQDN with the DNS suffix. It resolves with just the hostname. This is because the DNS suffix is in the search list that we reviewed in the previous step.

Figure 2.14 – Name resolution of the same VNet workloads

5.      Use the following commands to perform reverse DNS lookups for VMs in the same virtual network as WebVM:

All IP addresses should resolve successfully, as shown in the following screenshot. It works out of the box!

Figure 2.15 – Reverse DNS lookup of the same VNet workloads

6. Use the following commands to perform forward and reverse DNS lookups for VMs in a different virtual network:

Both lookups should fail, as shown in the following screenshot. The scope of the default Azure- provided DNS is limited to a virtual network! And because we don’t have access to modify its configuration, this cannot be changed.

Figure – Forward and reverse DNS lookup of workloads in a different VNet

7. Enter the following command to review how requests to the virtual IP address (168.63.129.16) are routed:

           8. Here is the output from the preceding command. As you can see, requests are routed through the defaul                      gateway of the Azure subnet.

Figure  – Azure-provided DNS route review

Thant Zin Phyo@Cracky (MCT, MCE, MVP)