5.1.2.4. Design for Azure DNS and Azure Traffic Manager
5.1.2.4. Design for Azure DNS and Azure Traffic Manager
💡 First Principle: An intelligent, global traffic routing system is essential for building high-performing, resilient, and globally available applications by directing user requests to the optimal endpoint based on health, latency, or geography.
Scenario: You are designing a global web application with active deployments in East US and West Europe Azure Regions. You need to route users to the geographically closest region for optimal performance. In case of a regional outage in one region, traffic should automatically failover to the other region.
Azure DNS is a managed service for hosting DNS domains, and Azure Traffic Manager is a DNS-based traffic load balancer.
Key Design Considerations:
- Azure DNS:
- Purpose: Hosts your DNS domains and provides name resolution using Microsoft's global DNS infrastructure.
- Use Cases: Public DNS for web applications, private DNS for VNet resources (Azure DNS Private Zones).
- Azure Traffic Manager:
- Purpose: A DNS-based traffic load balancer that distributes traffic globally across your application endpoints.
- Routing Methods: Choose from Priority (failover), Weighted, Performance (latency-based), Geographic, MultiValue, or Subnet routing.
- Endpoint Monitoring: Continuously monitors endpoint health and automatically routes traffic away from unhealthy endpoints.
- Use Cases: Global load balancing, disaster recovery (failover to secondary Region), and optimizing user experience.
- Integration: Traffic Manager uses Azure DNS to resolve the appropriate endpoint based on the chosen routing method.
Design decisions in practice:
| Requirement | Service |
|---|---|
| Global HTTP entry with WAF and TLS terminated at the edge | Front Door |
| Global distribution for NON-HTTP protocols | Traffic Manager — it answers at the DNS layer, so it is protocol-agnostic |
| Layer-4 distribution inside one region | Azure Load Balancer |
| Layer-7 routing and WAF inside one region | Application Gateway |
| Name resolution for private endpoints inside a VNet | Private DNS zone linked to the VNet — a zone links to VNets only, never to an on-premises network, and the endpoint's DNS zone group keeps its records current as endpoints are added or change IP |
| VM host names across several VNets (Azure-provided DNS resolves them only within one VNet) | Private DNS zone linked to each VNet with auto-registration |
| On-premises resolving Azure private names, or the reverse | DNS Private Resolver |
Traffic Manager's routing methods are the examined detail: Priority for active-passive failover, Weighted for gradual rollout or A/B, Performance for lowest latency, Geographic for data-residency or content rules, MultiValue for returning several healthy endpoints, and Subnet for routing by the caller's source IP range. Geographic returns the endpoint mapped to the most specific matching region (state or country, then regional grouping, then World), and a location that matches nothing gets an empty (NODATA) answer, so map World as the catch-all. Because the lookup stops at the first match, a country that must be blocked while World is mapped is assigned to an endpoint that answers nothing (a nested endpoint whose child profile is disabled); leaving it unmapped would just send it to World. Endpoint health comes from the probe alone, never from how real requests perform: an endpoint turns Degraded only when its probe path returns a status outside the expected range (default 200) or times out (defaults: 30-second interval, 10-second timeout, three tolerated failures), so the probe path should exercise the dependencies that matter.
Private Resolver's two endpoint directions are the other, and they are easy to invert. An inbound endpoint gives on-premises DNS a target inside Azure to forward to, so on-premises can resolve Azure private zone names. On-premises DNS cannot forward to 168.63.129.16 instead: that address answers only from inside an Azure VNet, which is why the inbound endpoint exists. An outbound endpoint plus a forwarding ruleset sends queries from Azure out to on-premises DNS, so Azure can resolve on-premises names. Hybrid designs usually need both.
A private endpoint only works if the service's normal name resolves to its private IP. Inside Azure, link the privatelink Private DNS zone to every VNet whose clients use the endpoint — peered spokes included: the endpoint is reachable across peering, and a missing zone link is the usual reason a spoke still gets the public IP. From on-premises, add a conditional forwarder for the service's public zone (for example blob.core.windows.net, not the privatelink name) pointing at the resolver's inbound endpoint.
Moving a PaaS service behind a private endpoint has an order: create the endpoint, link its
privatelink DNS zone, confirm from inside the VNet that the service name resolves to the
private IP, and only then disable public network access — disabling it first cuts clients off
before the private path works.
⚠️ Exam Trap: Traffic Manager works in DNS, so failover is bounded by record TTL and by client caching — it never sees the traffic itself. When a question needs failover in seconds rather than minutes, or needs a WAF, it is describing Front Door.
Front Door separates origin health from origin speed. Health comes from its own probes: only a
200 OK counts as healthy, anything else or no valid response is a failure, and the origin group's
sample size and successful samples required decide how many recent probes must pass for an
origin to stay in rotation. A probe is pass/fail, so it removes origins that fail, not origins that
are merely slower. Speed enters through latency-based routing: among healthy origins, Front Door
sends traffic only to those within the origin group's latency sensitivity of the fastest one, as
measured by the probes (the default, 0 ms, means only the fastest). Front Door does not hide the
origins by itself: allow only the AzureFrontDoor.Backend service tag and check the
X-Azure-FDID header against your profile's ID (the tag alone admits every Front Door profile), or
use Private Link origins on Premium.
⚠️ Common Pitfall: Confusing Azure Traffic Manager with Azure Load Balancer. Traffic Manager is a DNS-based, global service that directs clients to an endpoint. Load Balancer is a regional service that distributes traffic within a region to specific VMs or services. Its separate global tier spans regions only by putting one static anycast IP in front of public regional load balancers, and it stays layer 4, with no WAF or TLS termination.
Key Trade-Offs:
- DNS-based (Traffic Manager) vs. Anycast-based (Azure Front Door): Traffic Manager provides DNS-level routing. For more advanced features like SSL offloading, WAF, and Anycast-based routing over the Microsoft backbone, Azure Front Door is the more powerful (and more expensive) option.
Reflection Question: How does designing for Azure DNS (for hosting the domain) and Azure Traffic Manager (with a Performance routing method for latency and endpoint monitoring) fundamentally enhance the global availability and performance of your applications by intelligently routing user requests to the optimal available endpoint?
