Azure DNS and Load Balancer: AZ-104 Networking Guide

A public DNS zone in Azure DNS hosts the records for a domain you already own, such as contoso.com, on Microsoft's global name servers and answers queries from anywhere on the internet. Azure DNS hosts records; it does not sell domain names.

To make Azure DNS authoritative you delegate the domain. When you create the zone, Azure assigns it four name servers. At the domain registrar you replace the domain's NS records with those four names. Copying every record into the Azure zone changes nothing on its own: until the registrar's NS records point at Azure, internet resolvers keep asking the old DNS host.

A child zone such as partners.contoso.com is delegated one level down, inside Azure DNS itself. Create the child zone, then in the parent zone contoso.com create an NS record set named after the child label (partners) that lists the child zone's four name servers. The registrar is not involved; it only delegates the top-level domain.

A record set is all the records of one type for one name in a zone. The types you must recognise:

• A / AAAA — map a name to an IPv4 / IPv6 address.
• CNAME — map a name to another host name. A name that holds a CNAME can hold no other record.
• MX — route the domain's email to a mail server host name, which itself needs an A (or AAAA) record.
• TXT — free text, used for domain verification and SPF.
• NS / SOA — delegation and zone authority (created with the zone). Azure DNS also supports SRV, PTR and CAA.

The zone apex (the bare domain, written @) already holds the NS and SOA records, so DNS forbids a CNAME there. That is the problem alias record sets solve. An alias record set is an A, AAAA or CNAME record set that points at an Azure resource instead of a fixed value, and Azure DNS keeps the answer in step with that resource. Supported alias targets are a Standard public IP address, an Azure Traffic Manager profile, an Azure CDN endpoint, an Azure Front Door endpoint, and another record set in the same zone.

Alias records give you two things. First, an alias A/AAAA record set can sit at the apex and still follow a resource whose address changes. Second, they prevent dangling records: when the target resource is deleted, the alias record set becomes empty instead of pointing at an address someone else could later be assigned. An alias CNAME follows the same no-CNAME-at-apex rule as any CNAME.

Every virtual network starts with Azure-provided DNS: VMs query the platform resolver at the virtual IP 168.63.129.16, which resolves the host names of VMs in the same virtual network with no configuration, plus public internet names. It works only within one VNet, uses an Azure-assigned suffix you cannot change, and does not resolve across peered networks.

The VNet's DNS servers setting replaces that resolver with custom DNS servers (for example domain controllers). VMs learn their DNS servers through DHCP, so after you change the setting, existing VMs pick it up only after a DHCP lease renewal or a restart; new VMs get it straight away.

Custom DNS servers can still answer for Azure private DNS zones, but only through the platform resolver. Two things are required: the servers forward those queries to 168.63.129.16, and the private zone is linked to the virtual network the DNS servers run in, because the platform resolver answers from the zones linked to the querying VM's network. Linking the zone only to the client VNets is not enough when the clients ask custom servers in another VNet.

A private DNS zone resolves a custom domain name such as corp.internal inside and between virtual networks, with nothing exposed to the internet. A zone answers only for virtual networks that have a virtual network link to it.

Peering does not share DNS zones. Peered VNets can reach each other's IP addresses, but a VNet that is not linked to the zone cannot resolve its names. Every VNet whose VMs must resolve the zone needs its own virtual network link.

Autoregistration is a property of each virtual network link, not of the zone. On a link with autoregistration enabled, Azure creates an A record for every virtual machine in that VNet, updates it when the IP changes and removes it when the VM is deleted. Its limits matter:

• One registration zone per VNet. A virtual network can have autoregistration enabled on only one private zone. It can still be linked to many other zones as resolution-only links. To move registration to another zone, switch the existing link to resolution-only first.
• Virtual machines only, registered from the VM's primary network interface. An internal load balancer frontend, a private endpoint or any other resource needs a manual A record.
• A link without autoregistration only resolves; you add the records yourself.

An Azure DNS Private Resolver inbound endpoint only answers queries (for example from on-premises) using the zones linked to its VNet. It never creates records in a private zone; that is autoregistration's job.

A private endpoint gives a PaaS resource a private IP in your VNet, and DNS is what sends clients to that IP while they keep using the normal service name. When the endpoint is created, the service's public name gets a CNAME into a service-specific privatelink zone: for example sql01.database.windows.net → sql01.privatelink.database.windows.net. You create the matching private DNS zone (Microsoft's recommended names include privatelink.database.windows.net for Azure SQL Database, privatelink.blob.core.windows.net for Blob Storage and privatelink.vaultcore.azure.net for Key Vault), hold the endpoint's A record in it, and link it to every VNet that consumes the endpoint. Linked VNets resolve the CNAME to the private IP; internet clients, which cannot see the private zone, still get the public address.

Keep the standard FQDN in connection strings, as Microsoft recommends. Connecting to the endpoint's IP address breaks TLS certificate name validation, because the certificate is issued for the service's names, not for an IP; connecting to the privatelink name can also fail, depending on whether the service's certificate covers it. The standard FQDN works both inside the linked VNets and from the internet.

On-premises clients cannot query 168.63.129.16; it is reachable only from inside Azure. Deploy an Azure DNS Private Resolver in a VNet linked to the privatelink zones, and on the on-premises DNS servers add a conditional forwarder for the public service zone (for example database.windows.net) pointing at the resolver's inbound endpoint IP. Key Vault needs forwarders for both of its public zones, vault.azure.net and vaultcore.azure.net. The opposite direction, Azure VMs resolving on-premises names, uses the resolver's outbound endpoint with a forwarding ruleset.

Split-horizon DNS means one name returns different answers to internal and external clients. In Azure you build it by creating a private zone with the same name as the public zone (for example contoso.com) and linking it to the VNets that need the internal answers. Internet clients keep resolving from the public zone; linked VNets resolve from the private zone.

The private zone shadows the public one completely for linked VNets: a name missing from the private zone returns NXDOMAIN there; the query does not fall back to the public zone. So the private zone must hold every name those VNets need, including copies of public names they still use. The fallback to internet option (the NxDomainRedirect resolution policy on a virtual network link) does not help here: it is supported only for Private Link (privatelink.*) zones, where it lets a VNet resolve the public address of a resource that has no private endpoint record.

Azure Load Balancer distributes TCP and UDP flows across a pool of backend virtual machines or scale-set instances at Layer 4, using IP addresses and ports. It does not read URLs, host headers or cookies, so it suits any TCP or UDP workload, not just web traffic.

Its building blocks:

• Frontend IP configuration — the address clients connect to: a public IP (public load balancer) or a private IP from a subnet (internal load balancer).
• Backend pool — the VMs or scale-set instances that receive traffic.
• Health probe — decides which pool members are healthy enough to receive new connections.
• Load-balancing rule — maps one frontend IP and port to a backend port on the pool, using a probe. A frontend and a pool alone forward nothing; you need a rule and a probe.
• Inbound NAT rule — forwards a frontend port to one specific VM (for example RDP or SSH to a single machine), whereas a load-balancing rule spreads a port across the whole pool.
• Outbound rule — configures outbound SNAT for the pool (see the outbound section).

An ordinary load-balancing rule maps a single frontend port to a backend port; it takes no port ranges. Balancing every port therefore needs HA ports rather than a rule per port.

Session persistence on the rule controls which flows stick to one backend:

Cookie-based affinity is a Layer 7 feature of Application Gateway, not of Azure Load Balancer.

Three rule settings change how flows are handled, and each solves a specific problem.

HA ports is a load-balancing rule with port 0 and protocol All, available on an internal Standard load balancer. One rule balances every TCP and UDP flow on every port. Its main use is high availability for network virtual appliances (firewalls): route tables send traffic (for example 0.0.0.0/0) to the internal frontend IP as the next hop, and the load balancer spreads it across the NVA instances whatever the destination port.

Floating IP (direct server return) leaves the frontend IP as the packet's destination instead of rewriting it to the backend VM's IP. You need it when several frontends must reach the same backend port on the same VMs (for example two listeners both on port 443): enable floating IP on each rule and configure each frontend IP on a loopback interface in the guest OS so the application can bind to it. If each frontend maps to a different backend port, ordinary rules work without it. SQL Server Always On listeners behind an internal load balancer are the classic floating IP case.

Idle timeout closes TCP flows with no traffic after a set time: 4 minutes by default, configurable up to 100 minutes. Connections that silently die after a few idle minutes point to this setting (or to TCP keep-alives in the application). Enabling TCP reset on idle makes the load balancer send a TCP RST to both ends when the timeout hits, so applications learn the connection is gone instead of hanging.

The frontend IP type decides who can reach a load balancer: a public IP frontend makes it a public load balancer reachable from the internet; a private IP frontend makes it an internal load balancer, never reachable from the internet. Pick the type by where the callers are.

Both use the same frontend, backend pool, probe and rule components; only the frontend differs. An internal load balancer gives its backend VMs no internet access. A common low-effort pattern is an internal load balancer for private inbound traffic plus a NAT gateway on the backend subnet for outbound.

One documented limitation: a VM in an internal load balancer's backend pool cannot reach that load balancer's own frontend. If the flow is sent back to the same VM it fails, so a backend that needs to call the service must reach it another way (a different load balancer, or the other backends directly).

Standard is the SKU for every new public or internal load balancer. Basic Load Balancer was retired on 30 September 2025, and Basic public IP addresses were retired at the same time; existing Basic deployments must be upgraded to Standard. The third SKU, Gateway (Gateway Load Balancer), is a special-purpose SKU that chains third-party NVAs transparently in front of a Standard public load balancer's frontend or a VM's instance-level public IP configuration; it is not used to distribute application traffic.

What defines Standard:

• Secure by default. A Standard public IP and a public Standard load balancer are closed to inbound internet traffic until a network security group on the backend subnet or NIC allows it; a public frontend whose backends have no NSG rule allowing the traffic serves nothing. For an internal load balancer, traffic from inside the virtual network is already allowed by the NSG default rule AllowVNetInBound, unless a custom rule denies it.
• Standard public IPs on public frontends.
• Availability zones and the load balancer SLA.
• HA ports, outbound rules, larger backend pools and Azure Monitor multi-dimensional metrics.

A frontend's zone setting decides what survives a zone failure:

For a single address that must survive the loss of any one zone, use a Standard load balancer with a zone-redundant frontend and backends spread across zones.

Backend VMs without a public IP reach the internet through source NAT (SNAT) provided by one of a fixed set of methods, and when several apply Azure uses the highest in this order:

1. A user-defined route that sends 0.0.0.0/0 to an NVA or virtual network gateway (the traffic leaves through that device).
2. NAT gateway on the subnet.
3. An instance-level public IP on the VM's NIC.
4. Outbound rules on a public Standard load balancer (or load-balancing-rule SNAT).
5. Default outbound access (implicit, not recommended).

So a NAT gateway on the subnet takes over new outbound connections even from VMs that have their own public IP or sit behind load balancer outbound rules. Default outbound access is being phased out: new virtual networks created with API versions released after 31 March 2026 (and through the Azure portal) default to private subnets, with no implicit outbound access, so VMs there need an explicit method. Existing virtual networks are unchanged, and deployments that use an older API version (for example an older template) keep the old default unless the subnet is set to private.

Outbound rules only configure SNAT, need a public frontend IP, and therefore exist only on a public Standard load balancer, never on an internal frontend. To rely on them, set the load-balancing rule to not use its own outbound SNAT, then define the outbound rule with its frontend IPs and port allocation.

SNAT port exhaustion shows up as intermittent outbound connection failures under load and as failed connections in the SNAT Connection Count metric. Fix it by adding outbound capacity: a NAT gateway (the recommended method, with a large port inventory per public IP) or outbound rules with more frontend public IPs and manual port allocation per backend instance.

The Microsoft-recommended way to give VMs without public IPs outbound access is a NAT gateway on the subnet; outbound rules on a public Standard load balancer also work when that load balancer already fronts the VMs.

Azure Load Balancer is the right distributor for any TCP or UDP traffic within one region, including proprietary non-HTTP protocols. The other services either speak only HTTP/S or work through DNS.

Application Gateway routes on HTTP content: path-based rules send /images/* and /video/* to different backend pools, and multi-site (host-based) listeners serve several host names, such as contoso.com and fabrikam.com, from one gateway. Traffic Manager answers DNS queries with the endpoint chosen by its routing method: priority (a primary endpoint with failover to backups), weighted (split traffic by weight, for example for a gradual rollout), performance (the endpoint with the lowest network latency for the client), geographic (by the client's location, for data sovereignty or localisation), plus multivalue and subnet. Because clients connect to the endpoint directly after the DNS answer, Traffic Manager works for any protocol but cannot inspect or terminate traffic.

A workload on a custom TCP port, a UDP service or a database tier therefore needs Azure Load Balancer; Application Gateway and Front Door cannot carry it because they only handle HTTP and HTTPS.

When a load balancer stops distributing traffic, start with the health probe: the load balancer sends new flows only to instances whose probe succeeds. A failing instance is taken out of rotation. If every instance fails, no new flows are sent anywhere; a Standard load balancer keeps established TCP flows to the instances running, but new connections fail.

How probes decide health. A TCP probe succeeds when the TCP handshake completes on the probe port. An HTTP or HTTPS probe succeeds only when the probed path returns HTTP 200; any other status, including a 301 or 302 redirect or a 404, marks the instance down at once. The probe threshold (consecutive failures) applies only to probes that time out.

Check in this order:

• Probe port and path match what the application listens on and serves.
• NSG rules. Probes come from 168.63.129.16, carried by the AzureLoadBalancer service tag. Every NSG includes the default rule AllowAzureLoadBalancerInBound at priority 65001, but a custom deny-all rule with a lower priority number (for example 4000) is evaluated first and blocks probes, so every backend goes down. Allow the AzureLoadBalancer tag on the probe port above the deny. Remember that Standard is secure by default: the NSG must also allow the client traffic itself.
• The backend — VM running, service started, guest firewall open on the probe port.
• Topology limits — a backend calling its own internal load balancer's frontend fails by design.

Azure Monitor metrics separate platform problems from backend problems:

Data path healthy but one instance failing its probe means the cause is inside that VM; a shared setting such as the probe definition or a subnet NSG would fail every instance.

Scenario: a web tier calls an internal load balancer in front of an app tier, and requests suddenly fail. Health Probe Status shows every instance down while Data Path Availability is normal. The app team moved the service to port 8080, but the probe still targets port 80. Point the probe at 8080 and confirm the NSG allows the AzureLoadBalancer tag on 8080; the instances return to the pool and traffic flows again.