Azure DNS and Load Balancer: AZ-104 Networking Guide

Azure DNS is a hosting service for DNS domains, running on Microsoft's global name server infrastructure. A public DNS zone hosts the records for a domain name — such as contoso.com — and answers queries from anywhere on the internet. You do not buy domains through Azure DNS; you host the records for a domain you already own.

Inside a zone you create record sets, one per name and record type. The types you must recognise are the everyday ones: an A record maps a name to an IPv4 address, a CNAME aliases one name to another, an MX record points mail to a mail server, and a TXT record holds arbitrary text used for things like domain verification and SPF. Azure DNS also supports AAAA, NS, SOA, SRV, PTR, and CAA records.

To make Azure DNS authoritative for your domain you perform delegation. When you create the zone, Azure assigns it four name servers. You then go to your domain registrar and update the domain's NS records to point at those four Azure name servers. Once the registrar's delegation propagates, the internet resolves your domain's records from Azure DNS. On the exam, the phrase host a public domain's records plus update the name servers at the registrar always points to a public Azure DNS zone with delegation.

By default, virtual machines in the same virtual network can resolve each other by name using Azure-provided default DNS (the platform resolver reachable at the virtual IP 168.63.129.16). That built-in resolution works only within a single VNet, uses an Azure-assigned suffix you cannot change, and does not span virtual networks. When you need a custom domain name, or resolution across peered virtual networks, you use a private DNS zone.

A private DNS zone provides name resolution inside and between your virtual networks without exposing anything to the internet. You connect a zone to a VNet with a virtual network link. Any VNet you link can resolve the zone's records; link several VNets to one zone and they all share private name resolution.

The feature that makes this effortless is autoregistration. When you enable autoregistration on a virtual network link, Azure automatically creates and updates an A record for every virtual machine in that VNet, and removes the record when the VM is deleted. You never hand-maintain host records. If a scenario asks how to resolve VM names privately inside a VNet, or resolve names across peered VNets using your own domain, the answer is a private DNS zone with a virtual network link, and autoregistration if the records should manage themselves. Without autoregistration the zone still works, but you add records manually.

Azure Load Balancer distributes inbound network traffic across a pool of backend virtual machines. It operates at Layer 4 of the network stack — the transport layer — so it makes decisions on TCP and UDP flows using IP addresses and ports. It does not read URLs, host headers, or cookies; that is Layer 7 work for a different service. Because it works at Layer 4, Azure Load Balancer is fast, protocol-agnostic, and suited to any TCP or UDP workload, not just web traffic.

Four components make up every load balancer, and the exam expects you to name each one:

• Frontend IP configuration — the IP address clients connect to. A public frontend uses a public IP; an internal frontend uses a private IP from a subnet.
• Backend pool — the set of virtual machines (or scale-set instances) that receive the traffic.
• Health probe — a periodic check that tells the load balancer which backend instances are healthy enough to receive traffic.
• Load-balancing rule — the mapping that ties a frontend IP and port to a backend pool port and a probe, defining how a flow is distributed.

By default the load balancer spreads flows using a five-tuple hash (source IP, source port, destination IP, destination port, protocol). You can change the distribution to session persistence — source IP affinity (a two-tuple or three-tuple hash) — so that a client always lands on the same backend, which some stateful applications require. An inbound NAT rule is a related feature that forwards a specific frontend port to one specific VM, for example for direct RDP or SSH access.

The single most common load balancer decision on AZ-104 is internal versus public, and it comes down to what kind of frontend IP the load balancer exposes.

A public load balancer has a public IP frontend. It takes traffic from the internet and distributes it across backend VMs — for example, spreading inbound web requests across a pool of front-end web servers. It also provides outbound connectivity for the VMs behind it.

An internal (private) load balancer has a private IP frontend from a VNet subnet. It is never reachable from the internet; it only distributes traffic that originates inside your network. The classic use is fronting a private application or database tier so that a web tier can call it through one stable private address while traffic is balanced across the backend instances.

On the exam, distribute internal TCP traffic across a private app tier means an internal load balancer; balance internet requests across public web servers means a public load balancer. Both use the identical frontend, backend pool, probe, and rule components — only the frontend IP type differs.

Azure Load Balancer comes in two SKUs, and you choose the SKU when you create the resource. The exam expects you to know why Standard is the production choice.

The Standard SKU is the full-featured, recommended tier. It is zone-redundant — you can spread a frontend across availability zones so the load balancer survives a zone outage — and it is secure by default: its endpoints are closed to inbound traffic unless a network security group explicitly allows it. Standard supports larger backend pools, HA ports, outbound rules, and richer diagnostics. It backs onto Standard public IP addresses.

The Basic SKU is the older, no-cost tier with limited scale, no availability-zone redundancy, and no built-in NSG requirement. Microsoft has placed Basic Load Balancer on a retirement path and recommends Standard for all new and production deployments, so treat Basic as legacy.

The practical exam takeaway: if a scenario needs resilience to a datacentre (zone) failure or a production-grade, secure load balancer, choose Standard. Remember that Standard being secure by default means you must add an NSG rule allowing your application traffic, or clients cannot reach the backend at all.

Azure offers several load-distribution services, and picking the wrong one is a favourite exam trap. The deciding factors are the layer the service works at and whether it balances traffic regionally or globally.

Azure Load Balancer is Layer 4, regional, and distributes any TCP or UDP traffic. Reach for it when you balance non-HTTP workloads, or web servers where you do not need URL-aware routing.

Application Gateway is a Layer 7, regional web load balancer. Because it reads HTTP, it can do URL path-based routing, host-based routing, SSL/TLS termination, and it integrates a Web Application Firewall (WAF). Choose it when a scenario mentions Layer 7 URL-path routing and WAF.

Traffic Manager is a DNS-based global load balancer. It hands clients the address of the best endpoint using routing methods such as priority, weighted, performance, and geographic — it works at the DNS layer and does not sit in the data path. Azure Front Door is a global Layer 7 service that adds CDN, WAF, and TLS at the edge for web apps.

The trigger words: Layer 4 TCP/UDP within a region is Azure Load Balancer; Layer 7 URL-path routing and WAF is Application Gateway; global DNS-based traffic routing is Traffic Manager.

When traffic stops flowing through a load balancer, the cause is almost always the health probe. The load balancer only sends new connections to backend instances the probe reports as healthy. If a backend fails its probe, the load balancer removes it from rotation; if every backend fails, no traffic is distributed at all and clients see connection failures.

A probe checks a port (and, for an HTTP or HTTPS probe, a path that must return HTTP 200) at a regular interval. Work through these causes in order:

• Is the application actually listening on the probe port, and does the probe path return 200? A wrong port or a path that returns 404 marks the instance unhealthy.
• Does a network security group allow the probe? Standard Load Balancer probes originate from Azure's 168.63.129.16; you must allow the AzureLoadBalancer service tag and the probe port inbound, or the probe never reaches the VM.
• Is the backend instance itself healthy — VM running, application service started, host firewall open?

Scenario: a web tier calls an internal load balancer in front of a private app tier, and requests are suddenly failing. You check the backend health and every instance shows unhealthy. The app team recently changed the service to listen on port 8080, but the probe still targets port 80. Because the probe on port 80 fails, every backend is removed from rotation and the internal load balancer distributes nothing. You update the health probe to port 8080 (and confirm the NSG allows the AzureLoadBalancer tag on 8080); the probes pass, the instances return to the pool, and traffic flows again. On the exam, backend removed from rotation and traffic not distributing both point straight to a failed health probe — check the probe port and path, the NSG, and backend health.