Category: AZ-700

Notes from MS Learn AZ-700 Module 1: Introduction to Azure Virtual Networks – Unit 6: Exercise – Configure Domain Name Servers Settings in Azure

Create Private DNS zone and link VNets for registration and resolution. Test with two created VMs

Tasks (taken from MS Learn: Items without “Task” in front of them are personal additions)

• Task 1: Create a private DNS Zone.
  • Search Private DNS Zones
  • Create
  • Select Resource Group and Create Name
  • Review & Create – Create
  • Go to resource to verify
• Task 2: Link the subnet for auto registration.
  • Under Private DNS Zone resource created select “Virtual network links”
  • Click Add
  • Add link name
  • Select VNet
  • Check “Enable auto registration” box
  • Okay
  • Repeat for additional VNets
• Task 3: Test the environment.
  • Use Azure PowerShell to deploy the template to create VMs.
    • Open Powershell (Cloud Shell button next to search bar in Azure Portal)
    • Upload template files (Upload/Download files button in PowerShell menu bar)
    • Verify Subscription
      • az account show –output table
    • Set subscription in PowerShell
      • az account set –subscription “Subscription Name”
    • Deploy ARM template to create VMs
      • $RGName = “ResourceGroupName”
      • New-AzResourceGroupDeployment – ResourceGroupName $RGName – TemplateFile templatename.json – TemplateParameterFile templatefilename.parameters.json
    • Return to Azure Portal to verify VM’s created
      • Search “Virtual Machines” in Portal
      • Select Virtual machines
• Task 4: Verify records are present in the DNS zone and VMs function properly.
  • Search for Private DNS Zones in Azure Portal search bar
  • Select Private DNS Zones
  • Select Private DNS Zone created earlier
  • Verify A records exist for newly created VMs
  • Search Virtual Machines in Azure Portal search bar
  • Select Virtual machines
  • Select VM
    • In VM bar select Connect > RDP
    • Download RDP File
    • In right panel select Open File
    • Select Connect
    • Enter VM Username and Password and select OK
    • Open command prompt once connected to VM RDP session
    • Verification
      • ipconfig /all
      • Ping another VM by name to verify name resolution
      • nslookup othervmname.domain.com

Notes from MS Learn AZ-700 Module 1: Introduction to Azure Virtual Networks – Unit 5: Design Name Resolution for your Virtual Network

DNS Services accessible from your own internal networks:

• Public DNS resolve names and IP’s for resources and services accessible over the internet E.g. Web Servers.
  • Azure DNS is a hosting service for DNS domain that provides name resolution using Azure infrastructure.
  • Host on Azure global network of DNS servers.
  • Utilizes Anycast Networking where each query is sent to closest DNS Server

• Create address records manually in relevant zones. Examples:
  • Host record – A/AAAA (IPv4/IPv6)
  • Alias record – CNAME

• Azure DNS provides resolution in a VNet without need for custom DNS solution
• DNS zone hosts DNS records for domain. Need to create a DNS zone for domain. Records for that domain then created inside the zone

• Considerations:
  • Zone name must be unique within the resource group and must not already exist
  • Same zone name can be reused in different resource group or subscription
  • When multiple zones share same name, each is assigned different name server address
  • Root/Parent domain is registered at registrar and point to Azure NS
  • Child domains registered in AzureDNS directly

• Delegate DNS Domains:
  • To delegate domain to Azure DNS must know name server name for your zone
  • Each DNS zone created is allocated an Azure DNS name server from pool
  • Once Name Server assigned, Azure DNS creates authoritative NS records in zone
  • Once DNS zone created, and have name servers, update the parent domain
  • Each registrar has own DNS management tools to change name server records – edit NS records and replaces with Azure DNS created ones
  • Always use all four name servers when delegating

• Child Domains E.g. partners.contoso.com (taken from MS Learn):
  • Same process as typical delegations
  • Can be in same or different resource group as parent domain
  • Record set is collection of records in a zone that have same name and type
  • Record set can’t contain two identical records.
  • Empty record sets can be created but don’t appear on Azure DNS name servers
  • CNAME Record sets can only have one record
  • A records require TTL and IP address

• Private DNS services resolve names and IP address for resources and services
  • When resource deployed in VNet and need to resolve to internal IP they use:
    • Azure DNS Private Zones
    • Azure-provided name resolution
    • Your own DNS server

• Can use recursive where a DC in Azure can respond to DNS for its domain and forward other queries to Azure
  • VMs can see both private DC and Azure forwarder
  • Access to recursive resolvers in Azure via 168.63.129.16
• Forwarding also enables DNS resolution between VNets and allows on prem machines to resolved Azure host names
  • DNS server VM must reside in the same VNet and configured to forward host name queries to Azure
  • DNS suffix different in each VNet use conditional forwarding rules to send DNS query to correct VNet for resolution.

• Azure provided DNS
  • Azure provides free default internal DNS
  • Only basic authoritative DNS capabilities
  • If used, DNS zone names and records automatically managed by Azure. No control over zone names or life cycle of records
  • Internal DNS namespace: .internal.cloudapp.net
  • VM created in VNet registered in internal DNS zone get name similar to myVM.internal.cloudapp.net (taken from MS Learn)
  • Is Azure Resource name registered not guest OS name on VM
  • Limitations of Internal DNS
    • No resolution across VNets
    • Resource names no guest OS names registered
    • No manual records

• Azure Private DNS Zones
  • Available only to internal resources
  • Global in scope = access from any region, subscription, VNet, tenant
  • If permission to read zone, can use for DNS resolution
  • Highly resilient, replicated to regions all throught world
  • Not available to internet resources

• Custom Private DNS Zones can:
  • Configure specific DNS name for zone
  • Create records manually
  • Resolve names and IPs across zones
  • Resolve names and IPs across VNets
  • Can also use autoregistration which creates record based on Azure resource name

• Link VNets to Private DNS Zone
  • At VNet level default DNS is part of DHCP assignments by Azure specifying 168.63.129.16 for Azure DNS
  • Override at VM NIC
  • Linking VNets options:
    • Registration – Each can link 1 private DNS zone, up to 100 VNets. Linkable to same zone
    • Resolution – Other private DNS zones for different namespaces
      • Link VNet to each for name resolution
      • VNet can link up to 1000 private Zones for resolution

• Integration to on-prem DNS with VNets
  • External DNS (On-prem) can run any DNS Server e.g. BIND, AD DNS
  • Often use Azure private DNS zone for auto registration and custom config to forward queries to external zones to external DNS Server
  • Forwarding:
    • Forwarding specifies another DNS server (SOA for zone) to resolve query initial server can’t
    • Conditional forwarding specifies DNS server for a named zone so all queries for that zone sent to specific DNS Server

Notes from MS Learn AZ-700 Module 1: Introduction to Azure Virtual Networks – Unit 4: Exercise – Design and Implement a Virtual Network in Azure

Create VNets and Subnets in Azure Portal:

• Create Resource Group
• Create First VNet Name
  • Add Addresses
    • Add Subnets under VNet
      • Select – Review and Create
      • Select Create if validation succeeds

• Repeat for each VNet required
• Verify Resources Created
  • All Resources under menu
    • Select VNet
      • Select Subnets Under Settings
        • Verify Subnets and address ranges

Notes from MS Learn AZ-700 Module 1: Introduction to Azure Virtual Networks – Unit 3: Configure Public IP Services

To allow public networks such as the internet to communicate with Azure resources you must use a public IP in use along with the private Azure IP.

A public IP in Azure is dedicated to a specific resource. Resources without public IP’s can communicate outbound through NAT with a non-dedicated IP

• Azure Resource Manager is where a Public IP has it’s own properties. Example resources that can be assigned a Public IP:
  • VM Interfaces
  • VM Scale Sets
  • Public Load Balancers
  • VPN Gateways
  • NAT Gateways
  • App Gateways
  • Azure FW
  • Bastion Hosts
  • Route Servers

• Public IP’s can be either IPv4 or IPv6 of different types:
  • Dynamic Public IP
    • Assigned automatically for example when VM created or started
    • Released automatically for example when VM stopped or deleted
    • Default allocation method within region
  • Static Public IP
    • Assigned and doesn’t change
    • Set allocation method to static
    • Released only when resource deleted or Allocation method changed to dynamic

SKU Table: Taken from MS Learn

Create a Public IP Address Prefix:

• Public IP Prefixes are assigned from a pool in an Azure Region
• Specify name and prefix size
• IPv4 or IPv6
• In Availability Zones: create as zone-redundant or associate with specific availability zone
• After prefix is created you can create public IP addresses

Custom IP Address Prefix (BYOIP)

• Used the same was as Azure owned public IP address prefixes
• Can be associated with Azure resources, interact with internal/private Ips and VNets, as well as reach external destinations outbound from Azure WAN

Notes from MS Learn AZ-700 Module 1: Introduction to Azure Virtual Networks – Unit 2: Explore Azure Virtual Networks

Overview:

Azure Virtual Networks = VNets

Mimic on-premises networks with Azure infrastructure benefits such as scale, availability, and isolation

VNets have their own CIDR and can be linked to other Vnets and on-prem networks as long as they don’t overlap.

Vnets offer control of DNS server settings and segmentation in to subnets

Capabilities:

• Communication with internet by default outbound
• Inbound requires assigning a public IP or public Load Balancer which can also be used for outbound connections
• Communication between Azure resources
  • VNets
  • VNet service endpoints
  • VNet peering
• Can connect not just to VM’s but also Azure resources such as:
  • App Service. Environment
  • Azure Kubernetes Service
  • Azure Virtual Machine Scale Sets
• Service Endpoints can connect to Azure resource types such as:
  • Azure SQL database
  • Azure storage accounts
• Communication between on-prem resources
  • Extend using Point-to-site VPN
  • Azure ExpressRoute
• Filter network traffic
  • Network security groups
  • Network virtual appliances
• Routing network traffic
  • Azure routes between subnets, connected virtual networks, on-prem networks, and internet by default.
  • Create route tables or BGP routes to override the default Azure created routes

VNET Design Conderations:

• Create multiple virtual networks per region per subscription. Multiple subnets within each VNet

• Virtual Networks:
• • Use RFC 1918 rages
    • 10.0.0.0-10.255.255.255 (10/8)
    • 172.16.0.0-172.31.255.255 (172.16/12)
    • 192.168.0.0-192.168.255.255 (192.168/16)
  • Additional Ranges
    • 224.0.0.0/4 (Multicast)
    • 255.255.255.255/32 (Broadcast)
    • 127.0.0.0/8 (Loopback)
    • 169.254.0.0/16 (Link-local)
    • 168.63.129.16/32 (Internal DNS)

• Azure assigns resources IP’s from address space provisioned. Azure reserves the first 4 and last IP.
  • x.x.x.0-x.x.x.3 as well as the last address is the subnet

• When planning consider:
  • No overlapping address space with other networks
  • Is security isolation required
  • Need to mitigate IP limitations
  • Connections between Azure VNets and On-prem
  • Isolation requirements for admin purposes
  • Use of Azure services that create their own VNets

• Subnets
  • Range of IP addresses in a VNet. You can segment VNet into difference size subnets within subscription limit.

• Smallest supported is /29 and largest is /2.

• For IPv6 must be exactly /64

• Considerations:
  • Each subnet must have unique address range in CIDR format
  • Certain Azure services require their own subnet
  • Can be used for traffic management
  • Can limit access to Azure resources to specific subnets with virtual network service endpoint. Can create multiple subnets and enable service endpoint for some subnets and not others.

Determine a naming convention:

• Example (taken from MS Learn)
  • Pip-sharepoint-prod-westus-001
  • Resource Type-Workload/App-Environment-Region-Instance

• Azure resource types have a scope that defines level resource must be unique
  • Management group
  • Subscription
  • Resource group
  • Resource

Regions and Subscriptions:

• Resource can only be created in a VNet that exists in the same region and subscription as the resource
• You can connect VNets that exist in different subscriptions and regions
• Deploy as many VNets as needed up to subscription limit

• Azure Availability Zones
• • Enables you to define unique physical locations with in a region. Zone is made up of one or more datacenters with independent power, cooling, networking.
  • Consider availability zones when designing Azure network and plan for services that support them.
  • Availability Zone categories:
    • Zonal services = Resources pinned to a specific zone
    • Zone-redundant services = Resources replicated/distributed across zones automatically.
      • Azure replicated across three zones for failure resiliency
    • Nonregional services = Service available from geographies is resilient to zone-wide outages