Skip to content
FR

Azure DNS and Load Balancer

Step 25 of 30

Azure DNS and Load Balancer for AZ-104

Introduction

Azure DNS and Azure Load Balancer work together to resolve service names and distribute connections to healthy backends. This lesson completes the AZ-104 skills area Implement and manage virtual networking (15–20% of the exam). The study guide objective is configure name resolution and load balancing: configure Azure DNS (public and private zones, records), configure an internal or public load balancer, and troubleshoot load balancing.

Two ideas drive this lesson. First, applications reach each other by name, not by IP address, so the name has to resolve to the right address from the right place: public names on the internet, private names inside your networks. Second, a single VM is a single point of failure, so traffic is spread across several instances and unhealthy ones are removed. Exam questions combine both: a record that points to the wrong place, a probe that fails, a rule missing a port, a Basic SKU that cannot be mixed with Standard.

After this lesson you will be able to create public and private DNS zones and records, link private zones to virtual networks, choose between an internal and a public load balancer, configure the backend pool, health probe and rules, and work out why a load balancer is not delivering traffic.

Learning objectives

  • Host a public DNS zone in Azure DNS, delegate a domain, and create the common record types.
  • Create a private DNS zone, link it to virtual networks, and use auto-registration.
  • Explain how name resolution works in a VNet with Azure-provided DNS or custom DNS servers.
  • Choose between a public and an internal Azure Load Balancer, and between load balancing options in general.
  • Configure frontend IPs, backend pools, health probes, load balancing rules, inbound NAT rules and outbound access.
  • Troubleshoot probe failures, missing rules, NSG blocks and SKU mismatches.

Azure DNS

Public DNS zones

Azure DNS hosts DNS zones on Microsoft's global anycast network. It does not sell domain names (you buy the domain from a registrar, or with App Service Domains); it answers queries for a zone that you host.

To use it for contoso.com:

  1. Create a DNS zone named contoso.com in a resource group. Azure assigns four name servers (for example ns1-01.azure-dns.com).
  2. At your registrar, change the domain's NS records to the four Azure name servers. This is called delegation. Until the registrar points to them, Azure DNS is not used.
  3. Create records in the zone.

Records are grouped into record sets (all records with the same name and type). The record types to know:

Type Purpose Notes
A Name to IPv4 address Several values in one record set give round-robin answers
AAAA Name to IPv6 address
CNAME Alias from one name to another name Not allowed at the zone apex (contoso.com)
MX Mail exchangers Includes priority
TXT Text, such as SPF or domain verification App Service uses asuid TXT records
NS Delegates a name to name servers The apex NS record set is created for you; you can add NS records to delegate a child zone
SOA Zone authority data Created automatically
SRV, CAA, PTR Service location, certificate authority restriction, reverse lookup
Alias record Supported A, AAAA or CNAME record set referencing an Azure resource or compatible record set Use A/AAAA for the apex; an alias CNAME still cannot be at the apex

Alias records are a favourite exam topic. An alias record points to an Azure resource (a public IP, a Traffic Manager profile, a Front Door or CDN endpoint) instead of a fixed value. When the resource's IP address changes, the record updates automatically, and a dangling record is avoided when the resource is deleted. Alias A/AAAA records allow supported targets at the apex (contoso.com), which a CNAME cannot do. Existing Traffic Manager alias targets remain supported; Microsoft’s current guidance points new Traffic Manager designs toward Linked Records. For a public-IP alias, keep the target resource ID stable: deleting and recreating a different resource does not automatically retarget the alias.

The time to live (TTL) controls how long resolvers cache an answer. Lower the TTL before a planned change, then wait for the previous TTL to expire before switching the record. Existing resolver caches are not shortened retroactively.

Bash
az network dns zone create -g rg-dns -n contoso.com

az network dns record-set a add-record -g rg-dns -z contoso.com \
  -n www --ipv4-address 20.50.60.70

az network dns record-set cname set-record -g rg-dns -z contoso.com \
  -n shop --cname contoso-shop.azurewebsites.net

az network dns record-set a create -g rg-dns -z contoso.com -n @ \
  --target-resource $(az network public-ip show -g rg-net -n pip-web --query id -o tsv)

To delegate a subdomain, create a child zone dev.contoso.com in Azure DNS and add an NS record set named dev in the parent zone containing the child's name servers.

Access to DNS is controlled by Azure RBAC. The built-in DNS Zone Contributor role manages zones and records without granting rights to other resources, and a resource lock can protect a zone from deletion.

Private DNS zones

A private DNS zone provides name resolution through linked Azure networks or configured resolvers, without running authoritative DNS servers yourself. Choose a valid, non-conflicting domain such as corp.contoso.internal, or a service-defined name such as privatelink.blob.core.windows.net for private endpoints.

How it works:

  • You create the zone, then add virtual network links. Azure-provided DNS resolves its records in linked VNets. Clients elsewhere can also resolve them through a DNS forwarder or Private Resolver in a linked VNet; a link is not a client authorization boundary.
  • A link can have auto-registration enabled. VMs in that VNet get A records for their primary NIC’s primary private IPv4 address, updated or removed with the VM. Secondary NICs and load-balancer frontend names are not automatically registered. A VNet can be linked to one zone with auto-registration, but a zone can have up to 100 registration-enabled links, and many VNets can be linked to a zone with resolution only.
  • Records can be added manually for anything else (for example a database listener name).
  • Private DNS zones are global resources, and direct resolution through Azure-provided DNS requires a link for each client VNet. A central resolver is an alternative; peering alone does not copy DNS links.
  • Records in a private zone are not visible on the internet.
Bash
az network private-dns zone create -g rg-dns -n corp.contoso.internal

prodVnetId="$(az network vnet show -g rg-net -n vnet-prod --query id -o tsv)"
az network private-dns link vnet create -g rg-dns -n link-prod \
  -z corp.contoso.internal -v "$prodVnetId" -e true

az network private-dns record-set a add-record -g rg-dns -z corp.contoso.internal \
  -n sql01 --ipv4-address 10.0.2.10

Comparison: public and private zones

Aspect Public DNS zone Private DNS zone
Who can resolve Internet clients through the delegated authority Linked VNets directly, plus clients using an appropriately configured resolver
Delegation at registrar Required Not applicable
Auto-registration of VMs No Yes, on links with it enabled
Typical records www, mail, verification Internal servers, private endpoints
Split-horizon Same name can exist in a private zone with different answers Same name can exist in a public zone

How VMs resolve names

By default a VNet uses Azure-provided DNS (the virtual IP 168.63.129.16). It resolves VM host names inside the VNet, public names, and names in linked private zones. If you set custom DNS servers on the VNet (for example domain controllers), VMs ask those servers instead. Configure the servers to forward the relevant private-zone queries to Azure DNS (168.63.129.16) from an Azure VNet linked to those zones. An on-premises DNS server cannot query that platform IP directly: forward to a reachable Azure DNS Private Resolver inbound endpoint or Azure-hosted forwarder instead. After changing a VNet's DNS servers you must restart the VMs (or renew their DHCP lease) for the change to apply. For hybrid designs, Azure DNS Private Resolver provides inbound and outbound endpoints so that on-premises and Azure can resolve each other's names without VM-based forwarders.

Worked example 1: records for a new web application

Scenario. Contoso buys contoso.com at a registrar. The marketing site runs on a public load balancer with IP 20.50.60.70. Requirements: contoso.com and www.contoso.com must open the site; if the IP changes the records must follow automatically; internal VMs must reach the database as sql01.corp.contoso.internal.

Reasoning.

  1. Create the public zone contoso.com, then change the registrar's name servers to the four Azure ones.
  2. The apex cannot be a CNAME, and a plain A record would need manual updates. Create an alias A record for @ pointing to the public IP resource, and a CNAME www pointing to contoso.com (or a second alias record).
  3. Create a private zone corp.contoso.internal, link it to vnet-prod, and add an A record sql01.

Why other choices are weaker. A CNAME at the apex violates the DNS standard and Azure rejects it. A normal A record works until the IP changes. Putting sql01 in the public zone would publish internal addresses to the internet.

Azure Load Balancer

What it is

Azure Load Balancer distributes traffic at layer 4 (TCP and UDP) across healthy instances. It does not read HTTP content; for URL-based routing, TLS offload or a web application firewall use Application Gateway (regional) or Front Door (global). Availability-zone resilience depends on the frontend configuration and supported region; deploy healthy backends across zones as well. It is a low-latency service, and for the exam you use the Standard SKU. The Basic SKU was retired on 30 September 2025, so new deployments are Standard.

Type Frontend Use
Public load balancer Public IP address (Standard) Internet-facing services; outbound SNAT must be explicitly designed using outbound rules or another supported method
Internal (private) load balancer Private IP in a subnet Tier-to-tier traffic inside a VNet, such as web servers calling an app tier, or on-premises through VPN/ExpressRoute

Many designs use both: a public load balancer in front of the web tier and an internal one in front of the data tier.

Components

Component Role
Frontend IP configuration The address clients connect to (public or private)
Backend pool The NICs or IP addresses of the instances that receive traffic (VMs, VM scale sets)
Health probe Checks each backend instance on a port (TCP, HTTP or HTTPS); unhealthy instances stop receiving new flows
Load balancing rule Maps a frontend IP and port to a backend pool and port, using a probe
Inbound NAT rule Maps frontend ports to particular backend instances, without a health probe; V2 manages mappings for a backend pool
Outbound rule Controls source NAT for outbound internet access of backend instances

Distribution and session persistence

The default is a 5-tuple hash (source IP, source port, destination IP, destination port, protocol), spreading connections across healthy instances. Session persistence (also "source IP affinity") keeps a client on the same backend: Client IP (2-tuple) or Client IP and protocol (3-tuple). It can reduce backend changes for an application that cannot share state, but it is not a per-user cookie and does not replicate sessions. Users behind one NAT can share an affinity key; backend failure or pool changes can remap clients. Prefer external session storage when availability requires sessions to survive backend loss.

Other settings:

  • Idle timeout: how long an idle TCP connection stays open (default 4 minutes; Standard load-balancing and inbound NAT rules support 4–100 minutes, outbound rules 4–120). TCP keep-alives help.
  • TCP reset on idle and floating IP (direct server return) support specific scenarios such as SQL Always On listeners.
  • HA ports rule: a rule with protocol All and port 0 that balances all ports, typically for network virtual appliances behind an internal Standard load balancer.

Health probes

A probe determines which instances get traffic.

Probe type Healthy when Notes
TCP The TCP handshake on the port succeeds Simple; says nothing about the application
HTTP / HTTPS The path returns HTTP 200 Allows an application-aware check such as /health

The probe comes from the platform address 168.63.129.16, represented by the AzureLoadBalancer service tag. The NSG on the backend subnet must not block it. The default AllowAzureLoadBalancerInBound rule permits it; an earlier matching custom deny without a higher-priority probe allow breaks the probe and the load balancer marks every instance unhealthy. The guest operating system firewall must also allow it, and the application must listen on the probe port.

Backend and SKU rules

Review Azure VNet routing and explicit outbound access before choosing the backend egress method.

  • All backend instances must be in one virtual network, in the same region as the load balancer.
  • Standard load balancers need Standard public IPs and are closed by default: an NSG must allow inbound traffic to the backend, otherwise nothing gets through.
  • Do not mix SKUs: a Standard load balancer needs Standard public IPs.
  • For new outbound flows using the Internet next hop, a subnet NAT Gateway takes precedence over instance public IPs and load-balancer outbound rules. Without NAT Gateway, a VM’s instance-level public IP takes precedence over load-balancer SNAT. A UDR through a firewall is a different routed egress path.
  • A NAT gateway is the recommended way to give a subnet predictable outbound addresses when an Internet egress path is required. New VNet subnet defaults depend on the API version: versions released after March 31, 2026 default to private subnets; existing VNets are not changed automatically.

These Bash commands assume rg-net, the backend VM/NIC, its HTTP service and permissive NSG rules for clients/probes already exist. Create the Standard frontend IP explicitly. Configure NAT Gateway or explicit outbound rules separately for backend internet access.

Bash
az network public-ip create -g rg-net -n pip-lb-web -l westeurope \
  --sku Standard --allocation-method Static
az network lb create -g rg-net -n lb-web -l westeurope --sku Standard \
  --frontend-ip-name fe-web --public-ip-address pip-lb-web \
  --backend-pool-name be-web

az network lb probe create -g rg-net --lb-name lb-web -n probe-80 \
  --protocol Http --port 80 --path /health

az network lb rule create -g rg-net --lb-name lb-web -n rule-http \
  --protocol Tcp --frontend-port 80 --backend-port 80 \
  --frontend-ip-name fe-web --backend-pool-name be-web --probe-name probe-80 \
  --disable-outbound-snat true

az network nic ip-config address-pool add -g rg-net --nic-name nic-web1 \
  --ip-config-name ipconfig1 --lb-name lb-web --address-pool be-web

For an internal load balancer you provide --vnet-name and --subnet instead of a public IP, and the frontend receives a private address.

For new multi-VM port-forwarding designs, use inbound NAT rule V2. The VM Scale Sets-specific Inbound NAT Pools feature stops accepting new pools on November 15, 2026 and retires on September 30, 2027. Single-VM V1 inbound NAT rules are not included in that retirement.

Choosing a load-balancing service

Service Layer Scope Choose when
Load Balancer 4 (TCP/UDP) Regional Non-HTTP traffic, very high performance, internal tiers
Application Gateway 7 (HTTP/S) Regional URL routing, TLS termination, WAF, cookie affinity
Front Door 7 Global Global HTTP acceleration, CDN, WAF at the edge
Traffic Manager DNS Global DNS-based routing across regions to any endpoint

Worked example 2: an internal tier that works only from one VM

Scenario. Fabrikam placed three app servers (10.0.2.4, .5, .6) behind an internal Standard load balancer with frontend 10.0.2.100, rule TCP 8080, and an HTTP probe on port 8080 path /health. Web servers get connection timeouts when calling 10.0.2.100:8080. The backend pool contains all three NICs. An allow rule at priority 100 permits the web subnet to TCP 8080; the portal shows probe status 0% for all three. Directly calling 10.0.2.4:8080 from a web server works, and /health returns 200 from the same VM.

Reasoning.

  1. Direct connection works, so the application and the web-to-app NSG path are fine.
  2. A probe at 0% means the load balancer sees every instance as unhealthy, so it sends no new flows to this pool. Established TCP connections on Standard Load Balancer can continue; a failed probe does not prove all traffic has stopped. The probe source is 168.63.129.16, not the web server.
  3. Check the app subnet NSG: someone added a deny-all inbound rule at priority 4000, which sits before the default AllowAzureLoadBalancerInBound at 65001. The probe is denied.
  4. Add an allow rule from the AzureLoadBalancer service tag on port 8080 with a lower priority number than the deny. Probe status returns to 100% and traffic flows.

Why other choices are weaker. Switching to a TCP probe would hit the same NSG block. Adding the web servers to the backend pool confuses clients and backend roles. Replacing the load balancer with a public one exposes the app tier.

Troubleshooting load balancing

Combine NSG priorities and private endpoint DNS with Azure Monitor metrics and connectivity diagnostics to distinguish a blocked probe from a DNS or route failure.

Work from the symptom to the layer.

Symptom Likely cause Check or fix
No new flows reach the pool, all probes 0% NSG or guest firewall blocks 168.63.129.16, app not listening on the probe port, wrong probe path Allow the AzureLoadBalancer tag; test the port on the VM; check probe response
One instance gets no traffic That instance fails its probe, or it is not in the pool Probe status per instance; backend pool membership
Clients cannot connect to the frontend IP Standard LB closed by default; no NSG allow rule; rule missing for that port NSG inbound allow; load balancing rule frontend port
A backend VM calling its own internal LB frontend fails intermittently An internal load balancer cannot send a flow back to the instance that initiated it Call the service from a different tier, or have the initiating backend call its local service directly where appropriate; adding another frontend alone does not remove this limitation
Connections drop after idle time Idle timeout reached Raise the idle timeout or enable TCP keep-alives
Backend VMs have no outbound internet No public IP, outbound rule or NAT gateway Add outbound rule, NAT gateway or instance public IP
Sticky behaviour unexpected Session persistence enabled Set distribution back to default hash

Useful tools: Load balancer metrics (Health probe status, Data path availability), Insights (topology and health), Network Watcher Connection troubleshoot, IP flow verify and the Effective security rules from the previous lesson.

Also check the name resolution side. If clients use a DNS name for the load balancer, confirm with nslookup that it resolves to the expected frontend IP, from the network where the client lives. A private zone not linked to the client's VNet is a frequent cause of "works from one VNet but not from the other".

Pitfalls and exam tips

  • Delegation first. A public DNS zone has no effect until the registrar uses the Azure name servers.
  • CNAME cannot sit at the apex; use an alias record.
  • Private zones need VNet links. Auto-registration is per link, and peering does not copy links.
  • Custom DNS forwarding depends on location. Azure-hosted forwarders can query 168.63.129.16 in a linked VNet; on-premises uses a reachable resolver inbound endpoint. Renew DHCP or restart VMs after changing their DNS configuration.
  • Standard load balancer is closed by default; an NSG rule is required for the traffic and the AzureLoadBalancer tag must stay allowed for the probe.
  • All probes at 0% stop new flows to the pool; established Standard TCP flows can continue. Look at NSG, guest firewall and the app port before changing the rule.
  • Backend pool must be in one VNet and region.
  • Public vs internal: internet-facing means public frontend IP; tier-to-tier or on-premises means a private frontend IP.
  • Layer 4 or layer 7: URL paths, TLS offload and WAF mean Application Gateway, not Load Balancer.

Exam tip: "The records resolve from one VNet but not from another." Think private DNS zone link, not the load balancer. "Everything is unhealthy after a security hardening." Think NSG blocking AzureLoadBalancer.

Mini case study: Wingtip Toys

Wingtip Toys has vnet-prod with a web subnet and a data subnet and a peered vnet-reporting in the same region. Requirements:

  1. wingtiptoys.com and www.wingtiptoys.com must serve the web tier through a single public IP.
  2. Web servers reach the order service on three app VMs by the name orders.wingtip.internal, and individual new VM hostnames must appear in DNS without manual work.
  3. Reporting VMs in vnet-reporting must also resolve orders.wingtip.internal.
  4. After a hardening project, the web load balancer reports all backends unhealthy.

Solution.

  1. Create the public zone, delegate at the registrar, create an alias A record for @ pointing to the load balancer's public IP and a CNAME www to the apex.
  2. Create an internal Standard load balancer in the data subnet for the three app VMs, with a probe and rule, and a private zone wingtip.internal linked to vnet-prod with auto-registration and an A record orders pointing to the internal frontend IP. Only individual VM hostnames register automatically; the orders record remains the manually managed load-balancer frontend record. Registering a VM does not add it to the backend pool: configure pool membership separately, or use the appropriate VM scale set integration.
  3. Link the private zone to vnet-reporting (resolution only). Peering is not enough.
  4. Inspect probe status and the NSG on the web subnet: the hardening added a deny-all rule before the defaults. Add an allow rule for the AzureLoadBalancer service tag on the probe port, and confirm that public traffic is allowed on the frontend port.

Commentary. The facts to remember are delegation, apex alias, per-VNet links, and the probe source address. Each fix is small once you know which layer is failing.

Key terms

  • Azure DNS zone / record set: hosted domain and the records sharing a name and type.
  • Delegation: registrar NS records pointing to Azure name servers.
  • Alias record: resource-linked DNS record; use a supported A/AAAA alias at the apex.
  • Private DNS zone / virtual network link: internal records resolved in linked VNets or through configured resolvers.
  • Auto-registration: automatic A records for VMs in a linked VNet.
  • 168.63.129.16: virtual IP of Azure-provided DNS and of load balancer probes.
  • Public / internal load balancer: layer 4 balancer with a public or private frontend.
  • Backend pool, health probe, load balancing rule: targets, health check and the mapping from frontend to backend.
  • Session persistence: keeping a client on the same backend by hashing source IP.
  • AzureLoadBalancer tag: service tag for the probe source.

Summary checklist

  • I can create a public DNS zone, delegate it, and add A, CNAME, MX, TXT and alias records.
  • I can create a private DNS zone, link VNets and use auto-registration.
  • I understand Azure-provided DNS versus custom DNS servers.
  • I can choose between a public and an internal load balancer and between Load Balancer, Application Gateway, Front Door and Traffic Manager.
  • I can configure the frontend, backend pool, probe, rules and NAT rules of a Standard load balancer.
  • I know a Standard load balancer is closed by default and needs the AzureLoadBalancer tag allowed.
  • I can troubleshoot a probe at 0%, a missing rule and a missing outbound path.

Official sources