Azure Network Connectivity and Name Resolution
The course is part of these learning pathsSee 3 more
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
When you create a virtual network, Azure automatically sets up name resolution so the VMs in it can communicate with each other using hostnames instead of IP addresses. Although this is very convenient, it has many limitations. For example, it doesn’t work across peered VNets. That is, VMs in one VNet can’t resolve the hostnames of VMs in a peered VNet. You could solve this by setting up a custom DNS server, but a simpler solution is to use Azure DNS.
Azure DNS is a service for hosting your domains and managing your domain name system records. Until recently, it could only be used to host public domains, such as contoso.net, but the new private domains feature allows you to host private domains that are only accessible from within your Azure virtual networks.
We’ll start off with a simple Azure DNS use case and work our way up to more complex ones. Before we get into private domains, I’ll show you how to use Azure DNS to host public domains. Suppose you have a web app and you want to give people access to it at www.contoso.net and also at just contoso.net.
First, you need to create a zone. That’s where we’ll put the DNS records for the contoso.net domain. Type “dns” in the search bar in the Azure portal. There’s “DNS zones”, which is what we want. Click “Add”. Then type the name of the zone, which is the same as the name of the domain. In this case, it’s “contoso.net”. Create a new resource group or use an existing one. Then click “Create”.
When it’s done, go to the zone. You’ll see that it has filled in a couple of records for you already. The NS record says which name servers to use. It configured four of Azure’s name servers.
The SOA record stands for “Start of Authority”. This gives information about the zone, such as the email address of the administrator, the master name server for the zone, and how often a secondary name server should refresh (that is, check for updates from the master).
Now we can create a record to translate contoso.net to an IP address. Click “Add Record set”. In the Name field, we’re supposed to type a hostname that comes before “.contoso.net”. For example, we could put “www” here. But what should we put if this is a record for contoso.net itself? We can’t leave it blank because it’s a required field. Well, have a look at what name was used for the NS and SOA records. Those records are for the root of the domain as well, so we should use the same name as they do.
Type the “at” symbol in the Name field. Leave the type of record as “A”, which stands for “Address”. The next field is TTL, which stands for “Time to Live”. This says how long DNS clients can cache a response before they have to request the address again, in case there’s an update to the record. We can leave it at 1 hour. Finally, we need to put in the IP address for the web app.
We need to go into App Services to get the address. I’ll open it in another tab. I have a web app called “cademo”. To get the IP address, you need to click on “Custom Domains”. There it is. Copy it and then go back to the other tab and paste it.
It added another IP address field. This might seem strange because if you put in multiple IP addresses for the same name, then how will DNS know which one the name should resolve to? Well, in that case, it chooses one randomly. This is actually quite common, especially for busy sites, because you can scale out by using multiple servers to handle the traffic. By the way, that’s why this is called a record set rather than a record. A record set can contain multiple records for the same name. For this example, we only have one IP address, so leave it at that and click OK.
If we were doing this for real, then we’d need to delegate this domain to Azure DNS. We would do that by going to the domain name registrar that we used to register our domain and entering these name servers in the registrar’s NS records for our domain. Once we did that and waited for 10 minutes or so for the information to propagate, anyone on the internet would be able to resolve contoso.net to its IP address. Let’s pretend that we did all of that.
Now let’s create a record for www. Click “Add Record set” again. Then type “www” for the name. We could make this an A record just like the last one, but it’s usually a better idea to make it a CNAME record instead. A CNAME record lets you make this name an alias for another name you’ve already defined. In this case, we want “www.contoso.net” to be an alias for “contoso.net” so they’ll both resolve to the same IP address. If we created an A record instead, and the IP address of our web app changed in the future, then we’d have to change the IP address in both records. This way, we’d only have to change it once.
Now we also need to tell our web app to accept requests for contoso.net. We’re already on the Custom Domains page. Currently, the only hostname assigned to this web app is the one that Azure assigned to it. To use your own domain name, click “Add hostname”. Type “www.contoso.net”. Then click “Validate”.
You can see that the domain ownership test failed. That’s because I don’t actually own contoso.net. Remember when I said that you need to delegate this domain to Azure DNS by changing the name servers at the registrar? Since I didn’t do that step, the DNS records I added are only on the Azure DNS name servers and not in the worldwide DNS system, so Azure App Services can’t find this record.
I still want to show you something else, though. If I had delegated the domain properly, then I’d also need to add contoso.net to the web app. When I click “Validate” for that, it fails, of course, but it also says that it’s expecting to find 2 DNS records for contoso.net. One is an A record, which makes sense, but the other one’s a TXT record, which seems kind of weird. A text record is just a place where you can associate some text with a domain. Azure App Services is looking for something very specific in it, though. You need to put in Azure’s default domain name for this web app. If you do that, then App Services will consider this a verification that you are, indeed, the owner of the contoso.net domain and that it can associate that domain with your web app. Once the verification is done, you can remove the text record from your DNS zone if you want to.
Just for the sake of completeness, let’s add the record. Go back to the other tab, click Add Record Set again, and change the Type to TXT. Set the name to “at” again. For the Value, we need the fully qualified domain name of the web app, so go back to the other tab and copy it from the Domain Ownership section. Then paste it in the Value field.
Now that we’ve added all of the necessary records, let’s verify that we added them properly. Even though we didn’t tell a domain registrar about this domain, we can still test that the names will resolve properly. We can do that by using the nslookup command and telling it to query one of the Azure DNS name servers directly.
I’m going to open Cloud Shell and run it from there, but you can run it from your Windows, Mac, or Linux desktop if you want. If you run it from Cloud Shell, make sure it’s in Bash mode. OK, now type “nslookup”, then the name we want to resolve, which is “www.contoso.net”, and then the name server it should query. To get that, copy the first name server address from up here. There. Notice that it doesn’t come back with the IP address. It only says that the canonical name (which is what CNAME stands for) is contoso.net.
To get the IP address, we have to do a lookup on contoso.net. There. It resolved to the IP address of the web app.
If you want to see all of the records for the root of contoso.net, then add “q=any” to the command. Now it also shows the NS record, the SOA record, and the TXT record.
That’s it for configuring a custom public domain. In the next lesson, we’ll set up a private domain.
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).