0% found this document useful (0 votes)
176 views

Module4 Virtualnetworking

The document discusses Azure networking components, specifically virtual networks and subnets. It states that virtual networks in Azure allow organizations to logically isolate their Azure resources in a virtual private network dedicated to their subscription. Subnets further segment virtual networks and can improve security, performance, and manageability. The document provides examples of how virtual networks and subnets can be used and considerations for implementing them in Azure networking.

Uploaded by

Nithin krishna
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
176 views

Module4 Virtualnetworking

The document discusses Azure networking components, specifically virtual networks and subnets. It states that virtual networks in Azure allow organizations to logically isolate their Azure resources in a virtual private network dedicated to their subscription. Subnets further segment virtual networks and can improve security, performance, and manageability. The document provides examples of how virtual networks and subnets can be used and considerations for implementing them in Azure networking.

Uploaded by

Nithin krishna
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 33

Azure Networking Components

A major incentive for adopting cloud solutions such as Azure is to enable information technology (IT)
departments to move server resources to the cloud. This can save money and simplify operations by removing
the need to maintain expensive datacenters with uninterruptible power supplies, generators, multiple fail-safes,
clustered database servers, and so on. For small and medium-sized companies, which might not have the
expertise to maintain their own robust infrastructure, moving to the cloud is particularly appealing.

Once the resources are moved to Azure, they require the same networking functionality as an on-premises
deployment, and in specific scenarios require some level of network isolation. Azure networking components
offer a range of functionalities and services that can help organizations design and build cloud infrastructure
services that meet their requirements. Azure has many networking components.

Virtual Networks
An Azure Virtual Network (VNet) is a representation of your own network in the cloud. It is a logical isolation
of the Azure cloud dedicated to your subscription. You can use VNets to provision and manage virtual private
networks (VPNs) in Azure and, optionally, link the VNets with other VNets in Azure, or with your on-premises
IT infrastructure to create hybrid or cross-premises solutions. Each VNet you create has its own CIDR block
and can be linked to other VNets and on-premises networks if the CIDR blocks do not overlap. You also have
control of DNS server settings for VNets, and segmentation of the VNet into subnets.

1
Virtual networks can be used in many ways.

 Create a dedicated private cloud-only VNet. Sometimes you don't require a cross-premises
configuration for your solution. When you create a VNet, your services and VMs within your VNet can
communicate directly and securely with each other in the cloud. You can still configure endpoint
connections for the VMs and services that require internet communication, as part of your solution.
 Securely extend your data center With VNets. You can build traditional site-to-site (S2S) VPNs to
securely scale your datacenter capacity. S2S VPNs use IPSEC to provide a secure connection between your
corporate VPN gateway and Azure.
 Enable hybrid cloud scenarios. VNets give you the flexibility to support a range of hybrid cloud
scenarios. You can securely connect cloud-based applications to any type of on-premises system such as
mainframes and Unix systems.

For more information, Virtual Network Documentation.

Subnets
A virtual network can be segmented into one or more subnets. Subnets provide logical divisions within your
network. Subnets can help improve security, increase performance, and make it easier to manage the network.

Each subnet contains a range of IP addresses that fall within the virtual network address space. Each subnet
must have a unique address range, specified in CIDR format. The address range cannot overlap with other
subnets in the virtual network in the same subscription.

2
Considerations
 Service requirements. Each service directly deployed into virtual network has specific requirements for
routing and the types of traffic that must be allowed into and out of subnets. A service may require, or
create, their own subnet, so there must be enough unallocated space for them to do so. For example, if you
connect a virtual network to an on-premises network using an Azure VPN Gateway, the virtual network
must have a dedicated subnet for the gateway.
 Virtual appliances. Azure routes network traffic between all subnets in a virtual network, by default.
You can override Azure's default routing to prevent Azure routing between subnets, or to route traffic
between subnets through a network virtual appliance. So, if you require that traffic between resources in the
same virtual network flow through a network virtual appliance (NVA), deploy the resources to different
subnets.
 Service endpoints. You can limit access to Azure resources such as an Azure storage account or Azure
SQL database, to specific subnets with a virtual network service endpoint. Further, you can deny access to
the resources from the internet. You may create multiple subnets, and enable a service endpoint for some
subnets, but not others.
 Network security groups. You can associate zero or one network security group to each subnet in a
virtual network. You can associate the same, or a different, network security group to each subnet. Each
network security group contains rules, which allow or deny traffic to and from sources and destinations.

✔️Azure reserves the first three IP addresses and the last IP address in each subnet address range.

Implementing Virtual Networks


You can create new virtual networks at any time. You can also add virtual networks when you create a virtual
machine. Either way you will need to define the address space, and at least one subnet. By default, you can
create up to 50 virtual networks per subscription per region, although you can increase this limit to 500 by
contacting Azure support.

✔️Default limits on Azure networking resources can change periodically so it's a good idea to consult the
documentation for the latest information.

3
✔️Always plan to use an address space that is not already in use in your organization, either on-premises or in
other VNets. Even if you plan for a VNet to be cloud-only, you may want to make a VPN connection to it later.
If there is any overlap in address spaces at that point, you will have to reconfigure or recreate the VNet. The
next lesson will focus on IP addressing.

Demonstration - Creating Virtual Networks


In this demonstration, you will create virtual networks.

Note: You can use the suggested values for the settings, or your own custom values if you prefer.

Create a virtual network in the portal

1. Sign in the to the Azure portal and search for Virtual Networks.


2. On the Virtual Networks page, click Add.
 Name: myVNet1.
 Address:10.1.0.0/16.
 Subscription: Select your subscription.
 Resource group: Select new or choose an existing resource group
 Location - Select your location
 Subnet - Enter mySubnet1.
 Subnet - Address range: 10.1.0.0/24
3. Leave the rest of the default settings and select Create.
4. Verify your virtual network was created.

Create a virtual network using PowerShell

1. Create a virtual network. Use values as appropriate.


$myVNet2 = New-AzVirtualNetwork -ResourceGroupNamemyResourceGroup
-Location EastUS -Name myVNet2 -AddressPrefix 10.0.0.0/16
2. Verify your new virtual network information.
Get-AzVirtualNetwork -Name myVNet2
3. Create a subnet. Use values as appropriate.
$mySubnet2 = Add-AzVirtualNetworkSubnetConfig -Name mySubnet2
-AddressPrefix 10.0.0.0/24 -VirtualNetwork $myVNet2
4. Verify your new subnet information.
Get-AzVirtualNetworkSubnetConfig -Name mySubnet2 -VirtualNetwork $myVNet2
5. Associate the subnet to the virtual network.
$mySubnet2 | Set-AzVirtualNetwork
6. Return to the portal and verify your new virtual network with subnet was created.

IP Addressing
You can assign IP addresses to Azure resources to communicate with other Azure resources, your on-premises
network, and the Internet. There are two types of IP addresses you can use in Azure. Virtual networks can
contain both public and private IP address spaces.

4
1. Private IP addresses: Used for communication within an Azure virtual network (VNet), and your on-
premises network, when you use a VPN gateway or ExpressRoute circuit to extend your network to Azure.
2. Public IP addresses: Used for communication with the Internet, including Azure public-facing services.

Static vs Dynamic addressing


IP addresses can also be statically assigned or dynamically assigned. Static IP addresses do not change and are
best for certain situations such as:

 DNS name resolution, where a change in the IP address would require updating host records.
 IP address-based security models which require apps or services to have a static IP address.
 SSL certificates linked to an IP address.
 Firewall rules that allow or deny traffic using IP address ranges.
 Role-based VMs such as Domain Controllers and DNS servers.

✔️As a best practice you may decide to separate dynamically and statically assigned IP resources into different
subnets. And, IP Addresses are never managed from within a virtual machine.

Creating Public IP Addresses

IP Version. Select IPv4 or IPv6 or Both. Selecting Both will result in 2 Public IP addresses being create- 1 IPv4
address and 1 IPv6 address.

5
SKU. You cannot change the SKU after the public IP address is created. A standalone virtual machine, virtual
machines within an availability set, or virtual machine scale sets can use Basic or Standard SKUs. Mixing
SKUs between virtual machines within availability sets or scale sets or standalone VMs is not allowed.

Name. The name must be unique within the resource group you select.

IP address assignment

 Dynamic. Dynamic addresses are assigned only after a public IP address is associated to an Azure
resource, and the resource is started for the first time. Dynamic addresses can change if they're assigned to a
resource, such as a virtual machine, and the virtual machine is stopped (deallocated), and then restarted. The
address remains the same if a virtual machine is rebooted or stopped (but not deallocated). Dynamic
addresses are released when a public IP address resource is dissociated from a resource it is associated to.
 Static. Static addresses are assigned when a public IP address is created. Static addresses are not
released until a public IP address resource is deleted. If the address is not associated to a resource, you can
change the assignment method after the address is created. If the address is associated to a resource, you
may not be able to change the assignment method. If you select IPv6 for the IP version, the assignment
method must be Dynamic for Basic SKU. Standard SKU addresses are Static for both IPv4 and IPv6.

Public IP Addresses
A public IP address resource can be associated with virtual machine network interfaces, internet-facing load
balancers, VPN gateways, and application gateways.

Public IP addresses IP address association Dynamic Static

Virtual Machine NIC Yes Yes

Load Balancer Front-end configuration Yes Yes

VPN Gateway Gateway IP configuration Yes Yes*

Application Gateway Front-end configuration Yes Yes*

*Static IP addresses only available on certain SKUs.

Address SKUs
When you create a public IP address you are given a SKU choice of either Basic or Standard. Your SKU
choice affects the IP assignment method, security, available resources, and redundancy. This table summarizes
the differences.

Feature Basic SKU Standard SKU

IP
Static or dynamic Static
assignment

Are secure by default and


Security Open by default
closed to inbound traffic

6
Feature Basic SKU Standard SKU

Network interfaces, VPN Gateways, Application Network interfaces or public


Resources
Gateways, and Internet-facing load balancers standard load balancers

Redundancy Not zone redundant Zone redundant by default

Private IP Addresses
A private IP address resource can be associated with virtual machine network interfaces, internal load balancers,
and application gateways. Azure can provide an IP address (dynamic assignment) or you can assign the IP
address (static assignment).

Private IP Addresses IP address association Dynamic Static

Virtual Machine NIC Yes Yes

Internal Load Balancer Front-end configuration Yes Yes

Application Gateway Front-end configuration Yes Yes

A private IP address is allocated from the address range of the virtual network subnet a resource is deployed in.

 Dynamic. Azure assigns the next available unassigned or unreserved IP address in the subnet's address
range. For example, Azure assigns 10.0.0.10 to a new resource, if addresses 10.0.0.4-10.0.0.9 are already
assigned to other resources. Dynamic is the default allocation method.
 Static. You select and assign any unassigned or unreserved IP address in the subnet's address range. For
example, if a subnet's address range is 10.0.0.0/16 and addresses 10.0.0.4-10.0.0.9 are already assigned to
other resources, you can assign any address between 10.0.0.10 - 10.0.255.254.

Network Security Groups


You can limit network traffic to resources in a virtual network using a network security group (NSG). A
network security group contains a list of security rules that allow or deny inbound or outbound network traffic.
An NSG can be associated to a subnet or a network interface.

Subnets
You can assign NSGs to subnets and create protected screened subnets (also called a DMZ). These NSGs can
restrict traffic flow to all the machines that reside within that subnet. Each subnet can have zero, or one,
associated network security groups.

Network Interfaces
You can assign NSGs to a NIC so that all the traffic that flows through that NIC is controlled by NSG rules.
Each network interface that exists in a subnet can have zero, or one, associated network security groups.

7
Associations
When you create an NSG the Overview blade provides information about the NSG such as, associated subnets,
associated network interfaces, and security rules.

✔️Generally, this is used for specific VMs with Network Virtual Appliances (NVAs) roles, otherwise it is
recommended to link NSG to the subnet level and re-use across your VNETs and subnets.

For more information, Network Security Groups.

NSG Rules
Security rules in network security groups enable you to filter the type of network traffic that can flow in and out
of virtual network subnets and network interfaces. Azure creates several default security rules within each
network security group.

You can add more rules by specifying Name, Priority, Port, Protocol (Any, TCP, UDP), Source (Any, IP
Addresses, Service tag), Destination (Any, IP Addresses, Virtual Network), and Action (Allow or Deny). You
cannot delete the default rules, but you can add other rules with a higher priority. Azure creates the default rules
in each network security group that you create. You cannot remove the default rules, but you can override them
by creating rules with higher priorities.

Inbound rules
There are three default inbound security rules. The rules deny all inbound traffic except from the virtual
network and Azure load balancers.

8
Outbound rules
There are three default outbound security rules. The rules only allow outbound traffic to the Internet and the
virtual network.

NSG Effective Rules


NSGs are evaluated independently, and an “allow” rule must exist at both levels otherwise traffic will not be
admitted.

9
In the above example if there was incoming traffic on port 80, you would need to have the NSG at subnet level
ALLOW port 80, and you would also need another NSG with ALLOW rule on port 80 at the NIC level. For
incoming traffic, the NSG set at the subnet level is evaluated first, then the NSG set at the NIC level is
evaluated. For outgoing traffic, it is the converse.

If you have several NSGs and are not sure which security rules are being applied, you can use the Effective
security rules link. For example, you could verify the security rules being applied to a network interface.

Creating NSG Rules


It is easy to add inbound and outbound rules. There is a Basic and Advanced page. The advanced option lets
you select from a large variety of services such as HTTPS, RDP, FTP, and DNS.

10
Service. The service specifies the destination protocol and port range for this rule. You can choose a predefined
service, like HTTPS and SSH. When you select a service the Port range is automatically completed. Choose
custom to provide your own port range.

Port ranges. If you choose a custom service then provide a single port, such as 80; a port range, such as 1024-
65635; or a comma-separated list of single ports and/or port ranges, such as 80, 1024-65535. This specifies on
which ports traffic will be allowed or denied by this rule. Provide an asterisk (*) to allow traffic on any port.

Priority. Rules are processed in priority order. The lower the number, the higher the priority. We recommend
leaving gaps between rules – 100, 200, 300, etc. This is so it is easier to add new rules without editing existing
rules. Enter a value between 100-4096 that is unique for all security rules within the network security group.

✔️Are there any services you are interested in?

Application Security Groups


Application Security Groups provide for the grouping of servers with similar port filtering requirements, and
group together servers with similar functions, such as web servers.

 Allows you to reuse your security policy at scale without manual maintenance of explicit IP addresses.
 Handles the complexity of explicit IP addresses and multiple rule sets, allowing you to focus on your
business logic.

Consider the following illustration.

11
In the illustration, NIC1 and NIC2 are members of the AsgWeb ASG. NIC3 is a member of the AsgLogic ASG.
NIC4 is a member of the AsgDb ASG. Though each network interface in this example is a member of only one
ASG, a network interface can be a member of multiple ASGs, up to the Azure limits. None of the network
interfaces have an associated network security group. NSG1 is associated to both subnets and contains the
following rules:

 Allow-HTTP-Inbound-Internet
 Deny-Database-All
 Allow-Database-BusinessLogic

The rules that specify an ASG as the source or destination are only applied to the network interfaces that are
members of the ASG. If the network interface is not a member of an ASG, the rule is not applied to the network
interface even though the network security group is associated to the subnet.

ASGs have the following constraints


 There are limits to the number of ASGs you can have in a subscription, in addition to other limits related
to ASGs.
 You can specify one ASG as the source and destination in a security rule. You cannot specify multiple
ASGs in the source or destination.
 All network interfaces assigned to an ASG have to exist in the same virtual network that the first
network interface assigned to the ASG is in. For example, if the first network interface assigned to an ASG

12
named AsgWeb is in the virtual network named VNet1, then all subsequent network interfaces assigned to
ASGWeb must exist in VNet1. You cannot add network interfaces from different virtual networks to the
same ASG.
 If you specify an ASG as the source and destination in a security rule, the network interfaces in both
ASGs must exist in the same virtual network. For example, if AsgLogic contained network interfaces from
VNet1, and AsgDb contained network interfaces from VNet2, you could not assign AsgLogic as the source
and AsgDb as the destination in a rule. All network interfaces for both the source and destination ASGs
need to exist in the same virtual network.

Demonstration - NSGs
In this demonstration, you will explore NSGs and service endpoints.

Access the NSGs blade

1. Access the Azure Portal.


2. Search for and access the Network Security Groups blade.
3. If you have virtual machines, you may already have NSGs. Notice the ability to filter the list.

Add a new NSG

1. + Add a network security group.


 Name: select a unique name
 Subscription: select your subscription
 Resource Group: create new or select an existing resource group
 Location: your choice
 Click Create
2. Wait for the new NSG to deploy.

Explore inbound and outbound rules

1. Select your new NSG.


2. Notice the NSG can be associated with subnets and network interfaces (summary information above the
rules).
3. Notice the three inbound and three oubound NSG rules.
4. Under Settings select Inbound security rules.
5. Notice you can use Default rules to hide the default rules.
6. + Add a new inbound security rule.
7. Click Basic to change to the Advanced mode.
8. Use the Service drop-down to review the predefined services that are available.
9. When you make a service selection (like HTTPS) the port range (like 443) is automatically populated.
This makes it easy to configure the rule.
10. Use the Information icon next to the Priority label to learn how to configure the priority.
11. Exit the rule without making any changes.
12. As you have time, review adding an outbound security rule.

Azure Firewall
Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network
resources. It's a fully stateful firewall as a service with built-in high availability and unrestricted cloud
scalability. You can centrally create, enforce, and log application and network connectivity policies across
subscriptions and virtual networks. Azure Firewall uses a static public IP address for your virtual network

13
resources allowing outside firewalls to identify traffic originating from your virtual network. The service is fully
integrated with Azure Monitor for logging and analytics.

Azure Firewall features


 Built-in high availability. High availability is built in, so no additional load balancers are required and
there's nothing you need to configure.
 Availability Zones. Azure Firewall can be configured during deployment to span multiple Availability
Zones for increased availability.
 Unrestricted cloud scalability. Azure Firewall can scale up as much as you need to accommodate
changing network traffic flows, so you don't need to budget for your peak traffic.
 Application FQDN filtering rules. You can limit outbound HTTP/S traffic or Azure SQL traffic to a
specified list of fully qualified domain names (FQDN) including wild cards.
 Network traffic filtering rules. You can centrally create allow or deny network filtering rules by source
and destination IP address, port, and protocol. Azure Firewall is fully stateful, so it can distinguish
legitimate packets for different types of connections. Rules are enforced and logged across multiple
subscriptions and virtual networks.
 Threat intelligence. Threat intelligence-based filtering can be enabled for your firewall to alert and
deny traffic from/to known malicious IP addresses and domains. The IP addresses and domains are sourced
from the Microsoft Threat Intelligence feed.
 Multiple public IP addresses. You can associate multiple public IP addresses (up to 100) with your
firewall.

Implementing Azure Firewall


Let's consider a simple example where we want to use Azure Firewall to route protect our workload server by
controlling the network traffic.

14
1. Create the network infrastructure. In this case, we have one virtual network with three subnets.
2. Deploy the firewall. The firewall is associated with the virtual network. In this case, it is in a separate
subnet with a public and private IP address. The private IP address will be used in a new routing table.
3. Create a default route. Create a routing table to direct network workload traffic to the firewall. The
route will be associated with the workload subnet. All traffic from that subnet will be routed to the firewall's
private IP address.
4. Configure an application rule.

In production deployments, a Hub and Spoke model is recommended, where the firewall is in its own VNET,
and workload servers are in peered VNETs in the same region with one or more subnets.

Firewall Rules
There are three kinds of rules that you can configure in the Azure Firewall. Remember, by default, Azure
Firewall blocks all traffic, unless you enable it.

NAT Rules
You can configure Azure Firewall Destination Network Address Translation (DNAT) to translate and filter
inbound traffic to your subnets. Each rule in the NAT rule collection is used to translate your firewall public IP
and port to a private IP and port. Scenarios where NAT rules might be helpful are publishing SSH, RDP, or
non-HTTP/S applications to the Internet. A NAT rule that routes traffic must be accompanied by a matching
network rule to allow the traffic. Configuration settings include:

 Name: A label for the rule.


 Protocol: TCP or UDP.
 Source Address: * (Internet), a specific Internet address, or a CIDR block.
 Destination Address: The external address of the firewall that the rule will inspect.
 Destination Ports: The TCP or UDP ports that the rule will listen to on the external IP address of the
firewall.

15
 Translated Address: The IP address of the service (virtual machine, internal load balancer, and so on)
that privately hosts or presents the service.
 Translated Port: The port that the inbound traffic will be routed to by the Azure Firewall.

Network Rules
Any non-HTTP/S traffic that will be allowed to flow through the firewall must have a network rule. For
example, if if resources in one subnet must communicate with resources in another subnet, then you would
configure a network rule from the source to the destination. Configuration settings include:

 Name: A friendly label for the rule.


 Protocol: This can be TCP, UDP, ICMP (ping and traceroute) or Any.
 Source Address: The address or CIDR block of the source.
 Destination Addresses: The addresses or CIDR blocks of the destination(s).
 Destination Ports: The destination port of the traffic.

Application Rules
Application rules define fully qualified domain names (FQDNs) that can be accessed from a subnet. For
example, specify the Windows Update network traffic through the firewall. Configuration settings include:

 Name: A friendly label for the rule.


 Source Addresses: The IP address of the source.
 Protocol:Port: Whether this is for HTTP/HTTPS and the port that the web server is listening on.
 Target FQDNs: The domain name of the service, such as www.contoso.com. Note that wildcards can
be used. An FQDN tag represents a group of fully qualified domain names (FQDNs) associated with well
known Microsoft services. Example FQDN tags include Windows Update, App Service Environment, and
Azure Backup.

Rule Processing
When a packet is being inspected to determine if it is allowed or not the rules are processed in this order:

1. Network Rules
2. Application Rules (network and application)

The rules are terminating. Once a positive match is found, allowing the traffic through, no more rules are
checked.

Domains and Custom Domains


Initial domain name
By default, when you create an Azure subscription an Azure AD domain is created for you. This instance of the
domain has initial domain name in the form domainname.onmicrosoft.com. The initial domain name, while
fully functional, is intended primarily to be used as a bootstrapping mechanism until a custom domain name is
verified.

16
Custom domain name
Although the initial domain name for a directory can't be changed or deleted, you can add any routable custom
domain name you control. This simplifies the user sign-on experience by allowing user to logon with
credentials they are familiar with. For example, a contosogold.onmicrosoft.com, could be assigned a simpler
custom domain name of contosogold.com.

Practical information about domain names


 Only a global administrator can perform domain management tasks in Azure AD, by default this is the
user who created the subscription.
 Domain names in Azure AD are globally unique. If one Azure AD directory has verified a domain
name, then no other Azure AD directory can verify or use that same domain name.
 Before a custom domain name can be used by Azure AD, the custom domain name must be added to
your directory and verified. This is covered in the next topic.

For more information, Managing custom domain names in your Azure Active Directory.

Verifying Custom Domain Names


When an administrator adds a custom domain name to an Azure AD, it is initially in an unverified state. Azure
AD will not allow any directory resources to use an unverified domain name. This ensures that only one
directory can use a domain name, and the organization using the domain name owns that domain name.

So, after adding the custom domain name, you must demonstrate ownership of the domain name. This is called
verification. and is done by adding a DNS record (MX or TXT) that is provided by Azure into your company’s
DNS zone. Once this record is added, Azure will query the DNS domain for the presence of the record. This
could take several minutes or several hours. If Azure verifies the presence of the DNS record, it will then add
the domain name to the subscription.

17
✔️Notice you can use a TXT or MX record.

Azure DNS Zones


Azure DNS provides a reliable, secure DNS service to manage and resolve domain names in a virtual network
without your needing to add a custom DNS solution.

A DNS zone hosts the DNS records for a domain. So, to start hosting your domain in Azure DNS, you need to
create a DNS zone for that domain name. Each DNS record for your domain is then created inside this DNS
zone.

18
From the portal you can easily add a DNS zone and then view information including name, number of records,
resource group, location (always global), subscription, and name servers.

Considerations
 The name of the zone must be unique within the resource group, and the zone must not exist already.
 The same zone name can be reused in a different resource group or a different Azure subscription.
 Where multiple zones share the same name, each instance is assigned different name server addresses.
 Only one set of addresses can be configured with the domain name registrar.

✔️You do not have to own a domain name to create a DNS zone with that domain name in Azure DNS.
However, you do need to own the domain to configure the domain.

19
DNS Delegation
To delegate your domain to Azure DNS, you first need to know the name server names for your zone. Each
time a DNS zone is created Azure DNS allocates name servers from a pool. Once the Name Servers are
assigned, Azure DNS automatically creates authoritative NS records in your zone.

The easiest way to locate the name servers assigned to your zone is through the Azure portal. In this example,
the zone ‘contoso.net’ has been assigned four name servers: ‘ns1-01.azure-dns.com’, ‘ns2-01.azure-dns.net’,
‘ns3-01.azure-dns.org’, and ‘ns4-01.azure-dns.info’:

Once the DNS zone is created, and you have the name servers, you need to update the parent domain. Each
registrar has their own DNS management tools to change the name server records for a domain. In the
registrar’s DNS management page, edit the NS records and replace the NS records with the ones Azure DNS
created.

✔️When delegating a domain to Azure DNS, you must use the name server names provided by Azure DNS.
You should always use all four name server names, regardless of the name of your domain.

Child Domains
If you want to set up a separate child zone, you can delegate a sub-domain in Azure DNS. For example, after
configuring contoso.com in Azure DNS, you could configure a separate child zone for partners.contoso.com.

20
Setting up a sub-domain follows the same process as typical delegation. The only difference is that NS records
must be created in the parent zone contoso.com in Azure DNS, rather than in the domain registrar.

✔️The parent and child zones can be in the same or different resource group. Notice that the record set name in
the parent zone matches the child zone name, in this case partners.

DNS Record Sets


It's important to understand the difference between DNS record sets and individual DNS records. A record set is
a collection of records in a zone that have the same name and are the same type.

You can add up to 20 records to any record set. A record set cannot contain two identical records. Empty record
sets (with zero records) can be created, but do not appear on the Azure DNS name servers. Record sets of type
CNAME can contain one record at most.

The Add record set page will change depending on the type of record you select. For an A record, you will
need the TTL (Time to Live) and IP address. The time to live, or TTL, specifies how long each record is cached
by clients before being requeried.

21
DNS for Private Domains
By using private DNS zones, you can use your own custom domain names rather than the Azure-provided
names available today. Using custom domain names helps you to tailor your virtual network architecture to best
suit your organization's needs. It provides name resolution for virtual machines (VMs) within a virtual network
and between virtual networks. Additionally, you can configure zones names with a split-horizon view, which
allows a private and a public DNS zone to share the name.

22
If you specify a registration virtual network, the DNS records for the VMs from that virtual network that are
registered to the private zone are not viewable or retrievable from the Azure Powershell and Azure CLI APIs,
but the VM records are indeed registered and will resolve successfully.

Azure DNS benefits


 Removes the need for custom DNS solutions. Previously, many customers created custom DNS
solutions to manage DNS zones in their virtual network. You can now perform DNS zone management by
using the native Azure infrastructure, which removes the burden of creating and managing custom DNS
solutions.
 Use all common DNS records types. Azure DNS supports A, AAAA, CNAME, MX, PTR, SOA, SRV,
and TXT records.
 Automatic hostname record management. Along with hosting your custom DNS records, Azure
automatically maintains hostname records for the VMs in the specified virtual networks. In this scenario,
you can optimize the domain names you use without needing to create custom DNS solutions or modify
applications.
 Hostname resolution between virtual networks. Unlike Azure-provided host names, private DNS
zones can be shared between virtual networks. This capability simplifies cross-network and service-
discovery scenarios, such as virtual network peering.
 Familiar tools and user experience. To reduce the learning curve, this new offering uses well-
established Azure DNS tools (PowerShell, Azure Resource Manager templates, and the REST API).
 Split-horizon DNS support. With Azure DNS, you can create zones with the same name that resolve to
different answers from within a virtual network and from the public internet. A typical scenario for split-
horizon DNS is to provide a dedicated version of a service for use inside your virtual network.
 Available in all Azure regions. The Azure DNS private zones feature is available in all Azure regions
in the Azure public cloud.

Private Zone scenarios


Scenario 1: Name resolution scoped to a single virtual network
In this scenario, you have a virtual network in Azure that has a number of Azure resources in it, including
virtual machines (VMs). You want to resolve the resources from within the virtual network via a specific

23
domain name (DNS zone), and you need the name resolution to be private and not accessible from the internet.
Furthermore, for the VMs within the VNET, you need Azure to automatically register them into the DNS zone.

In this scenario, VNET1 contains two VMs (VM1 and VM2). Each of these VMs have Private IPs. So, if you
create a Private Zone named contoso.com and link this virtual network as a Registration virtual network, Azure
DNS will automatically create two A records in the zone. Now, DNS queries from VM1 to resolve
VM2.contoso.com will receive a DNS response that contains the Private IP of VM2. Furthermore, a Reverse
DNS query (PTR) for the Private IP of VM1 (10.0.0.1) issued from VM2 will receive a DNS response that
contains the FQDN of VM1, as expected.

Scenario 2: Name resolution for multiple networks


Name resolution across multiple virtual networks is is probably the most common usage for DNS private zones.
The following diagram shows a simple version of this scenario where there are only two virtual networks -
VNet1 and VNet2.

 VNet1 is designated as a Registration virtual network and VNET2 is designated as a Resolution virtual


network.
 The intent is for both virtual networks to share a common zone contoso.com.
 The Resolution and Registration virtual networks are linked to the zone.
 DNS records for the Registration VNet VMs are automatically created. You can manually add DNS
records for VMs in the Resolution virtual network.

With this setup, you will observe the following behavior for forward and reverse DNS queries:

1. DNS queries across the virtual networks are resolved. A DNS query from a VM in the Resolution
VNet, for a VM in the Registration VNet, will receive a DNS response containing the Private IP of VM.

24
2. Reverse DNS queries are scoped to the same virtual network. A Reverse DNS (PTR) query from a
VM in the Resolution virtual network, for a VM in the Registration VNet, will receive a DNS response
containing the FQDN of the VM. But, a reverse DNS query from a VM in the Resolution VNet, for a VM
in the same VNet, will receive NXDOMAIN.

✔️There is also Split-Horizon functionality scenario.

Demonstration - DNS Name Resolution


In this demonstration, you will explore Azure DNS.

Note: There is a DNS lab.

Create a DNS zone

1. Access the Azure Portal.


2. Search for the DNS zones service.
3. On the Create DNS zone blade enter the following values, and Create the new DNS zone.
 Name: contoso.internal.com
 Subscription: <your subscription>
 Resource group: Select or create a resource group
 Location: Select your Location
4. Wait for the DNS zone to be created.
5. You may need to Refresh the page.

Add a DNS record set

1. Select +Record Set.
2. Use the Type drop-down to view the different types of records.
3. Notice how the required information changes as you change record types.
4. Change the Type to A and enter these values.
 Name: ARecord
 IP Address: 1.2.3.4
5. Notice you can add other records.
6. Click OK to save your record.
7. Refresh the page to observe the new record set.
8. Make a note of your resource group name.

Use PowerShell to view DNS information

1. Open the Cloud Shell.


2. Get information about your DNS zones. Notice the name servers and number of record sets.
Get-AzDnsZone-Name "contoso.internal.com"-
ResourceGroupName<resourcegroupname>

3. Get information about your DNS record set.


Get-AzDnsRecordSet-ResourceGroupName<resourcegroupname>-ZoneName
contoso.internal.com

View your name servers

1. Access the Azure Portal and your DNS zone.


2. Review the Name Server information. There should be four name servers.

25
3. Make a note of the resource group.
4. Open the Cloud Shell.
5. Use PowerShell to confirm your NS records.
# Retrieve the zone information
$zone = Get-AzDnsZone –Name contoso.internal.com –
ResourceGroupName<resourcegroupname>

# Retrieve the name server records


Get-AzDnsRecordSet –Name “@” –RecordType NS –Zone $zone

Test the resolution

1. Continue in the Cloud Shell.


2. Use a Name Server in your zone to review records.
nslookup arecord.contoso.internal.com <name server for the zone>

3. Nslookup should provide the IP address for the record.

Explore DNS metrics

1. Return to the Azure portal.


2. Select a DNS zone, and then select Metrics.
3. Use the Metrics drop-down to view the different metrics that are available.
4. Select Query Volume. If you have been using nslookup, there should be queries.
5. Use the Line Chart drop-down to observe other chart types, like Area Chart, Bar Chart, and Scatter
Chart.

For more information, Nslookup

Lab 04 - Implement Virtual Networking


Lab scenario
You need to explore Azure virtual networking capabilities. To start, you plan to create a virtual network in
Azure that will host a couple of Azure virtual machines. Since you intend to implement network-based
segmentation, you will deploy them into different subnets of the virtual network. You also want to make sure
that their private and public IP addresses will not change over time. To comply with Contoso security
requirements, you need to protect public endpoints of Azure virtual machines accessible from Internet. Finally,
you need to implement DNS name resolution for Azure virtual machines both within the virtual network and
from Internet.

26
Objectives
In this lab, you will:

27
 Task 1: Create and configure a virtual network.
 Task 2: Deploy virtual machines into the virtual network.
 Task 3: Configure private and public IP addresses of Azure VMs.
 Task 4: Configure network security groups.
 Task 5: Configure Azure DNS for internal name resolution.
 Task 6: Configure Azure DNS for external name resolution.

✔️Consult with your instructor for how to access the lab instructions and lab environment (if provided).

Module 04 Review Questions


Review Question 1
Your company has an existing Azure tenant named alpineskihouse.onmicrosoft.com. The company wants to
start using alpineskihouse.com for their Azure resources. You add a custom domain to Azure.
Now, you need to add a DNS record to prepare for verifying the custom domain. Which two of the following
record types could you create?

 Add an PTR record to the DNS zone.

 Add a TXT record to the DNS zone.

 Add an MX record to the DNS zone.

 Add an SRV record to the DNS zone.

 Add a CNAME record to the DNS zone.

Explanation

By default, Azure will prompt you to create a custom TXT record in your DNS zone to verify a custom domain.
Optionally, you can use an MX record instead. The result is the same. Other record types are not supported.

Check Answers

Review Question 2
You are planning to configure networking in Microsoft Azure. Your company has a new Microsoft Azure
presence with the following network characteristics:

 1 Virtual Network.
 1 subnet using 192.168.0.0/23 (does not have existing resources).

Your on-premises data center has the following network characteristics:

 10 subnets using 192.168.1.0/24 through 192.168.10.0/24.

The company intends to use 192.168.1.0/24 on-premises and 192.168.0.0/24 in Azure. You need to update your
company's environment to enable the needed functionality. What should you do? (Each answer represents part
of the solution. Choose two.)

28
 Delete 192.168.0.0/23 from Azure.

 Delete 192.168.1.0/24 in the on-premises environment.

 Create a matching public subnet in Azure and in the on-premises environment.

 Create a subnet for 192.168.0.0/23 in the on-premises environment.

 Create a subnet for 192.168.0.0/24 in Azure.

Explanation

First, you need to delete 192.168.0.0/23 from Azure. It overlaps with 192.168.1.0/24, which you intend to use
for on-premises. Second, you need to create a subnet for 192.168.0.0/24 in Azure to enable usage in Azure.

Check Answers

Review Question 3
You are planning your Azure network implementation to support your company's migration to Azure. Your first
task is to prepare for the deployment of the first set of VMs. The first set of VMs that you are deploying have
the following requirements:

 Consumers on the internet must be able to communicate directly with the web application on the VMs.
 The IP configuration must be zone redundant.

You need to configure the environment to prepare for the first VM. Additionally, you need to minimize costs,
whenever possible, while still meeting the requirements. What should you do? Select one.

 Create a standard public IP address. During the creation of the first VM, associate the public IP address with
the VM's NIC.

 Create a standard public IP address. After the first VM is created, remove the private IP address and assign
the public IP address to the NIC.

 Create a basic public IP address. During the creation of the first VM, associate the public IP address with the
VM.

 Create a basic public IP address. After the first VM is created, remove the private IP address and assign the
public IP address to the NIC.

Explanation

To meet the requirement of communicating directly with consumers on the internet, you must use a public IP
address. To meet the requirement of having a zone redundant configuration, you must use a standard public IP
address. Of the answer choices, only the answer that creates the standard public IP address first, then associates
it during VM creation, functions and meets the requirements. You cannot configure a VM with only a public IP
address. Instead, all VMs have a private IP address and can optionally have one or more public IP addresses.

Check Answers

29
Review Question 4
You deploy a new domain named contoso.com to domain controllers in Azure. You have the following domain-
joined VMs in Azure:

 VM1 at 10.20.30.10
 VM2 at 10.20.30.11
 VM3 at 10.20.30.12
 VM99 at 10.20.40.101

You need to add DNS records so that the hostnames resolve to their respective IP addresses. Additionally, you
need to add a DNS record so that intranet.contoso.com resolves to VM99. What should you do? (Each answer
presents part of the solution. Choose two.)

 Add AAAA records for each VM.

 Add A records for each VM.

 Add a TXT record for intranet.contoso.com with the text of VM99.contoso.com.

 Add an SRV record for intranet.contoso.com with the target pointing at VM99.contoso.com

 Add a CNAME record for intranet.contoso.com with a value of VM99.contoso.com.

Explanation

In this scenario, the hostnames have IPv4 IP addresses. Thus, to resolve those hostnames, you must add A
records for each of the VMs. To enable intranet.contoso.com to resolve to VM99.contoso.com, you need to add
a CNAME record. A CNAME record is often referred to as an “alias”.

Check Answers

Review Question 5
Your company is preparing to move some services and VMs to Microsoft Azure. The company has opted to use
Azure DNS to provide name resolution. A project begins to configure the name resolution. The project
identifies the following requirements:

 A new domain will be used.


 The domain will have DNS records for internal and external resources.
 Minimize ongoing administrative overhead.

You need to prepare and configure the environment with a new domain name and a test hostname of WWW.
Which of the following steps should you perform? (Each answer presents part of the solution. Choose three.)

 Register a domain name with a domain registrar.

 Register a domain name with Microsoft Azure.

30
 Delegate the new domain name to Azure DNS.

 Add an Address (A) record for Azure name servers in the zone.

 Add DNS glue records to point to the Azure name servers.

 Add a record for WWW.

Explanation

For private domain names, you must register with a registrar because Azure isn't a registrar. Thereafter, you
need to delegate the new domain name to Azure DNS, which enables Azure DNS to be authoritative for the
domain. After delegation, you should add a test hostname of WWW and test name resolution.

Check Answers

Review Question 6
You have a VM with two NICs named NIC1 and NIC2. NIC1 is connected to the 10.10.8.0/24 subnet. NIC2 is
connected to the 10.20.8.0/24 subnet. You plan to update the VM configuration to provide the following
functionality:

 Enable direct communication from the internet to TCP port 443.


 Maintain existing communication across the 10.10.8.0/24 and 10.20.8.0/24 subnets.
 Maintain a simple configuration whenever possible.

You need to update the VM configuration to support the new functionality. What should you do? Select one.

 Remove the private IP address from NIC2 and then assign a public IP address to it. Then, create an inbound
security rule.

 Add a third NIC and associate a public IP address to it. Then, create an inbound security rule.

 Associate a public IP address to NIC2 and create an inbound security rule.

 Create an inbound security rule for TCP port 443.

Explanation

To enable direct communication from the internet to the VM, you must have a public IP address. You also need
an inbound security rule. You can associate the public IP address with NIC1 or NIC2, although this scenario
only presents an option to associate it with NIC2 so that is the correct answer.

Check Answers

Review Question 7
You're currently using network security groups (NSGs) to control how your network traffic flows in and out of
your virtual network subnets and network interfaces. You want to customize how your NSGs work. For all

31
incoming traffic, you need to apply your security rules to both the virtual machine and subnet level.
Which of the following options will let you accomplish this? (Choose two)

 Configure the AllowVNetInBound security rule for all new NSGs.

 Create rules for both NICs and subnets with an allow action.

 Delete the default rules.

 Add rules with a higher priority than the default rules.

Explanation

You should add rules with a higher priority than the default rules if needed, as you cannot delete the default
rules. Also, in order to meet the requirement to apply security rules to both VM and subnet level, you should
create rules with an allow action for both. There is no need to configure the AllowVnetInBound rule as it as a
default rule for any new security group you create.

Check Answers

Review Question 8
You need to ensure that Azure DNS can resolve names for your registered domain. What should you
implement? Select one.

 zone delegation

 a CNAME record

 an MX record

 a secondary zone

 a primary zone with a NS record

Explanation

Once you create your DNS zone in Azure DNS, you need to set up NS records in the parent zone to ensure that
Azure DNS is the authoritative source for name resolution for your zone. For domains purchased from a
registrar, your registrar will offer the option to set up these NS records. When delegating a domain to Azure
DNS, you must use the name server names provided by Azure DNS. Domain delegation does not require the
name server name to use the same top-level domain as your domain.

Check Answers

Review Question 9
You are configuring the Azure Firewall. You need to allow Windows Update network traffic through the
firewall. Which of the following should you use?

32
 Application rules

 Destination inbound rules

 NAT rules

 Network rules

Explanation

Application rules. Application rules define fully qualified domain names (FQDNs) that can be accessed from a
subnet. That would be appropriate to allow Windows Update network traffic.

Check Answers

Additional Study
Microsoft Learn provides self paced skills training on a variety of topics. These Learn modules cover the
content you have just learned. You can search for additional modules by product, role, or level.

 Networking Fundamentals - Principals


 Design an IP addressing schema for your Azure deployment
 Secure and isolate access to Azure resources by using network security groups and service endpoints

33

You might also like