1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Azure Network Connectivity and Name Resolution

More Complex Scenarios

The course is part of these learning paths

AZ-103 Exam Preparation: Microsoft Azure Administrator
course-steps 15 certification 6 lab-steps 8

Contents

keyboard_tab
Azure Network Connectivity and Name Resolution
1
Introduction
PREVIEW1m 24s
4
Azure DNS
10m 14s
7
play-arrow
Start course
Overview
DifficultyIntermediate
Duration32m
Students748
Ratings
4.8/5
star star star star star-half

Description

Learn how to configure Microsoft Azure connectivity and name resolution with this expertly instructed course from Cloud Academy. 

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 and then moves on to showing 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 7 lectures with an introduction and conclusion to aid in reviewing what you have learned throughout the course.

 

Learning Objectives

  • Configure Azure virtual network peering

  •  Create a virtual network gateway and use it to connect two VNets

  •  Configure Azure DNS to handle name resolution

Intended Audience

  • Those looking to become Azure cloud architects

  • Those preparing for Microsoft’s AZ-100 or AZ-102 exam

Prerequisites

  • Basic knowledge of Azure virtual networks

Additional Resources

Transcript

In the last lesson, we created a private domain for a single virtual network. A more complex scenario is when you have multiple period 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, but there's a catch. Remember the registration-VNets option that we used when we created the private zone in the last lesson? You can only have one registration VNet, so resources will only be auto-registered in the VNet you specify for that option. For the other VNets, you'll have to manually add DNS records. The other virtual networks are called resolution VNets.

 To link them to the DNS zone, you add the resolution-Vnets option and provide a list of VNets separated by spaces. Aside from resources not being automatically registered in resolution-VNets, there's one other 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.

About the Author

Students18642
Courses41
Learning paths23

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).