Streamlining Azure Connectivity: Implementing Private DNS for Big Ben Corporation

Introduction

In today's dynamic cloud environment, efficient and secure network management is paramount. As an Azure network engineer at Big Ben Corporation, a leader in high-tech watch manufacturing, a recent project focused on enhancing internal connectivity within our Azure infrastructure. The specific requirement was to establish a private DNS zone to facilitate seamless communication with a virtual machine (VM) using a user-friendly domain name. This initiative leveraged the capabilities of Azure Private DNS, a robust service that provides a reliable and secure DNS resolution for virtual networks in Azure. This article details the step-by-step implementation and key highlights of this successful project.

The Need for Private DNS

Traditionally, accessing virtual machines in Azure often involves using their public or private IP addresses. While functional, this method can be cumbersome and difficult to manage, especially as the number of VMs grows. Relying on IP addresses makes it challenging to remember and can lead to configuration errors. Furthermore, if an IP address changes, all dependent configurations need to be updated. Azure Private DNS offers a more elegant solution by allowing the creation of private DNS zones that are resolvable only within specified virtual networks. This enables the use of easily recognizable domain names to connect to VMs, simplifying management and improving overall network agility. The implementation of Private DNS for Big Ben Corporation aimed to address these challenges and provide a more scalable and user-friendly approach to internal resource access.

Step-by-Step Implementation in Azure

The implementation process involved several key stages within the Azure portal.

1. Accessing the Azure Portal and Connecting to the User VM

The first step involved securely logging into the Azure portal using the provided credentials. Ensuring the use of a private browser session is crucial for maintaining the integrity of the lab environment. Once logged in, the next step was to establish a Remote Desktop connection to the designated user-vm virtual machine. This connection was made using the public IP address and credentials provided, allowing for direct interaction with the VM's operating system. This initial access to the user-vm served as the starting point for verifying the DNS configuration later in the process.

2. Creating the Private DNS Zone

The core of the project involved creating the private DNS zone. This was initiated by navigating to the search bar at the top of the Azure portal and typing "private dns". From the auto-complete list, the "Private DNS zone" service was selected. On the "Private DNS zone" page, the "Create" button was clicked to begin the configuration. In the "Name" field, a descriptive name, bigbencorp.private, was entered. This name would serve as the domain suffix for all resources within this private DNS zone. After entering the name, the "Review + create" button was clicked, followed by "Create" to deploy the private DNS zone.

3. Linking the Private DNS Zone to the Virtual Network

Once the private DNS zone was successfully deployed, the next crucial step was to link it to the virtual network where the virtual machines reside. This linkage ensures that the DNS records within the private zone are resolvable by resources within the specified virtual network. To achieve this, the "Go to resource" button was clicked after the deployment. In the left navigation menu of the private DNS zone, under the "Settings" section, the "Virtual network links" option was selected. On the "Virtual network links" page, the "+ Add" button was clicked. In the "Link name" field, vnetlink was entered as a descriptive identifier for the link. From the "Virtual network" dropdown, the virtual network provisioned for this lab was selected. It's important to note that the VNet name typically includes the lab's title. The "Enable auto registration" checkbox was selected. This feature automatically registers the private IP addresses of virtual machines within the linked virtual network as A records in the private DNS zone. Finally, the "OK" button was clicked to create the virtual network link. It's worth noting that the creation of the virtual network link might take a few moments, and its status will eventually show as "Completed".

4. Verifying Auto-Registered Records

After the virtual network link was established, the next step was to verify that the "Enable auto registration" feature worked as expected. In the left navigation menu, the "Overview" section of the private DNS zone was clicked. The record sets within the private DNS zone were then examined. The expectation was to find auto-registered A records for both the server virtual machine (named in the format server-vm-xxxxx) and the user virtual machine (named in the format user-vm-xxxxx). The presence of these records confirms that Azure automatically associated the private IP addresses of these VMs with their respective hostnames within the bigbencorp.private zone. The name of the server virtual machine, particularly the 5-character unique suffix, was noted for later use in testing the DNS resolution.

5. Creating a DNS Record Pointing to the Server VM

In addition to the auto-registered records, a manual DNS record was created to provide a more user-friendly alias for the server virtual machine. On the "Overview" page of the private DNS zone, the "+ Record set" button was clicked. In the "Name" field, server was entered. The "Type" was verified to be "A - Alias record to IPv4 address". In the "IP address" field, the private IP address of the server VM, which was 10.0.1.4, was entered. Finally, the "OK" button was clicked to create this manual DNS record. After creation, the record sets were reviewed to confirm the presence of the newly created "server" A record.

6. Testing DNS Resolution from the User VM to the Server VM

The final stage involved testing the DNS resolution from the user-vm to the server-vm. This was done by reconnecting to the user-vm via Remote Desktop using its public IP address and credentials. Once inside the user-vm, PowerShell was launched. The hostname command was executed to confirm that the connection was indeed established to the correct virtual machine.

Next, the manually created A record for the server VM was tested using the nslookup command:

PowerShell

nslookup server.bigbencorp.private

The expected output was the IP address 10.0.1.4, confirming that the server.bigbencorp.private domain name correctly resolved to the server VM's private IP address.

Following this, the auto-registered A record for the server VM was also tested using nslookup:

PowerShell

nslookup server-vm-xxxxx.bigbencorp.private

It was crucial to replace xxxxx with the actual unique suffix of the server VM's name, which was noted earlier from the Azure portal. The expected output was also the IP address 10.0.1.4, verifying that the auto-registered DNS record was functioning correctly.

Finally, connectivity to the server VM via its domain name was tested using the ping command:

PowerShell

ping server.bigbencorp.private

Successful responses from the 10.0.1.4 IP address confirmed that the DNS record for the server virtual machine was fully functional and that the user-vm could communicate with the server-vm using the configured private domain name.

Final Thoughts

The successful implementation and configuration of Azure Private DNS for Big Ben Corporation has provided a more efficient and manageable approach to internal network connectivity. By creating a private DNS zone and linking it to the virtual network, we have enabled the use of domain names to access virtual machines, simplifying management and enhancing the overall cloud infrastructure. The ability to automatically register VMs and the option to create custom DNS records offer flexibility and control over internal DNS resolution. This project demonstrates the value of Azure Private DNS in streamlining network operations within an organization's Azure environment.

Deep Dive Into Private DNS? Listen to Podcast on Case Study 🎙