Azure Network Connectivity and Name Resolution
Learn how to configure Microsoft Azure connectivity and name resolution with this course instructed by a Cloud Academy expert.
In this course, you will learn two different ways to connect virtual networks together. The course starts by teaching you how to set up peering between virtual networks, then moves on to show you how to connect two VNets using a virtual network gateway. Once you have mastered network connections, you will learn how to use Azure DNS to configure custom domain names for the resources in your VNets. Finally, we will move on to learning how to set up both public and private DNS zones.
This course is essential for those looking to train enterprise teams since, by default, Azure virtual networks are isolated from each other and only have a rudimentary form of name resolution. To build useful networks in Azure, you will need to connect these virtual networks together. To make them easier to manage, you will need to implement custom name resolution.
This course is made up of 7 lectures with an introduction and conclusion to aid in reviewing what you have learned throughout the course.
- Configure Azure virtual network peering
- Create a virtual network gateway and use it to connect two VNets
- Configure Azure DNS to handle name resolution
- Those looking to become Azure cloud architects
- Those preparing for Microsoft’s AZ-100 or AZ-102 exam
- Basic knowledge of Azure virtual networks
- The GitHub repository for this course is at https://github.com/cloudacademy/azure-networks-and-dns
In the last lesson, we created a private domain for a single virtual network. A more complex scenario is when you have multiple peered networks that need to share name resolution. For example, in the hub-and-spoke architecture we discussed earlier in the course, it would make sense to have all of the VNets in the same private DNS zone.
This is relatively easy to set up. Remember the autoregistration option that we used when we created the private zone in the last lesson? Well, you can enable autoregistration on all of the VNets in the hub-and-spoke architecture and link them to the same private zone. That way, whenever you create a VM in a VNet, its IP address will be registered in the zone, and all of the VNets in the hub-and-spoke network will be able to resolve it.
If you don’t enable autoregistration on a VNet, then you have to manually add DNS records for the VMs you create in it. This type of VNet is called a resolution VNet.
There is one deficiency when linking multiple VNets to the same zone. PTR queries (that is, reverse DNS queries) don’t work between virtual networks. So, for example, if you try to do a reverse DNS query between the hub and one of the spokes, you’ll get a Non-Existent Domain response. Reverse DNS queries do work within a virtual network, though.
Another scenario is when you want to have a zone that’s both public and private. For example, suppose you have two different versions of an application, one for customers and one for employees, and that you want both to have the same domain name. This is called split-horizon functionality.
With Azure DNS, you can create a public zone and a private zone that both have the same name, such as contoso.net. In the private zone, the application VM’s internal IP address would be automatically registered (assuming that you configured it as a registration VNet). In the public zone, you’d register the public IP address of the VM running the customer application, which may or may not be the same VM. So, if a request for contoso.net comes from the internet, it will reach the public IP address, and if it comes from the internal network, such as from an on-premises network that’s connected to the VNet, then it will reach the private IP address.
And that’s it for scenarios.
Guy launched his first training website in 1995 and he's been helping people learn IT technologies ever since. He has been a sysadmin, instructor, sales engineer, IT manager, and entrepreneur. In his most recent venture, he founded and led a cloud-based training infrastructure company that provided virtual labs for some of the largest software vendors in the world. Guy’s passion is making complex technology easy to understand. His activities outside of work have included riding an elephant and skydiving (although not at the same time).