Azure DNS — Public Zones
Azure DNS public zonesAuthoritative DNS zones for custom domains (e.g., contoso.com) that answer queries from the public internet. Globally distributed across Azure's infrastructure with a 100% availability SLA. are authoritative DNS zones for custom domains that answer queries from the public internet, globally distributed with a 100% availability SLA.
You delegate your domain to Azure DNS by updating your registrar's name server records to point to the four Azure name servers assigned to your zone. Azure DNS supports all standard record types: A, AAAA, CNAME, MX, NS, PTR, SOA, SRV, TXT.
Azure DNS — Private Zones
Azure Private DNSName resolution for resources within virtual networks using custom domain names without deploying custom DNS servers. A private zone is not resolvable from the public internet. provides name resolution for resources within virtual networks using custom domain names — a private zone is not resolvable from the public internet.
To use a private zone, create a virtual network link connecting the zone to one or more VNets. A VNet linked with auto-registration enabled becomes a registration VNet — DNS A records are automatically created and deleted when VMs are deployed to or removed from that VNet.
Key auto-registration constraints:
- Auto-registration works for VM records only — not for load balancers or other resources
- A VNet can be a registration VNet for only one private DNS zone
- A VNet can be linked as a resolution-only VNet to multiple zones
- A single private zone can have multiple registration VNets
- Auto-registration does not create PTR (reverse DNS) records
Azure Load Balancer Overview
Azure Load BalancerA Layer 4 (TCP/UDP) service that distributes inbound traffic across backend pool members based on a 5-tuple hash (source IP, source port, destination IP, destination port, protocol) by default. is a Layer 4 (TCP/UDP) service that distributes inbound traffic across backend pool members using a 5-tuple hash by default.
- Public Load Balancer: Has a public frontend IP; distributes internet traffic to VMs
- Internal (Private) Load Balancer: Has a private frontend IP; distributes traffic within a VNet or from on-premises
Load Balancer SKU Comparison
| Feature | Standard SKU | Basic SKU (retired Sept 2025) |
|---|---|---|
| Backend pool members | Any VM/VMSS in a single VNet | VMs in one availability set or VMSS |
| Health probe protocols | TCP, HTTP, HTTPS | TCP, HTTP |
| Availability zones | Zone-redundant, zonal | Not supported |
| Secure by default | Yes — NSG required | No — open by default |
| Outbound rules | Yes | No |
| HA Ports | Yes (Internal LB only) | No |
Standard SKU is the only supported option for new deployments — Basic was retired on September 30, 2025.
Health Probes
A Health probeA mechanism that determines which backend instances are healthy and eligible to receive new connections. Azure Load Balancer sends probes from IP address 168.63.129.16 — this address must not be blocked by NSGs. determines which backend instances are healthy and eligible to receive connections; Azure Load Balancer sends probes from 168.63.129.16, which must not be blocked by NSGs.
When all probes are down:
- Standard LB: Existing TCP flows continue
- Basic LB: All existing TCP flows are terminated
Session Persistence
| Mode | Hash Tuple | Behavior |
|---|---|---|
| None (default) | 5-tuple | Each new flow may go to a different backend |
| Client IP | 2-tuple (src IP + dst IP) | Same client IP always hits same backend |
| Client IP and Protocol | 3-tuple | Same client IP + protocol hits same backend |
Session persistence can cause uneven load distribution when many clients share one IP (NAT/proxy).
Auto-Registration Scope Boundaries
Exam Trap
"Azure automatically creates DNS records for all Azure resources in a private zone once you link the VNet." → Auto-registration only creates records for VMs (primary NIC only). Load balancers, App Services, and other resources require manual DNS record creation.
Exam Trap
"A VNet can have auto-registration enabled on multiple private DNS zones." → A VNet can be a registration VNet for only one private zone. It can be linked as resolution-only to additional zones, but auto-registration is exclusive to one zone per VNet.
Standard LB Secure-by-Default
Exam Trap
"Standard Load Balancer backend instances are open by default, like Basic Load Balancer." → Standard Load Balancer is secure by default — all inbound flows are blocked unless an NSG on the backend subnet or NIC explicitly allows them. Basic was open by default, but Basic has been retired.
Health Probe Source IP
Must Memorize
Health probes always originate from 168.63.129.16, Azure's platform service IP. If you block this IP in an NSG on the backend subnet, the backend instance will be marked unhealthy even if the application is running correctly.
Session Persistence and Load Distribution
Exam Trap
"Session persistence (affinity) guarantees even load distribution across backend instances." → Session persistence can cause uneven distribution. If many clients share one IP (e.g., behind a corporate NAT), they all map to the same backend instance, overloading it.
Basic Load Balancer Retirement
Must Memorize
Basic Load Balancer was retired on September 30, 2025. All new deployments must use Standard SKU. Basic did not support Availability Zones, HTTPS health probes, or outbound rules. Standard SKU is secure by default; Basic was open by default.
Create a Public DNS Zone
- Portal → Search → DNS zones → + Create
- Enter your Subscription, Resource group, Name (e.g.,
contoso.com) - After creation, note the four Name server records under the zone overview
- Go to your domain registrar and update NS records to point to these four Azure name servers
- Add records: open the zone → + Record set → choose type (A, CNAME, MX, etc.) → enter values
Create a Private DNS Zone and Link to a VNet
- Portal → Search → Private DNS zones → + Create
- Enter zone name (e.g.,
internal.contoso.com) — must be a valid DNS name - After creation: open the zone → DNS Management → Virtual Network Links → + Add
- Enter Link name, select Virtual Network
- Check Enable auto registration if you want VM records auto-created
- Click Create
Create a Standard Public Load Balancer
- Portal → Search → Load balancers → + Create
- Set SKU to Standard, Type to Public, Tier to Regional
- Under Frontend IP configuration → + Add a frontend IP → assign or create a Standard static public IP
- Under Backend pools → + Add → name the pool, select VNet, add VMs or VMSS instances
- Under Health probes → + Add → set protocol (TCP/HTTP/HTTPS), port, interval
- Under Load balancing rules → + Add → map frontend IP:port to backend pool, select health probe, set session persistence
- Review + Create
Create an Internal Load Balancer
- Same steps as above but set Type to Internal
- Under Frontend IP configuration: select VNet and Subnet, assign a private IP (static or dynamic)
- Backend VMs must be in the same VNet
Troubleshoot Health Probe Failures
- Portal → select Load Balancer → Monitoring → Metrics
- Add metric Health Probe Status filtered by backend IP — a value of 0 means unhealthy
- On the backend VM: verify the probe port (e.g., 80) is listening
- Check NSG rules on the backend subnet allow inbound from 168.63.129.16 on the probe port
AZ-104 Exam Focus
Exam Trap
"Azure automatically creates DNS records for all Azure resources in a private zone once you link the VNet." → Auto-registration only creates records for VMs (primary NIC). Load balancers and other resources require manual DNS record creation.
Exam Trap
"A VNet can have auto-registration enabled on multiple private DNS zones." → A VNet can be a registration VNet for only one private zone. It can be linked as resolution-only to multiple zones.
Exam Trap
"Standard Load Balancer backend instances are open by default, like Basic Load Balancer." → Standard LB is secure by default — all inbound flows are blocked unless an NSG explicitly allows them.
Exam Trap
"Health probe traffic originates from the load balancer's frontend IP." → Health probes always originate from 168.63.129.16, Azure's platform service IP. Blocking this IP in an NSG marks the backend instance as unhealthy.
Exam Trap
"Session persistence (affinity) guarantees even load distribution." → Session persistence can cause uneven distribution. Many clients behind one NAT IP will all hit the same backend.
Exam Tip
When a backend VM is marked unhealthy despite the application running correctly, the first thing to check is whether an NSG is blocking inbound traffic from 168.63.129.16 on the probe port.
Question — click to flip
Q: Which resources get DNS records automatically created in a private DNS zone with auto-registration enabled?
Question — click to flip
Q: Can a VNet be a registration VNet for multiple private DNS zones?
Question — click to flip
Q: What source IP do Azure Load Balancer health probes originate from?
Question — click to flip
Q: Is Standard Load Balancer open or closed by default for inbound traffic?
Question — click to flip
Q: Which session persistence mode routes connections from the same client IP to the same backend?
Question — click to flip
Q: What happened to Basic Load Balancer?