The following are critical prerequisites for reading this chapter: you must have experience with networking concepts, including knowledge of IP addresses, DNS, routing, and networks like VPNs or WANs. You should also be familiar with the Azure portal and Azure PowerShell.

This chapter has two parts. First, you will read about designing private IP addresses for virtual networks (VNets), deploying VNets using Azure command-line tools and the Azure portal, and steps for preparing and configuring services for subnetting that include VNet gateways, Private Endpoint, firewalls, application gateways, and VNet-integrated platform services. Security aspects such as network security groups (NSGs) and access control lists (ACLs) for subnets are also discussed in detail, along with deployment and configuration steps. You will also learn about subnet delegation, planning, and subnetting for Azure route services.

In the second part, you will learn to design and deploy a domain name system (DNS) in private and public zones. Setting up DNS for name resolution inside VNets is explored in detail along with linking a private DNS zone to a VNet.

By the end of this chapter, you will understand some of the most crucial aspects of designing and deploying private IP addressing for VNets. Additionally, you will have detailed insight into designing and deploying name resolution.

Designing Private IP Addressing for VNets

In Chapter 1, “Getting Started with AZ-700 Certification for Azure Networking,” you read about Azure virtual networks (VNets). Let's do a quick recap to get you prepared for what you'll learn about in this chapter.

The Azure VNet is the fundamental building block for a private network. VNets provide a secure communication channel between Azure resources, such as virtual machines (VMs). VNets are like traditional datacenters but have the advantage of Azure's infrastructure, such as scalability, availability, reliability, broad network access, hybrid connectivity, segmentation, isolation, and security.

Azure VNets are the representation of your own networks in the cloud. The Azure cloud is logically isolated and dedicated to your subscription. VNets can be used to provision and manage virtual private networks (VPNs) in Azure. Alternatively, they can be linked to other VNets in Azure or your on-premises IT infrastructure to create hybrid or hybrid cross-premises solutions. You can link each VNet you make with another VNet and an on-premises network if the Classless Inter-Domain Routing (CIDR) blocks don't overlap. You can also control VNet settings, and subnets can be segmented.

The Azure VNet enables Azure resources to communicate with the Internet and on-premises networks securely. Critical scenarios include the following:

• Communication between Azure resources
• Contact with on-premises resources
• Filtering and routing of network traffic
• Integration with Azure services

Organizations can use VNets to do the following:

• Build a dedicated private cloud-native VNet.   Organizations do not always need cross-premises configurations. By creating a VNet, you allow your organization's services and VMs within cloud consumer VNets to communicate directly and securely within the cloud. You can still configure endpoint connections for VMs and services that need Internet connectivity as part of Azure's virtual network solution.
• Securely connect an on-premises datacenter.   Organizations can use VNets to securely connect their on-premise datacenters to the cloud via traditional site-to-site (S2S) VPNs. Azure provides secure connections between cloud-based enterprise VPN gateways and S2S VPNs using IPsec.
• Provide organizations with the ability to support a range of hybrid cloud scenarios.   The cloud can be securely connected to on-premises systems such as mainframes and Unix servers.

Azure VNets use private IP addresses. Private IP addresses fall within the same range as on-premises addresses. You have complete control over IP address assignment, name resolution, security settings, and security rules in an Azure VNet just as you do with on-premises networks. According to the CIDR for the IP address block, you can add or remove subnets.

Azure networks usually consist of essential components such as the following:

• Virtual networks
• Network security groups
• Subnets
• load balancers
• Firewalls

Azure's network structure is like an on-premises network, but its features and functions are different. Unlike on-premises networks, the Azure network does not follow a typical hierarchical structure. Azure allows you to scale infrastructure up and down on demand following cloud computing principles. It takes seconds for an organization's Azure resources to be provisioned, and routers and switches aren't required. You can logically segment a network according to your organization's demand since the entire infrastructure is virtual.

Network segmentation is an architectural practice that separates a network into numerous segments or subnets, each operating as its small network. This allows you to control traffic flow between subnets based on acceptable policies. Your organization can use segmentation to enhance monitoring, increase performance, localize technical problems, and significantly enhance security.

You can typically implement an NSG and a firewall. Subnets enable you to separate front- and back-end services, such as web servers and DNS, from each other. The Network layer filters traffic between internal and external servers. Firewalls can perform Network layer filtering as well as Application layer filtering. Your business can improve isolation of your resources for secure network architecture by using NSGs and a firewall.

A virtual network is a network in the cloud that is intended to serve cloud consumers. Virtual networks can be divided into multiple subnetworks. The cloud consumer virtual network is assigned a portion of each subnet. If there are no VMs or services deployed in a subnet, you can add, delete, expand, and shrink virtual networks.

In Azure VNets, all subnets can communicate by default. However, you can block communication between subnets by setting up an NSG. Subnet mask /29 is the smallest supported subnet; the largest supported subnet is /8.

You must know how to connect Azure virtual network resources with your organization's on-premises networks and configure IP addresses in the VNet. There are three types of resources that can have IP addresses assigned to them in Azure virtual networks:

• Virtual machine network interfaces
• load balancers
• Application gateways

You can establish them as dynamic (DHCP lease) or static (DHCP reservation). Organization on-premises and Azure virtual networks use private IP addresses:

• Dynamic private IP addresses are assigned using DHCP leases and are subject to change throughout their life span. Azure assigns the IP addresses in a subnet's address range that are currently unassigned or unreserved. If addresses 10.0.0.4-10.0.0.9 are already assigned to other resources, Azure gives 10.0.0.10 to a new resource.
• As a default, dynamic allocation is used. When an IP address has been assigned, it is released if it is:
  • Deleted
  • Reassigned
  • Modified to static

When you change the allocation method from dynamic to static, Azure assigns the previous dynamically assigned address as the static address. A static private IP address is assigned by DHCP reservation and does not change throughout the Azure resource. When a resource is stopped or deallocated, static IP addresses persist.

A subnet's address range, for instance, is 10.0.0.0.0/16, and the addresses 10.0.0.4-10.0.0.9 are used by other resources. You can assign any address between 10.0.0.10 and 10.0.255.254. Statically assigned addresses can only be released when you remove network interfaces.

When the allocation method is changed, Azure assigns a static IP address as a dynamic IP address. If the available address in the subnet is not set, the reassignment will occur. A network interface's address changes when it is assigned to a different subnet.

To assign the network interface to a different subnet, you must change the allocation method from static to dynamic. Then you set the allocation method back to static after assigning the interface to a different subnet. Affix the interface to an IP address in the new subnet's range.

For virtual machines in Linux or Windows, network interface cards or network interface cards are assigned one or more private IP addresses. The allocation method for private IP addresses can be dynamic or static, depending on the business requirement. For Azure internal load balancers and Azure application gateways, you can assign the private IP address to the front-end configuration.

Next let's turn to the fundamentals of IP addressing for Azure virtual networks.

The Azure VNet is fundamental to your organization's network. The scope of IP addresses is defined when you create a VNet. You are responsible for assigning IP addresses, setting security policies, and controlling security rules in the virtual network. Azure private IP addressing works the same way it does in on-premises networks. The Internet Assigned Numbers Authority (IANA) reserves private IP addresses for an organization's network based on the requirements of the cloud consumer's network:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

In a virtual network, a subnet is a set of IP addresses. You can divide the virtual network into multiple subnets. CIDR specifies the address range for each subnet. The CIDR format is used to represent a block of IP addresses in a network. CIDRs, established as part of IP addresses, indicate the length of the network prefix.

Take, for example, the CIDR 192.168.10.0/24. The network address is 192.168.10.0. 192.168.10.0 is part of the network address, whereas the last 8 bits are assigned to specific hosts. Address ranges for virtual networks and on-premise networks cannot overlap.

All Azure subnets are assigned three IP addresses by default. To comply with protocols, the first and last IP addresses of all subnets are also dedicated. An internal DHCP service manages the lease of IP addresses within Azure. Azure cloud consumers are not able to configure the .1, .2, and .3 IP addresses—Azure reserves these IP addresses for internal use.

You must compile requirements for your infrastructure before planning a network IP address scheme. These requirements will also help you prepare for future growth by reserving extra IP addresses and subnets. Here are questions you might ask to determine your requirements:

• What is the number of devices on your network?
• When do you plan on adding more devices to your network?
• What devices do you need to separate based on the services running on the infrastructure?
• Do you need multiple subnets?
• How many devices is your organization planning on adding to subnets in the future?
• In the future, how many subnets are you planning to add?

Keep in mind while designing IP schema that CIDR allows a more flexible allocation of IP addresses than was possible with the original system of IP address classes. You need to determine your business's requirements to slice the IP block into subnets and hosts. You should be familiar with the criteria for determining the number of devices on the network per subnet and how many subnets cloud users require.

Azure uses the first three IP addresses on each subnet. Protocol conformance is also reserved for the first and last IP addresses of a subnet. As a result, there are two *n-5 addresses on an Azure subnet, where n is the number of host bits.

Virtual networks can be deployed, and your cloud resources connected easily, when you understand the core concepts and best practices for implementing VNets (refer to Chapter 1 for a refresher). The rest of this section discusses the core concepts and best practices to follow while designing IP addresses for VNets.

• Address Space   VNets require a unique private IP address space, either public or private (RFC 1918). Virtual networks in Azure are assigned a private IP address from the address space that you specify. A virtual network can be created in more than one region per subscription. Virtual networks can contain multiple subnets.
• Subnets   Using subnets, you can segment the virtual network into one or more subnetworks, each of which receives a portion of the virtual network's address space. After that, Azure resources can be deployed within a specific subnet. Using subnets, you may segment your VNet address space for the organization's internal network, much like in a traditional network. Address allocation is also made more efficient in this way.

Deploying a VNet

In Chapter 1, you worked through the step-by-step deployment of Azure VNets using the Azure portal and Azure PowerShell. In this chapter you'll create a VNet using the Azure cloud shell.

VMs can communicate privately and with the Internet through a virtual network. In this section, you'll deploy a virtual network and then deploy two VMs into it.

Subnetworks are ranges of IP addresses within the virtual network. To organize and secure a virtual network, you can divide it into multiple subnets. Each NIC in a VM belongs to one virtual network subnet. NICs connected to different subnets within a virtual network can communicate without any additional configuration.

When setting up the virtual network, you specify their topology, including the available address spaces and subnets. Select address ranges that do not overlap when connecting the virtual network to other virtual networks or on-premises networks. Any address range in Azure is treated as a private virtual network IP address space. An IP address is a private address that only the computer can access. Only the address range of the virtual network, interconnected virtual networks, and the on-premises location can be accessed.

By default, security boundaries do not exist between subnets. This allows virtual machines within each subnet to communicate. Use NSGs to control traffic flows between subnets and VMs if your deployment needs security boundaries.

An access control list (ACL) defines whether network traffic is allowed or denied for subnets or NICs in an NSG. NSGs can be associated with subnets or individual NICs. ACLs are applied to all VMs in a subnet if an NSG is associated with that subnet. By associating an NSG directly to a NIC, you can restrict NIC traffic.

To create a new virtual network using the Azure cloud shell, follow the steps in Exercise 4.1.

If an Azure VM doesn't have a public IP address or is in a back-end pool of an Azure load balancer, it will have a default outbound access IP. Outbound access IP addresses aren't configurable by default.

When the VM is assigned a public IP address or placed in a standard load balancer with or without outbound rules, the default outbound access IP is disabled. When an Azure VNet NAT gateway resource is assigned to the subnet of a VM, the default outbound access IP is disabled. In Flexible Orchestration mode, VMs created by virtual machine scale sets do not have default outbound access.

Preparing Subnetting for Services

This section covers preparing subnetting for services, including VNet gateways, Private Endpoint, firewalls, application gateways, and VNet-integrated platform services.

Subnetworks are networks within networks. They are efficient because they are connected. By using subnetting, you ensure that network traffic can travel a shorter distance without traversing unnecessary routers to reach its destination. In this section you'll prepare the subnet for each service listed here:

• VNet gateway
• Private Endpoints
• Azure firewall
• Application gateway
• VNet-integrated platform services

Here is an overview of each service in this list:

• Virtual Network Gateway   Recall from Chapter 3, “Design, Deploy, and Manage Azure ExpressRoute,” that VM gateways are composed of two or more VMs deployed to a subnet that you create called the gateway subnet. VM gateways run routing tables and specific gateway services. You can create these VMs when you create the virtual network gateway. You cannot directly configure the VMs that are part of the virtual network gateway.

  A virtual network gateway in Azure is configured with a setting that specifies the type of gateway. A virtual network gateway's type determines how it will be used and what actions it will take. A VPN gateway that uses the gateway type VPN is distinct from an ExpressRoute gateway, which uses a different gateway type. Two virtual network gateways can be present in a virtual network: one VPN gateway and one ExpressRoute gateway.

• Private Endpoints   A Private Endpoint is an interface using a private IP address in a virtual network. The Azure Private Link provides you with a secure and private connection to the service. You can add the service to the cloud consumer virtual network by enabling a Private Endpoint.

  The service could be provided by Azure, such as Azure Storage, Azure Cosmos DB, Azure SQL Database, and the cloud consumer's own service using a Private Link service.

• Azure Firewall   Azure Firewall is a cloud-native security service that uses a well-designed intelligent firewall to protect business workloads from threats. It's a stateful firewall with high availability and unrestricted scalability built into it. The firewall can inspect both east-west traffic and north-south traffic.

  Standard and Premium versions of Azure Firewall are available.

  Azure Firewalls are managed across multiple subscriptions using Azure Firewall Manager. A firewall policy enables Firewall Manager to apply a standard set of network/application rules and configurations to firewalls within cloud tenants.

  Both VNets and virtual wide area networks (secure virtual hubs) can be protected with Firewall Manager. Secure virtual hubs simplify routing traffic to the firewall using the virtual WAN route automation solution in a few clicks.

• Azure Application Gateway   Cloud consumers can manage cloud consumer web applications using a web traffic load balancer. Traditionally, load balancers operate at the Transport layer (Open Systems Interconnection (OSI) Layer 4—TCP and UDP) and route traffic based on source IP address and port to a destination IP address and port.

  Application gateways can route a request based on additional attributes, such as the URI path or the host headers.

• VNet-Integrated Platform Services   App Service VNet integration allows your business applications to access resources via virtual networks. You can place several Azure resources in a non-Internet routable network. A virtual network integration does not allow cloud consumer apps to be accessed privately.

  App Service has two variations:

  • In one variation, there are four dedicated compute pricing tiers: Basic, Standard, Premium, and Premium v2.
  • In the other variation, the App Service Environment deploys directly into your organization's Azure VNet with dedicated infrastructure and uses the Isolated and Isolated v2 pricing tiers.

Example Case Study: Preparing Subnetting for Services

For this example, imagine that you are an Azure network architect, and you work for XYZ Company with two datacenters in the United States and two datacenters in Europe. Two other business units maintain six applications that you want to migrate to Azure as a pilot project. Figure 4.1 depicts the logical building blocks.

The applications’ basic architecture is as follows:

• Apps are currently hosted in one of XYZ Company's U.S. datacenters.
• On Linux servers running Ubuntu, OpCoApp1, OpCoApp2, OpCoApp3, and OpCoApp4 are web applications. A separate application server hosts RESTful services on Linux servers for each application. RESTful services connect to a MySQL database back-end.
• Both OpCoApp5 and OpCoApp6 run on Windows servers running Windows Server 2016. The applications connect to SQL Server databases.
• Address space 10.0.0.0/8 is used by on-premises datacenters.

Your customer has already engaged the consulting company, and they concluded that the following are the requirements with respect to the number of subscriptions and VNets:

• Resource consumption by other business units should not affect each business unit.
• All applications should be tested and developed on the same test/development VNet within each business unit.
• Two Azure datacenters are located on each continent (America and Europe).
• For easier management, you should minimize VNets and subnets.

To fulfill these requirements, the following is one of the ways forward.

You need to have a subscription for every business unit based on those requirements. You should also consider the “one subscription per business unit, two VNets per group of apps” pattern since you may want to minimize the number of VNets. This method prevents resource consumption by one business unit from counting against other business units’ limits.

Each Azure virtual network must also have an address space specified. As cloud consumers need connectivity between the on-premises datacenters and the Azure regions, the address space used by Azure VNets cannot clash with the on-premises network, and each VNet's address space should not conflict with any already existing VNets. You could satisfy these requirements by using address spaces other than the existing subnet's.

The following are the requirements with respect to the number of subnets and NSGs:

• For easier management, minimize VNets and subnets.
• The applications are separate from each other.
• Customers can access the applications over the Internet using HTTP/S.
• An encrypted tunnel allows users connected to the on-premises datacenters to access each application.
• Datacenters on-premises should be connected via existing VPN devices.
• A daily replication of Azure databases should be done to other Azure locations.

To fulfill these requirements, the following is one of the ways forward.

You could use one subnet per Application layer and NSGs to filter traffic per application based on those requirements. This method limits you to three subnets per VNet (front-end, Application layer, and Data layer) and one NSG per application per subnet. In this case, you should consider using NSGs for each app and one subnet per Application layer, as shown in Figure 4.2.

In addition, it would be helpful if you were able to deploy an extra subnet for the VPN connectivity between the VNets and the on-premises datacenters. You need to specify the address space for each subnet.

The following are the requirements with respect to the number of access controls:

• The company's network group should be in complete control of the VNet configuration.
• In each business unit, developers should be able to deploy VMs only to existing subnets.

To fulfill these requirements, the following is one of the ways forward.

Using these requirements, you would be able to include networking team members in the built-in Network Contributor role in each subscription, and create a custom role for application developers to be able to add VMs to existing subnets.

Several Azure roles in addition to Network Contributor are built into Azure role-based access control (RBAC). You can assign these roles to users, groups, service principals, and managed identities. The assignments are what permit users to access Azure resources.

Configuring Subnetting for Services

In this section, you will add, change, and delete a virtual network subnet. To create and add a subnet using the Azure portal, follow the steps in Exercise 4.2.

To change a subnet using the Azure portal, follow the steps in Exercise 4.3.

To delete a subnet using the Azure portal, follow the steps in Exercise 4.4.

Preparing and Configuring a Subnet Delegation

You can use subnet delegation for Azure PaaS services that need to be injected into a cloud consumer's virtual network. Subnet delegation offers customers complete control over how Azure services are integrated into their virtual networks.

You can delegate subnets to Azure services so that those services can set up some basic network configuration rules that will allow them to operate their instances stably. Because of this, you should take the following key deployment issues into consideration:

• Consider deploying the service in a shared subnet instead of a dedicated one.
• Postdeployment, add the network intent policies that are required for the service to function.

You can gain the following advantages by delegating subnets to specific services:

• The ability to establish a subnet for one or more Azure services and manage the instances in that subnet. To better manage resources and access, the virtual network owner may define the following for delegated subnets:
  • Security groups for network filtering traffic
  • Routing policies with user-definable routes
  • Service endpoint configurations integrated with routing policies
• Assign preconditions to injected services in network intent policies to better integrate them with the virtual network.

The virtual network's owners need to delegate one of the subnets for a specific Azure service by performing subnet delegation. The Azure service then deploys the instances into this subnet for consumption by cloud consumer workloads.

Delegated subnet Azure services still have the same basic properties as nondelegated subnet Azure services; for example:

• Instances can be injected into customer subnets, but existing workloads cannot be affected.
• These services apply flexible policies that the customer overrides.

According to the deployment model, the impact of subnet delegation on the subnet varies. Each Azure service can decide what properties it supports or does not support in a delegated subnet, such as:

• It supports a shared subnet with other Azure services or VMs that are in the same subnet, or it supports a dedicated subnet with instances of this service only.
• It associates an NSG with the delegated subnet.
• An NSG that supports the delegated subnet can also be associated with any other subnet.
• It enables routing tables to be associated with the delegated subnet.
• It allows a subnet to be associated with a routing table associated with a delegated subnet.
• The delegated subnet must contain at least one IP address.
• A delegated subnet must be assigned IP addresses from the Private IP Address space (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12).
• Custom DNS configurations have a DNS entry in Azure.
• Prior to deleting a virtual network or subnet, the delegation must be removed.
• Delegated subnets cannot be used with Private Endpoints.

The following policies can also be added to injected services:

• Security policies, which are a set of rules defining how a given service should operate
• A route policy, which is the collection of routes necessary for a service to function

Planning and Configuring Subnetting for Azure Route Server

Azure Route Server allows the dynamic routing of cloud consumer virtual networks and consumer network virtual appliances (NVAs). Using Azure Route Server, you can exchange routing information directly with any networking device that supports the Border Gateway Protocol (BGP) routing protocol and the Azure software-defined network (SDN) in the Azure VNet without manually setting up routing tables or configuring them. High availability is built into Azure Route Server, a managed service.

Figure 4.3 shows how Azure Route Server works with a software-defined wide area network (SD-WAN) NVA and a security NVA in a virtual network.

Upon establishing the BGP peering, Azure Route Server will receive a route from the SD-WAN appliance (10.250.0.0/16) and a default route (0.0.0.0/0) from the firewall. Once configured, the virtual network's routes are automatically applied to each VM. Therefore, the SD-WAN appliance will receive all traffic destined for the on-premises network. The firewall will also forward Internet traffic. Both NVAs will receive the virtual network address (10.1.0.0/16) from Azure Route Server. This information can be propagated to the on-premises network by the SD-WAN appliance.

You can configure, manage, and deploy your organization's virtual networks more easily with Azure Route Server. The following are the key benefits:

• Whenever an organization's virtual network addresses are updated, you no longer need to update the routing table on your NVA manually.
• Users of Azure networking no longer need to manually update user-defined routes whenever an NVA announces new routes or withdraws old ones.
• Using Azure Route Server, your NVA can peer with multiple instances, and the NVA can be configured with BGP attributes. Azure Route Server should know which NVA instance is active or passive based on your organization's Azure network design (e.g., active-active for performance or active-passive for resiliency).
• There is a common standard protocol between NVA and Azure Route Server. You can peer NVAs with Azure Route Server if the NVA supports BGP.
• You can deploy Azure Route Server on any new or existing virtual network.

The following are the key points to consider when planning and designing Azure Route Server:

• You can create one route server within a virtual network. An entire subnet called Route Server Subnet must be reserved for the deployment of the service.
• Azure Route Server supports virtual network peering; if you peer one virtual network with another and enable the Use Remote Gateway setting on the other, Azure Route Server will learn the address space of that virtual network and send it to all the virtual peering networks. An NVA will also program its routes into the routing table of the VMs connected to a peering virtual network.
• BGP is the only protocol Azure Route Server supports. To deploy Azure Route Server in a dedicated subnet in a virtual network, the NVA needs to support multihop external BGP. When configuring BGP on an NVA, you must choose a different Autonomous System Number (ASN) that the one used by Azure Route Server.
• During routing exchanges, Azure Route Server propagates the BGP routes to your organization's virtual network.
• A public IP address is required for Azure Route Server to communicate with the back-end service that manages routing configurations.

You can configure Azure Route Server to peer with an NVA in a virtual network using Azure PowerShell. Using Azure Route Server, routes are learned from the NVA and programmed in the virtual machines in the virtual network. Routes are also advertised to the NVA using Azure Route Server.

Use the New-AzResourceGroup command to create a resource group. You must make a resource group to host Azure Route Server before starting it. The following example creates a resource group named SybexRouteServerRG in the UAENorth location:

$rg = @{
    Name = 'SybexRouteServerRG '
    Location = 'UAENorth'
}
New-AzResourceGroup @rg

New-AzVirtualNetwork allows you to create a virtual network. A default virtual network named SybexVNet is created in the UAENorth location:

$vnet = @{
    Name = 'SybexVNet'
    ResourceGroupName = 'SybexRouteServerRG '
    Location = 'UAENorth'
    AddressPrefix = '10.0.0.0/16'    
}
$virtualNetwork = New-AzVirtualNetwork @vnet

There is a dedicated subnet called ARSSubnet that Azure Route Server requires. When deploying Route Server, you can receive an error message if the subnet size is less than /27 or a short prefix (such as /26 or /25). Add-AzVirtualNetworkSubnetConfig creates the ARSSubnet configuration:

$subnet = @{
    Name = 'ARSSubnet'
    VirtualNetwork = $virtualNetwork
    AddressPrefix = '10.0.0.0/24'
}
$subnetConfig = Add-AzVirtualNetworkSubnetConfig @subnet
$virtualnetwork | Set-AzVirtualNetwork

An assigned public IP address is required so that the back-end service can manage Route Server configuration. Create an IP address named SybexARSIP with New-AzPublicIpAddress:

$ip = @{
    Name = 'sybexARSIP'
    ResourceGroupName = 'SybexRG'
    Location = 'UAENorth'
    AllocationMethod = 'Static'
    IpAddressVersion = 'Ipv4'
    Sku = 'Standard'
}
$publicIp = New-AzPublicIpAddress @ip

Azure Route Server can be created with New-AzRouteServer. ARS is the name of the Azure Route Server created in the UAENorth location in this example. In the previous section, we created ARSSubnet with HostedSubnet.

$rs = @{
    RouteServerName = 'SybexARS'
    ResourceGroupName = 'SybexRG'
    Location = 'UAENorth'
    HostedSubnet = $subnetConfig.Id
    PublicIP = $publicIp
}
New-AzRouteServer @rs

BGP peering can be established between Route Server and the NVA with Add-AzRouteServerPeer.

The CC_nva_ip represents the virtual network address of the NVA. In the NVA, this is the ASN. ASNs other than those from 65515 to 65520 can be any 16-bit number. Microsoft reserves the range of ASNs in this range.

$peer = @{
    PeerName = 'SybexNVA"
    PeerIp = '192.168.0.1'
    PeerAsn = '65501'
    RouteServerName = 'SybexARS'
    ResourceGroupName = 'SybexRG'
}
Add-AzRouteServerPeer @peer

Use the same command with a different PeerName, PeerIp, and PeerAsn if you want to set up peering with a different NVA or another instance of a different NVA.

The IP and ASN of Azure Route Server are required to complete the configuration on the NVA. You can get this information by using Get-AzRouteServer:

$routeserver = @{
    RouteServerName = 'SybexARS'
    ResourceGroupName = 'SybexRG'
} 
Get-AzRouteServer @routeserver

If you have an ExpressRoute and an Azure VPN gateway in the same virtual network, and you want those two to exchange routes, you can enable route exchange on Azure Route Server. With the -AllowBranchToBranchTraffic flag, Azure Route Server can exchange routes with gateway(s):

$routeserver = @{
    RouteServerName = 'SybexARS'
    ResourceGroupName = 'SybexRG'
    AllowBranchToBranchTraffic
}  
Update-AzRouteServer @routeserver

Use Update-AzRouteServer without the -AllowBranchToBranchTraffic flag to disable route exchange between Azure Route Server and the gateway(s):

$routeserver = @{
    RouteServerName = 'SybexARS'
    ResourceGroupName = 'SybexRG'
}  
Update-AzRouteServer @routeserver

Designing and Configuring Public DNS Zones

A domain name system (DNS) converts a hostname (www.xyz.com) into an IP address (192.168.2.2). Each Internet device has an IP address, which is used to identify it, much like a street address helps to locate a house. There must be a translation between the address typed into a web browser (xyz.com) and what the machine can use to access the xyz.com website.

Domains are grouped into hierarchies in the DNS. The top-level domains include .com, .net, .org, .uk, or .jp below the root domain. org.uk and co.jp are second-level domains beneath the top-level domains. DNS name servers around the world host domains in the DNS hierarchy that are distributed globally.

Your public domain's host names can be resolved by Azure DNS. You could configure Azure DNS to host www.mycompany.xyz to your web server's IP address if you purchased the mycompany.xyz domain name from a domain name registrar.

With Azure DNS, your organization can use a globally distributed and high-availability name server infrastructure to host your organization domain. You can manage DNS records with credentials, APIs, tools, and billing, and you can support other Azure services by hosting domains in Azure DNS.

You can't use Azure DNS to purchase a domain name for your organization. Customers of the App Service can buy a domain name through a third-party registrar or use App Service domains, and organizations can host their domains in Azure DNS for record management.

Azure DNS's nonfunctional features include these built-in features (see Figure 4.4):

• Reliability and Performance   Azure DNS hosts DNS domains on its global DNS name servers, and it uses anycast networking. The closest DNS server answers the domain's DNS query to ensure high performance and availability.
• Security   Azure DNS is built on Azure Resource Manager, which offers these features:
  • By using Azure RBAC, you have control over who has access to specific actions.
  • Logs can be used to determine if a problem occurred when troubleshooting the activity.
  • Resources, resource groups, and subscriptions can be locked so that other users will not delete or modify critical resources.
• Accessibility   Azure DNS can manage DNS for Azure services and provide DNS for external resources. Azure DNS can be accessed through the Azure portal with the same credentials, support contract, and billing information. DNS billing is based on the number of DNS zones and queries hosted in Azure.

  Currently, Azure DNS does not support DNSSEC. Most businesses can minimize the need for DNSSEC by using HTTPS/TLS consistently in their applications. Organizations can host DNS zones with third-party DNS hosting providers if DNSSEC is a critical requirement.

  Azure DNS supports alias record sets. Your organization can use an alias record set to reference an Azure resource, such as an Azure public IP address, an Azure Traffic Manager profile, or an Azure Content Delivery Network (CDN) endpoint. The alias record set points to the IP address of the service instance. Whenever the IP address of the underlying resource changes, the alias record set seamlessly updates itself.

  Azure DNS also supports private DNS domains. This feature lets you use custom domain names in private virtual networks rather than using Azure-provided names.

  The DNS records for domains are stored in DNS zones. You will need to create a DNS zone for your domain name to host it in Azure DNS, and DNS records will then be added to this zone.

  When you design a DNS zone in Azure DNS, consider the following:

  • The zone's name must be unique within the resource group, and it cannot already exist. Otherwise, it fails.
  • Different Azure subscriptions or resource groups can use the same zone name.
  • Whenever multiple zones have the same name, each instance is assigned a different name server address. With the domain name registrar, only one set of addresses can be configured.
  • You do not need to own a domain name to create a DNS zone in Azure DNS. However, you need to hold the domain name for Azure DNS to be configured as a name server for the domain name with the domain name registrar.
  • As of this writing, the following maximum configurations are possible:
    • Public DNS zones per subscription: 250
    • Record sets per public DNS zone: 10,000
    • Records per record set in public DNS zones: 20
    • Alias records for a single Azure resource: 20

  During your requirements gathering, it's essential that you understand the following concepts in DNS:

  • DNS Record   A record that points an IPv4 address to a domain.
  • CNAME Records   CNAME doesn't respond with an IP address but rather with a pointer to the DNS record that contains it.
  • Weighted Routing   You can assign weights to service endpoints and distribute traffic according to those weights using weighted routing. This is one of four routing mechanisms available in Traffic Manager.
  • Priority Routing   Based on the health of the endpoints, priority routing is determined. All traffic is sent to the highest priority endpoint by default, but traffic is sent to the secondary endpoint when a failure or disaster occurs.
• Resiliency   Recovery from a disaster involves recovering from severe application functionality loss. To select the best disaster recovery solution, business and technology owners must consider which level of functionality they need during a disaster, such as being unavailable, partially available via reduced functionality, or fully functional. Enterprise customers choose multiregion architectures to reduce the risk of application failures and infrastructure failures. To achieve high availability and failover through redundant architecture, you have several options. Examples include:
  • Active/passive with cold standby
  • Active/passive with pilot light
  • Active/passive with warm standby

  When Azure architects set up disaster recovery architecture, there are two design aspects to consider:

  • Replicating instances, data, and configurations between a primary and a standby environment. Azure Site Recovery with partner appliances/services like Veritas or NetApp can provide disaster recovery natively.
  • Diverting network traffic to the standby site from the primary site. Using Azure DNS, Azure Traffic Manager (DNS), or third-party global load balancers is one option for disaster recovery.

Creating an Azure DNS Zone and Record Using PowerShell

In this section you create a DNS zone and record it with PowerShell in Azure. You can also perform these steps through the Azure portal or Azure CLI.

First, you need to create a DNS zone before you can use Azure DNS. DNS zones contain DNS records for a particular domain, and each zone can hold DNS records for a single domain.

In a DNS zone, DNS records are maintained for this domain and its subdomains. The DNS name servers are configured to answer queries on a domain and point to a destination.

In Exercise 4.7, you'll create a DNS zone for the domain organization that wants to host in Azure DNS. DNS records for a particular domain are stored in a DNS zone. Each DNS record for your domain is then created inside this DNS zone. Finally, you must configure the name servers for the domain to publish the cloud consumer DNS zone to the Internet (see Figure 4.5).

Designing and Configuring Private DNS Zones

The DNS is responsible for translating (or resolving) service names to IP addresses. Using Azure infrastructure, Azure DNS provides naming resolution for domains. Not only does Azure DNS support Internet-facing DNS domains, but it also supports private DNS zones.

Azure Private DNS offers a secure and reliable DNS service for virtual networks. A virtual network and connected virtual networks provide naming resolution for VMs. With Azure Private DNS, you don't have to configure a custom DNS solution to manage and resolve domain names in the virtual network. Private DNS zones allow your organization's own custom domain name instead of those provided by Azure during deployment. You can customize your organization's virtual network architecture to meet its needs with a custom domain name. You can also configure zone names with a split-horizon view, allowing private and public DNS zones to share the same name. Figure 4.6 illustrates the private domain name services.

It is helpful to link the virtual network with a private DNS zone to resolve the records of a private DNS zone from a virtual network. The linked virtual networks have full access to the private zone's DNS records and can resolve them. You can also enable autoregistration on a virtual network link. The DNS records for the VMs in the virtual network are registered in the private zone when you enable autoregistration on the virtual network link. If autoregistration is enabled, Azure DNS will update the zone record whenever a VM is created, its IP address changes, or it is deleted.

According to Microsoft's best practice, the private DNS zone shouldn't be a local domain. Some of the operating systems don't support this.

The following are some of the advantages of Azure Private DNS:

• Excludes the Demand for Custom DNS Solutions   For managing DNS zones in their virtual networks, many customers used custom DNS solutions. The native Azure infrastructure now allows you to work with DNS zones, which means you don't have to create and manage custom DNS solutions.
• Extensive DNS Record Types   Azure DNS supports A, AAAA, CNAME, MX, PTR, SOA, SRV, and TXT records.
• Automatic Hostname Record Management   Azure automatically maintains VMs in the specified virtual networks and custom DNS records. You can optimize cloud consumer domain names using this method without creating custom DNS solutions or modifying applications.
• Resolution of Hostnames among Virtual Networks   A private DNS zone can be shared between multiple virtual networks, unlike Azure-provided hostnames. In scenarios such as virtual network peering, this capability simplifies the discovery of cross-network services.
• Easy-to-Use Tools   The service relies on well-established Azure DNS tools (the Azure portal, Azure PowerShell, Azure CLI, Azure Resource Manager templates, and the REST API).
• Integrated Split-Horizon DNS Support   Azure DNS lets you create zones with the same name that resolve different responses within a virtual network and on the public Internet. Split-horizon DNS is typically used to provide a dedicated service version in the cloud consumer virtual network.
• Support for All Azure Regions   In the Azure public cloud, Azure DNS private zones can be established across all Azure regions.

The following are some of the Azure private DNS capabilities:

• Virtual machines automatically register from a private zone linked to a virtual network with autoregistration enabled.

  A record pointing to the private IP address of a virtual machine gets added to the private zone. Azure DNS also automatically removes the corresponding DNS record from the linked private zone when a VM in a virtual network link with autoregistration is deleted.

• The private zone supports forward DNS resolution across virtual networks that are linked to it.

  The virtual networks are not peering with each other for cross-virtual network DNS resolution. You might want to peer virtual networks in different scenarios (for example HTTP traffic).

• Virtual-network peering supports reverse DNS.

  For a private IP associated with a private zone, reverse DNS will return an FQDN that includes the host/record name and the zone name as the suffix.

The Azure private DNS service provides reliable and secure DNS management and resolution of domain names in a virtual network without adding a custom DNS service.

Before you enable Azure private DNS, there are a few concepts you should know. It is possible to associate a virtual network with a private DNS zone in two ways:

• A registration network is a virtual network configured against a specific DNS zone. A virtual machine within that virtual network will automatically register its hostname with the private DNS zone once it is registered.
• The behavior of a virtual network configured as a resolution network varies slightly. The DNS won't automatically register virtual machines, but they will still resolve hostnames in the private DNS zone.

Resolving networks have the advantage of allowing multiple DNS zones to be registered against a single DNS zone. VNets can share a standard DNS zone this way. Ideally, this is used when applications are spread across multiple VNets.

Consider the following Azure private DNS limitations when designing:

• If automatic registration of VM DNS records is enabled, only one private zone can be associated with a particular virtual network. Nevertheless, you can connect multiple virtual networks to a single DNS zone.
• The reverse DNS service is only available for private IP addresses in a linked virtual network.
• When reverse DNS for a private IP address is set to internal.cloudapp.net, the default suffix for the virtual machine will be internal.cloudapp.net. In the case of virtual networks connected to a private zone with autoregistration enabled, reverse DNS for a private IP address returns two FQDNs: one with the default suffix internal.cloudapp.net and another with the private zone suffix.
• Currently, conditional forwarding isn't supported natively. (Using a conditional forwarder, you can specify a domain to be forwarded to, such as contoso.com, in a DNS server. A DNS query for that domain is forwarded to the configured DNS server instead of the local DNS server trying to resolve the query.)
• Azure DNS private zones provide domain name resolution within a virtual network and between virtual networks. The virtual networks do not have to be peering explicitly. A private DNS zone must be linked to every virtual network.
• The CanNotDelete lock prevents accidental zone deletion, and a custom role should not have permission to delete zones.
• DNS-related security issues can be mitigated using a DNS firewall.
• Virtual networks belonging to different subscriptions can be linked to a private zone. You must have written permission to operate the virtual networks and the private DNS zone. Different Azure roles can grant permissions for writing. Classic Network Contributor Azure roles, for example, have written consent for virtual networks. The private DNS zones Contributor role has written permissions for the private DNS zones.
• As of this writing, the following maximum configuration was possible:
  • 1,000 private DNS zones per subscription
  • 25,000 record sets per private DNS zone
  • 20 records per record set for private DNS zones
  • 200 DNS queries queued (pending response) per virtual machine
  • 1,000 DNS queries a virtual machine can send to Azure DNS resolver, per the second set
  • A total of 1,000 private DNS zones a virtual network can get linked

Designing Name Resolution Inside a VNet

You may be required to enable communication between VMs and other resources deployed in a virtual network using Azure IaaS, PaaS, and hybrid solutions. Even though you can use IP addresses to enable communication, it is much easier to use easily recognizable names that do not change.

The following methods can be used by resources deployed in virtual networks to resolve domain names to internal IP addresses:

• Private DNS zones in Azure
• Azure-provided name resolution
• Your organization's managed DNS server

Which of these you use depends on how resources need to communicate and what type of name resolution is used.

In the previous section, you read about private DNS zones in Azure. In this section, you learn about Azure-provided name resolution.

Name resolution provided by Azure offers only basic authoritative DNS capabilities. If your organization needs a fully featured DNS solution for virtual networks, you must use Azure DNS private zones or cloud consumer-managed DNS servers. Let's assume your organization uses the Azure-provided name resolution option. When this happens, DNS zone names and records will be managed by Azure, and your organization will not be able to control DNS zone names or the life cycle of DNS records.

VMs and role instances within the same virtual network or cloud service can also use Azure to resolve internal names, in addition to public DNS resolution. Cloud services share the same DNS suffix, so the hostname alone suffices. However, different cloud services have different DNS suffixes in virtual networks deployed using the classic deployment model. FQDNs are required to resolve the other cloud service names in this case. Virtual networks deployed with Azure Resource Manager maintain a consistent DNS suffix, so the FQDN is not required. Network interfaces and VMs can both be given DNS names. Azure provides name resolution without any configuration needed, but it may not be appropriate for all deployment scenarios.

Azure-provided name resolution includes the following advantages and implementation considerations:

• It's easy to use because no configuration is required.
• It's extremely reliable. It's not necessary to manage and create clusters of your DNS servers.
• Both on-premises and Azure hostnames can be resolved using the service in conjunction with cloud consumer DNS servers.
• It is possible to resolve names between VMs and role instances within the same cloud service without an FQDN.
• Name resolution can be used in Azure Resource Manager deployed virtual networks without requiring FQDNs. For names to be resolved in different cloud services, virtual networks in the classic deployment model need an FQDN.
• Rather than using autogenerated names, choose hostnames that describe your deployments best.

The following are some key points to consider while adopting Azure-provided name resolution:

• It is not possible to modify the DNS suffix created by Azure-provided name resolution because it is fully managed by Microsoft.
• All DNS lookups are scoped to a single virtual network. It is impossible to resolve DNS names created for one virtual network from another virtual network.
• Organizations cannot register their records manually.
• There's no WINS or NetBIOS support. VMs cannot be accessed through Windows Explorer.
• DNS-compatible hostnames are required. 0–9, a–z, and “-” are the only valid characters for names.
• DNS query traffic for each VM is throttled. Most applications should not be affected. Organizations must enable client-side caching if they observe request throttling.
• Client-side caching: it is not necessary to send every DNS query across the network. Client-side caching reduces latency by resolving recurring DNS queries from a local cache and improves network resilience to blips. A DNS record contains a time-to-live (TTL) mechanism, which allows the cache to keep the record, if possible, without affecting its freshness. As a result, most situations can be handled by client-side caching. DNS caching packages (such as dnsmasq) are available in several different flavors (such as Ubuntu [uses resolvconf], SUSE [uses Netconf], and CentOS [uses NetworkManager]).
• Client-side retries: UDP is the primary protocol for DNS. The DNS protocol handles retry logic since the UDP protocol does not guarantee message delivery. DNS clients (operating systems) may exhibit different retry logic, depending on the creator's preference:
  • Windows operating systems retry after one second, then again after 2 seconds, 4 seconds, and 4 more seconds.
  • Linux defaults to trying after 5 seconds. Microsoft recommends changing the retry specifications to five times, with one-second intervals.
• A DNS cache is built into the default Windows DNS client. Caching is not included by default in some Linux distributions. Cloud consumers may want to add a DNS cache to each Linux VM if there isn't one already.
• A maximum of 180 VMs can be registered in a classic deployment model for each virtual network. Azure Resource Manager does not have this restriction.
• 168.63.129.16 is the Azure DNS IP address. This is a fixed IP address that will not change.
• Virtual networks based on Azure Resource Manager support reverse DNS. Cloud consumers can issue reverse DNS queries (PTR queries) to map virtual machine IP addresses to their FQDNs.
• All PTR queries for virtual machine IP addresses return FQDNs of the form vmname.internal.cloudapp.net, and a forward lookup on FQDNs of the form vmname.internal.cloudapp.net will resolve to the virtual machine's IP address.
• The reverse DNS queries will return two records if the virtual network is linked to an Azure DNS private zone. The first record will be in the format vmname.privatednszonename, and the second will be in the form vmname.internal.cloudapp.net.
• Even if a virtual network peers with other virtual networks, a reverse DNS lookup is still limited to that virtual network. NXDOMAIN returns in reverse DNS queries (PTR queries) for IP addresses of virtual machines located in peered virtual networks.
• By creating a reverse lookup zone and linking it to your organization's virtual network, you can disable the reverse DNS function in a virtual network.

Now let's move on to organization-managed DNS servers. The next two sections cover VMs, role instances, and web apps.

Linking a Private DNS Zone to a VNet

You need to link a virtual network to a private DNS zone created in Azure. The private DNS zone is accessible once the VMs are connected to that virtual network. It has a collection of virtual network link child resources. These resources represent connections to virtual networks. Registration or resolution virtual networks can be linked to a private DNS zone.

• Registration Virtual Network   An interface between a private DNS zone and a virtual network is created. The autoregistration option is available to cloud consumers. If this setting is enabled, the virtual network becomes a private DNS zone registration network. Each time a VM is deployed to the virtual network, a DNS record is automatically created. DNS records will also be created for already deployed VMs.

  Consequently, the private DNS zone becomes the registration zone for that virtual network. There can be multiple registration virtual networks in the private DNS zone. For each virtual network, however, there can be only one registration zone.

• Resolution Virtual Network   Organizations may link virtual networks to their private DNS zone without autoregistration. Virtual networks are treated as resolution networks only, and there will be no automatic creation of DNS records in the private zone for VMs deployed in this virtual network. Nonetheless, VMs deployed in the virtual network can successfully query DNS records within the private zone. Manually created records can be stored in a private DNS zone and automatic records from other virtual networks.

  There can be multiple resolution zones within a private DNS zone, and it is possible to have numerous resolution zones within a virtual network.

  The following are some key points to consider when using a virtual network link:

  • The classic deployment model does not support virtual networks deployed by Microsoft.
  • There can only be one connection between a private DNS zone and a virtual network in the cloud.
  • In a private DNS zone, each virtual network link must have its own unique name. Several private DNS zones may have the same name.
  • Check the Link Status field once the organization has created a virtual network link. The link status can change to complete after a few minutes, depending on the size of the virtual network.
  • Organizations can delete virtual networks, all linked virtual networks, and the associated DNS records by deleting the virtual networks.
  • The associated virtual network link can be removed by updating the DNS zone associated with the linked virtual network. During this process, automatically registered virtual machine records are removed from the zone.
  • Without first unlinking the virtual network from a private zone, the deletion operation succeeds, and all links to the DNS zone are automatically cleared.
• Configuring a Virtual Network Link   The organization creates a virtual network link to link a cloud at the consumer's private DNS zone to the organization's virtual network.

  Manage DNS records for VMs deployed in a virtual network using the Azure DNS private zone's autoregistration feature. This setting is enabled when an organization links a virtual network with a private DNS zone. Every VM in the virtual network will have its DNS record created.

  The A and PTR records are created for each VM. Additionally, DNS records are automatically created in the linked private DNS zone for newly deployed VMs. Any associated DNS records are also removed from the private DNS zone whenever a VM is deleted.

  When creating a virtual network link, select the Enable Auto Registration check box. The following are some key restrictions to consider:

  • Only VMs can be registered automatically. All other resources, such as internal load balancers, can be created manually in the private DNS zone linked to the virtual network by cloud consumers.
  • A DNS record is created automatically for the VM's primary NIC only. You can create DNS records manually for other network interfaces if cloud consumers’ VMs have more than one NIC.
  • DHCP-based virtual machine NICs automatically create DNS records. Autoregistration doesn't create records for the VM if you use static IPs, such as configuring multiple IP addresses in Azure.
  • The automatic registration of IPv6 (AAAA records) is not supported.
  • One private DNS zone can be associated with a specific virtual network when automatic VM DNS registration is enabled. Consumers of cloud services can link multiple virtual networks to a single DNS zone; however, they link many virtual networks to one DNS zone.
  • As of this writing, the following maximums are possible:
    • For private DNS zones with autoregistration enabled, the maximum number of virtual network links per zone is 1,000 and the maximum number of virtual network links per zone is 100.
    • With autoregistration enabled, a virtual network can link to only one private DNS zone.
    • The maximum number of private DNS zones a virtual network can link to is 1,000.

Exercise 4.9 walks you through the high-level workflow for configuring a virtual network link.

Summary

In this chapter you learned about designing private IP addresses for VNets, deploying the VNets using Azure command-line tools and the Azure portal, and steps to be followed in preparing and configuring services for subnetting that includes VNet gateways, Private Endpoint, firewalls, application gateways, and VNet-integrated platform services. Security aspects such as network security groups (NSGs) and ACLs were also discussed in detail, along with deployment and configuration steps. You learned about subnet delegation, planning, and configuring subnetting for Azure route services as well.

Along with designing subnets, you learned how to design and deploy DNS in private and public zones. We also explored setting up DNS for name resolution for VNets as well as linking a private DNS zone to a VNet.

Exam Essentials

• Know how to deploy virtual networks.   In Azure, a virtual network is a fundamental component of your private network. The service enables Azure resources, such as virtual machines, to communicate securely and access the Internet. The Azure virtual network enables Azure resources to communicate with the Internet and on-premises networks securely. You can create virtual networks using the Azure portal, Azure PowerShell, Azure CLI, and the ARM template.
• Be able to prepare and configure subnetting for services, including VNet gateways, Private Endpoints, firewalls, application gateways, and VNet-integrated platform services.   Subnet addresses are the IP addresses within a virtual network. Subnets help organize and secure virtual networks. Each NIC in a VM is connected to one virtual network subnet. If NICs in a virtual network are connected to different (or the same) subnets, they can communicate with each other without any additional configuration. A Layer 3 overlay network-based solution lets you extend on-premises subnets to Azure. You can use ARM templates, Azure PowerShell, and Azure CLI to create subnets.
• Be able to prepare and configure subnet delegation.   You can inject a specified Azure PaaS service into your virtual network by delegating a subnet. Subnet delegation gives customers complete control over integrating Azure services into their virtual networks. The virtual network owners must perform a subnet delegation exercise to designate one of the subnets for a particular Azure service. The Azure service then uses this subnet to deploy instances for consumption by customers.
• Be able to prepare and configure subnetting for Azure Route Server.   A dedicated subnet is required for Azure Route Server. At least /27 or a short prefix (such as /26 or /25) is required for the subnet. UDRs can't be configured on Azure Route Server subnets. Azure Route Server does not route data traffic between NVAs and VMs. Azure Route Server does not support RouteServerSubnet.
• Know how to design Public DNS zones.   Azure DNS hosts DNS domains and provides name resolution by using Azure infrastructure. Your Azure-hosted domains enable you to manage DNS records using credentials, APIs, tools, and billing as well as other Azure services. Azure DNS cannot be used to purchase domain names. Instead, App Service domains or third-party domain registrars can be used. When using Azure DNS, domain records are hosted there. Private domains can also be hosted in Azure DNS. This feature lets you use your own custom domain names in your private virtual networks rather than the Azure-provided names available today. There are alias records available through Azure DNS. Among the Azure resources that an alias record set can refer to are Azure public IP addresses, Azure Traffic Manager profiles, and Azure Content Delivery Network (CDN) endpoints. Azure DNS does not currently support DNSSEC.
• Know how to design private DNS zones.   Azure Private DNS offers reliable and secure DNS services for virtual networks. With Azure Private DNS, domain names are managed and resolved on the virtual network without the need to configure a custom DNS solution. You can deploy Azure services without using the Azure-provided names by using private DNS zones. When automatic VM DNS record registration of VMs is enabled, a specific virtual network can be linked to only one private zone if you wish to link more than one virtual network to one DNS zone. Reverse DNS works only for private IP space in the linked virtual network. Conditional forwarding is not natively supported.
• Be able to link a private DNS zone to a VNet.   Azure Private DNS provides a reliable, secure DNS service to manage and resolve domain names in a virtual network without adding a custom DNS solution. You can use your custom domain names by using private DNS zones rather than the Azure-provided names available today. The records in a private DNS zone aren't resolvable from the Internet, and DNS resolution against a private DNS zone works only from virtual networks linked to it. Microsoft doesn't support single-labeled private DNS zones. A private DNS zone can have a maximum of 34 labels.

Review Questions