Azure DNS & Load Balancers
Every web app needs a domain name, and every production workload needs to handle traffic across multiple servers. Learn how Azure DNS hosts your zones and how Azure Load Balancer distributes traffic at Layer 4.
What is Azure DNS?
Azure DNS is like a phone directory for the internet — hosted inside Azure.
When someone types “contoso.com” in a browser, DNS translates that name into an IP address. Azure DNS lets you host your domain’s phone directory (DNS zone) on Microsoft’s global network of name servers. You manage records (A records, CNAME records, MX records) from the Azure portal, CLI, or PowerShell.
Azure DNS also offers private DNS zones — a phone directory that only works inside your VNets. Perfect for name resolution between VMs without exposing names to the internet.
DNS record types
| Record Type | Purpose | Example |
|---|---|---|
| A | Maps name to IPv4 address | www -> 20.53.1.100 |
| AAAA | Maps name to IPv6 address | www -> 2001:db8::1 |
| CNAME | Maps name to another name (alias) | blog -> contoso.azurewebsites.net |
| MX | Mail exchange server | contoso.com -> mail.contoso.com |
| TXT | Text data (SPF, DKIM, verification) | v=spf1 include:spf.protection.outlook.com |
| NS | Name servers for the zone | ns1-01.azure-dns.com |
| SOA | Start of authority (zone metadata) | Auto-created with zone |
| Alias | Points to an Azure resource directly | www -> Azure Load Balancer or CDN endpoint |
Alias records
Alias records are Azure DNS-specific and solve a critical problem: CNAME records don’t work at the zone apex (e.g., contoso.com — only sub-domains like www.contoso.com). Alias records can point the zone apex to Azure resources like Load Balancer, Traffic Manager, CDN, or a public IP.
Exam tip: Alias records at zone apex
Standard CNAME records cannot be created at the zone apex (e.g., contoso.com). If you need the root domain to point to an Azure Load Balancer or Traffic Manager profile, use an alias record. Alias records automatically update if the target resource’s IP changes — no manual DNS updates needed.
Private DNS zones
Private DNS zones provide name resolution within VNets — no internet exposure.
How it works:
- Create a private DNS zone (e.g., contoso.internal)
- Link it to one or more VNets
- Enable auto-registration to automatically create DNS records for VMs in linked VNets
- VMs can now resolve each other by name (e.g., webserver1.contoso.internal)
Real-world: TechCorp's internal DNS
TechCorp Solutions creates a private DNS zone “techcorp.internal” linked to their production VNet with auto-registration enabled. When Alex creates a VM called “db-server-01”, it automatically gets a DNS record: db-server-01.techcorp.internal pointing to its private IP. Other VMs in the VNet can now connect to the database using the name instead of the IP. No DNS server to manage.
Azure Load Balancer
A load balancer is like a restaurant host — distributing incoming customers (traffic) across available tables (servers) so no single table gets overwhelmed.
Azure Load Balancer works at Layer 4 (TCP/UDP). It doesn’t inspect the content of traffic — it just forwards packets to backend servers based on IP and port. You configure health probes so the load balancer knows which servers are healthy and only sends traffic to those.
Public vs Internal Load Balancer
| Feature | Public Load Balancer | Internal Load Balancer |
|---|---|---|
| Frontend IP | Public IP address | Private IP from a VNet subnet |
| Traffic source | Internet clients | Resources within VNet or via VPN/ExpressRoute |
| Use case | Web apps, APIs facing the internet | Multi-tier apps (web tier to app tier) |
| Backend pool | VMs, VMSS in any VNet | VMs, VMSS in the same VNet |
Load Balancer SKUs
| Feature | Basic SKU | Standard SKU |
|---|---|---|
| Availability zones | Not supported | Zone-redundant and zonal |
| Backend pool size | Up to 300 instances | Up to 1000 instances |
| Health probes | TCP, HTTP | TCP, HTTP, HTTPS |
| SLA | No SLA | 99.99% SLA |
| Security | Open by default | Closed by default (NSG required) |
| Outbound rules | Implicit outbound | Explicit outbound rules or NAT Gateway |
| HA Ports | Not supported | Supported (internal LB only) |
Exam tip: Standard LB is zone-redundant
Standard Load Balancer is zone-redundant by default — it survives an entire availability zone failure. Basic Load Balancer does NOT support availability zones and has no SLA. Standard LB is also closed by default — backends won’t receive traffic until you configure an NSG allowing it. This catches many people off guard.
Health probes
Health probes determine which backend instances are healthy and can receive traffic:
| Probe Type | Protocol | How It Works |
|---|---|---|
| TCP | TCP | Attempts a TCP connection to the specified port |
| HTTP | HTTP | Sends an HTTP GET and expects a 200 OK response |
| HTTPS | HTTPS | Same as HTTP but over TLS (Standard SKU only) |
If a backend fails the health probe, the load balancer stops sending traffic to it until it becomes healthy again.
Troubleshooting load balancing
Common issues and how to diagnose them:
| Symptom | Likely Cause | How to Check |
|---|---|---|
| No traffic reaching backends | Health probe failing on all backends | Check probe configuration, backend app health |
| Uneven traffic distribution | Session persistence (source IP affinity) enabled | Review load balancing rule settings |
| Timeout errors | NSG blocking health probe or traffic | Check NSG on backend subnet and NIC |
| Intermittent failures | Some backends unhealthy | Check health probe status in Load Balancer metrics |
Real-world: CloudFirst Labs debugs a load balancer
CloudFirst Labs deployed a Standard Load Balancer with three web servers. After deployment, no traffic was reaching the backends. Alex checked the health probe status — all backends showed “unhealthy.”
Root cause: The health probe was configured for HTTP on port 80, but the web app listens on port 8080. Alex updated the health probe port and backends immediately became healthy. He also realised he’d forgotten to add an NSG rule allowing the health probe traffic — Standard LB requires explicit NSG rules.
Knowledge check
TechCorp Solutions wants contoso.com (zone apex) to resolve to their Azure Load Balancer. Alex tries to create a CNAME record but Azure DNS won't allow it. What should he use instead?
CloudFirst Labs deploys a Standard Load Balancer. The backends are healthy but internet traffic isn't reaching them. What is the most likely issue?
Meridian Financial needs name resolution between VMs in their VNet without exposing any DNS records to the internet. What should Alex configure?