This chapter covers Azure DNS and Azure Load Balancer, two fundamental networking services that ensure your applications are reachable and resilient. For the AZ-900 exam, this falls under Objective 2.3: Describe core Azure architecture services. While these specific services are not heavily weighted, understanding them is crucial for grasping how Azure handles name resolution and traffic distribution. Expect 1-2 questions on the exam that test your ability to distinguish between Azure DNS, Azure Load Balancer, and other networking services like Traffic Manager and Application Gateway.
Jump to a section
Imagine a large airport. When you book a flight, you don't call the airport operator to find the gate; you use a flight number. Azure DNS works like the airport's flight information display system: it translates the airline and flight number (your domain name, like www.contoso.com) into a specific gate number (an IP address, like 40.112.50.200). The system is globally distributed, with many screens (DNS servers) worldwide, so any traveler can see the gate instantly. Now, when hundreds of passengers arrive at the same gate, they need to get their luggage. Instead of one baggage carousel that would be overwhelmed, the airport uses multiple carousels (load balancers) that distribute passengers evenly. If one carousel breaks, the airport directs passengers to another. Azure Load Balancer works like that: it spreads incoming traffic across multiple servers (VMs) to prevent overload and ensures availability by rerouting traffic if a server fails. The load balancer also performs health checks, like an agent checking if a carousel is moving properly. If a carousel stops, the airport stops sending luggage there until it's fixed. This analogy captures the essence: DNS is the lookup service (name to IP), and the load balancer is the traffic distributor that ensures no single server gets too many requests.
What Are Azure DNS and Azure Load Balancer?
Azure DNS is a hosting service for DNS domains that provides name resolution using Microsoft Azure infrastructure. It allows you to manage your DNS records using the same credentials, APIs, and billing as your other Azure services. The business problem it solves: without DNS, users would have to remember numeric IP addresses to access websites. Azure DNS translates human-readable domain names (like www.contoso.com) into IP addresses (like 40.112.50.200) that computers use to communicate.
Azure Load Balancer is a Layer 4 (TCP/UDP) load balancer that distributes incoming traffic among healthy virtual machines (VMs) in a backend pool. It solves the problem of single points of failure and performance bottlenecks. By spreading traffic, it increases availability and scalability. It operates at the transport layer, meaning it doesn't inspect the content of packets; it simply forwards them based on rules.
How They Work – Step by Step
Azure DNS: 1. You create a DNS zone (e.g., contoso.com) in Azure. 2. You add DNS records (A, AAAA, CNAME, MX, etc.) to map names to IP addresses. 3. Azure hosts the authoritative DNS servers for your domain. These servers are globally distributed and highly available, with a 100% SLA for name resolution queries. 4. When a user types your domain name, their internet service provider (ISP) queries Azure DNS servers, which respond with the IP address. 5. Azure DNS supports alias records that can point to Azure resources like Traffic Manager profiles or CDN endpoints, automatically updating if the resource IP changes.
Azure Load Balancer: 1. You configure a frontend IP address (public or private) that clients connect to. 2. You define a backend pool of VMs (or other resources) that will receive traffic. 3. You create load balancing rules that specify how traffic is distributed (e.g., all TCP port 80 traffic goes to backend pool on port 80). 4. The load balancer uses a five-tuple hash (source IP, source port, destination IP, destination port, protocol) to map connections to a specific backend server. This ensures session persistence (stickiness) without cookies. 5. Health probes are configured to check if backend VMs are responsive. If a VM fails a health probe, the load balancer stops sending new traffic to it until it recovers.
Key Components, Tiers, and Pricing
Azure DNS: - DNS zones: Hosted zones for domain management. Can be public or private (for virtual networks). - Record sets: Collections of records with the same name and type. - Alias records: Point to Azure resources; automatically update when the resource IP changes. - Pricing: Based on the number of DNS zones and queries. The first 25 million queries per month are free. After that, per million queries.
Azure Load Balancer: - Frontend IP configuration: Public or private IP address. - Backend pool: Set of VMs or VM scale sets. - Health probes: TCP, HTTP, or HTTPS probes that check backend health. - Load balancing rules: Map frontend port to backend port with distribution settings. - Inbound NAT rules: Forward traffic to a specific VM (e.g., RDP on port 3389). - SKUs: Basic (free, no SLA, limited features) and Standard (paid, 99.99% SLA, zone-redundant, outbound SNAT). - Pricing: Standard Load Balancer charges per rule (first 5 rules free) and per processed data. Basic is free.
Comparison to On-Premises Equivalents
On-premises DNS typically involves running Windows Server DNS or BIND on physical or virtual servers. This requires managing failover, patching, and capacity planning. Azure DNS is fully managed: no servers to maintain, automatic high availability, and global presence. Similarly, on-premises load balancers (e.g., F5, Citrix ADC) are hardware appliances that require capital expenditure, complex configuration, and manual scaling. Azure Load Balancer is a software-defined, pay-as-you-go service that can scale instantly. It integrates natively with Azure VMs and availability sets.
Azure Portal and CLI Touchpoints
Azure DNS: - In the portal: Create a DNS zone under "All services" > "DNS zones". Add record sets by clicking "+ Record set". - CLI example to create a zone:
az network dns zone create -g MyResourceGroup -n contoso.comCLI example to add an A record:
az network dns record-set a add-record -g MyResourceGroup -z contoso.com -n www -a 40.112.50.200Azure Load Balancer: - In the portal: Create a load balancer under "All services" > "Load balancers". Configure frontend IP, backend pool, health probes, and rules. - CLI example to create a public Standard Load Balancer:
az network lb create -g MyResourceGroup -n MyLB --sku Standard --public-ip-address MyPublicIP --frontend-ip-name MyFrontEnd --backend-pool-name MyBackendPoolCLI example to create a health probe:
az network lb probe create -g MyResourceGroup --lb-name MyLB -n MyProbe --protocol tcp --port 80CLI example to create a load balancing rule:
az network lb rule create -g MyResourceGroup --lb-name MyLB -n MyRule --protocol tcp --frontend-port 80 --backend-port 80 --frontend-ip-name MyFrontEnd --backend-pool-name MyBackendPool --probe-name MyProbeCreate a DNS zone
In the Azure portal, go to 'DNS zones' and click 'Create'. Provide a resource group and zone name (e.g., contoso.com). Azure automatically assigns four authoritative name servers (e.g., ns1-04.azure-dns.com). You must update your domain registrar's NS records to point to these Azure DNS servers. This delegates authority to Azure. Behind the scenes, Azure provisions the zone on globally replicated DNS servers, ensuring high availability. The zone is now ready to host records.
Add DNS records
Inside the zone, click '+ Record set'. Choose record type (A for IPv4, AAAA for IPv6, CNAME for aliases, MX for mail exchange, etc.). For an A record, provide a name (e.g., 'www') and the IP address (e.g., 40.112.50.200). Set TTL (time-to-live) – default 3600 seconds. Lower TTL means faster propagation but more queries. Azure DNS supports alias records for Azure resources – this is important for exam: alias records point to Azure resource IDs, not IPs, and update automatically if the resource IP changes.
Configure Azure Load Balancer frontend
Create a load balancer and assign a frontend IP configuration. Choose public or private. For public, you can create a new public IP address or use an existing one. For Standard SKU, the frontend IP can be zone-redundant (survives zone failure) or zonal (pinned to a specific zone). The frontend IP is the address clients will connect to. For internal load balancing, use a private IP within a virtual network.
Create a backend pool and add VMs
Define a backend pool that contains the VMs receiving traffic. You can add VMs from an availability set or VM scale set. For high availability, VMs should be in an availability set (2-3 fault/update domains) or across availability zones. Each VM must have a network interface attached to the backend pool. The load balancer communicates with VMs via their private IP addresses. Health probes will be sent to these VMs to check their status.
Define health probes
Health probes determine which backend VMs are healthy. You can configure TCP, HTTP, or HTTPS probes. For a TCP probe, the load balancer attempts to establish a TCP connection to the VM on a specified port (e.g., 80). If the connection succeeds, the VM is considered healthy. For HTTP/HTTPS probes, you specify a URL path (e.g., /health) and expect a 200 OK response. Unhealthy VMs are removed from rotation. Probes are sent every 5 seconds (default interval) and timeout after 2 failed attempts (default).
Create load balancing rules
Load balancing rules map frontend traffic to backend VMs. For example, frontend port 80 (HTTP) maps to backend port 80. You also specify the protocol (TCP or UDP), session persistence (None, Client IP, or Client IP and Protocol), and idle timeout (default 4 minutes). For Standard Load Balancer, you can enable Floating IP (Direct Server Return) for scenarios like SQL AlwaysOn. Each rule consumes a rule count; the first 5 rules are free.
Scenario 1: E-commerce website with high traffic An online retailer runs a web application on two VMs in an availability set. They use Azure Load Balancer (Standard SKU) to distribute incoming HTTP/HTTPS traffic. The load balancer's health probe checks the /health endpoint every 5 seconds. During a Black Friday sale, traffic spikes. The load balancer distributes requests evenly, and the backend VMs scale out using VM scale sets (integrated with the load balancer). Cost: Standard Load Balancer charges per rule and data processed; with 10 rules and 100 GB/month, cost is ~$20/month. If misconfigured (e.g., no health probe), a failing VM would still receive traffic, causing errors for users.
Scenario 2: Private internal application A financial services company hosts a three-tier application: web, app, and database. The app tier (internal only) is behind an internal Azure Load Balancer. The load balancer uses a private IP in the virtual network. The app VMs are in different subnets for security. Health probes check TCP port 8080. If an app VM crashes, traffic is redirected to the remaining VMs. This setup ensures high availability without exposing the app tier to the internet. Cost: Basic Load Balancer is free, but Standard provides SLA and zone-redundancy. The company chooses Standard for the 99.99% SLA.
Scenario 3: Global DNS with failover A SaaS provider uses Azure DNS for their domain. They have two data centers – one primary, one disaster recovery. They use Azure Traffic Manager (not Load Balancer) to route users to the nearest healthy endpoint. Azure DNS hosts the domain and alias records pointing to Traffic Manager. When the primary data center fails, Traffic Manager redirects traffic to the DR site. Azure DNS's 100% SLA ensures name resolution is always available. If they had used a single DNS record with a static IP, users would have to wait for DNS propagation (hours) during failover. Alias records solve this by automatically updating when Traffic Manager endpoints change.
Objective 2.3: Describe core Azure architecture services – This includes Azure DNS and Azure Load Balancer, but the exam focuses on understanding their purpose and differentiating them from similar services like Traffic Manager (global DNS load balancing) and Application Gateway (Layer 7 HTTP load balancing).
Common wrong answers and why: 1. 'Azure Load Balancer can route based on URL path.' – False. Load Balancer is Layer 4; it does not inspect HTTP headers. Application Gateway does that. Candidates confuse the two. 2. 'Azure DNS provides a 99.99% SLA.' – False. Azure DNS has a 100% SLA for name resolution queries. Candidates often assume all Azure services have 99.99%. 3. 'Azure Load Balancer Basic SKU supports availability zones.' – False. Only Standard SKU supports zones. Basic is free but lacks zone-redundancy and SLA. 4. 'Azure DNS can host private domains for free.' – False. Private DNS zones are billed the same as public zones.
Specific terms and values: - SLA for Azure DNS: 100% for name resolution. - SLA for Standard Load Balancer: 99.99% for data path availability. - Basic Load Balancer: no SLA. - Ports: Load Balancer frontend ports must be unique per rule (no overlapping ranges). - Health probe interval: default 5 seconds, timeout after 2 failures. - Distribution algorithm: five-tuple hash (source IP, source port, destination IP, destination port, protocol).
Edge cases and tricky distinctions: - Alias records vs. CNAME: Alias records can point to Azure resources and coexist with other records at the zone apex (e.g., contoso.com). CNAME cannot be at the apex. - Internal Load Balancer vs. Public Load Balancer: Internal is for traffic within a virtual network; public is for internet-facing traffic. - Load Balancer vs. Traffic Manager: Load Balancer distributes traffic within a region; Traffic Manager distributes traffic across regions (global). - Load Balancer vs. Application Gateway: Load Balancer is Layer 4; Application Gateway is Layer 7 with SSL termination, URL-based routing, and WAF.
Memory trick: - 'L4 Load Balancer, L7 App Gateway' – Think of the OSI model: Layer 4 (transport) vs Layer 7 (application). - 'DNS is the phonebook, Load Balancer is the traffic cop.' - For decision tree: If you need to distribute traffic within one region, use Load Balancer. If across regions, use Traffic Manager. If you need HTTP-specific features (SSL offload, URL routing), use Application Gateway.
Azure DNS is a hosting service for DNS domains with a 100% SLA for name resolution.
Alias records in Azure DNS can point to Azure resources and update automatically if the resource IP changes.
Azure Load Balancer operates at Layer 4 (TCP/UDP) and distributes traffic within a single region.
Standard Load Balancer has a 99.99% SLA and supports availability zones; Basic has no SLA.
Health probes in Load Balancer can be TCP, HTTP, or HTTPS; default interval is 5 seconds.
Load Balancer uses a five-tuple hash (source IP, source port, dest IP, dest port, protocol) for distribution.
Internal Load Balancer is for private traffic within a VNet; Public Load Balancer is for internet-facing traffic.
Azure DNS private zones allow name resolution within virtual networks without internet exposure.
These come up on the exam all the time. Here's how to tell them apart.
Azure Load Balancer
Layer 4 (TCP/UDP) load balancer
Does not inspect HTTP headers
No SSL termination
Distributes traffic within a region
Uses five-tuple hash for distribution
Azure Application Gateway
Layer 7 (HTTP/HTTPS) load balancer
Can route based on URL path, host headers
SSL termination supported
Can be regional or global (via WAF)
Supports cookie-based session affinity
Mistake
Azure DNS is only for public domains.
Correct
Azure DNS supports private DNS zones for virtual networks, allowing name resolution for resources within a VNet without exposing them to the internet.
Mistake
Azure Load Balancer can do SSL termination.
Correct
SSL termination is a Layer 7 feature. Azure Load Balancer is Layer 4 and does not inspect or terminate SSL. Use Application Gateway or Azure Front Door for SSL offloading.
Mistake
Basic Load Balancer has the same SLA as Standard.
Correct
Basic Load Balancer has no SLA. Standard Load Balancer has a 99.99% SLA for data path availability.
Mistake
Azure DNS automatically updates records when my VM IP changes.
Correct
Azure DNS does not automatically update records unless you use alias records pointing to Azure resources like public IPs. Regular A records must be updated manually or via scripts.
Mistake
Health probes must use HTTP.
Correct
Health probes can be TCP, HTTP, or HTTPS. TCP probes are simpler and do not require a web server. HTTP probes are useful for checking application-level health.
Azure Load Balancer distributes incoming traffic within a single Azure region to backend VMs. It operates at Layer 4 and is used for high availability and scalability within a region. Azure Traffic Manager is a DNS-based traffic load balancer that distributes traffic across multiple regions (global). It uses DNS to route users to the nearest or healthiest endpoint. For the exam, remember: Load Balancer = regional, Traffic Manager = global.
Yes, Azure DNS can host DNS zones for any domain, regardless of where the resources are hosted. You just delegate the domain to Azure DNS by updating your registrar's NS records. This is a common scenario for hybrid environments. The exam may test that Azure DNS is not limited to Azure resources.
The default health probe uses TCP on the backend port with an interval of 5 seconds. If two consecutive probes fail (10 seconds), the backend VM is marked unhealthy. You can customize the protocol (TCP, HTTP, HTTPS), port, interval (5-300 seconds), and number of unhealthy thresholds. For the exam, know the defaults: interval 5 seconds, 2 failed probes.
Yes, Azure Load Balancer supports session persistence (also called source IP affinity) using the five-tuple hash. You can configure it as 'None' (default, any VM), 'Client IP' (same client IP goes to same VM), or 'Client IP and Protocol' (same client IP and protocol go to same VM). This is useful for applications that require stateful sessions, like shopping carts.
Basic SKU is free but has no SLA, no availability zone support, and limited features (no HA ports, no outbound SNAT rules, no idle timeout adjustments). Standard SKU is paid (per rule and data), has a 99.99% SLA, supports availability zones, HA ports, outbound rules, and is required for production workloads. The exam often tests that Standard is zone-redundant and has an SLA.
Yes, you can create an A record with a static IP address. However, if the resource's IP changes (e.g., a VM is stopped and started), the record becomes stale. To avoid this, use alias records that point to Azure resources (like a public IP) and automatically update when the resource IP changes. Alias records are a key exam point.
An internal load balancer distributes traffic within a virtual network to backend VMs. It uses a private IP address that is accessible only from within the VNet or connected networks. It is commonly used for multi-tier applications where the frontend web tier communicates with an internal app tier. It provides high availability without exposing the backend to the internet.
You've just covered Azure DNS and Load Balancer — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?