DNS
Intermediate 12 min read DNS

DNS Routing Policies

Choosing the best answer per resolver

Beyond simple lookups, DNS answers can be chosen by latency, geography, weight or failover state. These policies turn the resolver's question into an intelligent routing decision — the cheapest global load balancing you can buy.

routing policylatency routinggeolocationweightedfailovermultivalue
Prerequisites: Record Types and Hosted Zones
Before we start

What you will learn

  • Differentiate latency, geolocation, weighted, failover policies
  • Apply health-based DNS failover
  • Combine policies with regional LBs
In 60 seconds

Routing policies make DNS choose between multiple records: latency (nearest), geolocation (closest region by client's resolver location), weighted (canary splits), or failover (primary/secondary with health checks).

Introduction

What is this?

Route 53 policies: simple, weighted, latency, geolocation, geoproximity(BIAS), failover, multivalue answer — each record identified by SetIdentifier. Azure Traffic Manager profiles: Performance (latency), Geographic, Priority (failover), Weighted, Multivalue. GCP: Cloud DNS + GLB anycast for latency-aware routing. Health checks gate records: a sick region's record is excluded automatically.

Motivation

Why do you need it?

  • Sending users to the nearest region cuts latency without app changes.
  • Weighted splits support canary/blue-green and slow-roll traffic.
  • DNS failover is the first wake-up call when a region dies.
  • Compliance: geolocation keeps data processing region-resident.
Think about it

Mental model

Imagine

A delivery dispatch center assigning drivers by city (geo), time lag (latency), and load (weight)

Think of

DNS routing policies

The dispatcher (policy) reads the sender's location (resolver), prefers the closest open hub (latency), when overloaded splits packages (weighted), and if the local hub is closed reroutes (failover).

Mechanics

How it works

  • Each record has a SetIdentifier/priority tag; the policy picks among them at query time.
  • Latency policy: resolver's location → nearest healthy region by modeled latency.
  • Geolocation: deterministic region-assignment from the resolver's IP.
  • Weighted: split % per record (0-100) for canary; low weight = trickle traffic.
  • Failover: health-checked primary; if unhealthy, DNS serves the secondary.

Policy → region selection.

Query app.example.com
Health checks
Policy
Pick record
Answer
Hands-on

Examples

Weighted and latency policy records

Weighted and latency policy records
# Route 53: weighted records for canary (app-v1 90%, app-v2 10%)
aws route53 change-resource-record-sets --hosted-zone-id ZONE \
  --change-batch '{"Changes":[
   {"Action":"UPSERT","ResourceRecordSet":{"Name":"app.example.com","Type":"A",
      "SetIdentifier":"v1","Weight":90,"TTL":60,"AliasTarget":{"HostedZoneId":"...","DNSName":"v1-lb"}}},
   {"Action":"UPSERT","ResourceRecordSet":{"Name":"app.example.com","Type":"A",
      "SetIdentifier":"v2","Weight":10,"TTL":60,"AliasTarget":{"HostedZoneId":"...","DNSName":"v2-lb"}}}]}'

Two alias records, weighted 90/10, deliver canary traffic at the DNS layer.

Real world

In production

  • Two-region SaaS: latency records send EU→eu-west-1 and US→us-east-1 with 60s TTL.
  • Azure Traffic Manager priority: prod region primary, DR region on failover.
  • Geolocation policy reserves a region for regional-contract customers while weighted handles the rest.
Guidelines

Best practices

  • Attach a health check to every failover/latency record.
  • Low TTL (60s) on policy records to keep swim at takeoff.
  • Test the chosen record per region (dig with @region resolvers, or edns-client-subnet).
  • Document SetIdentifiers/policy intent in IaC — mislabeled weights cause silent skew.
Watch out

Common mistakes

  • Latency policy with no health check → routed to a dead region.
  • Weights that sum ≠ 100 for the records (traffic invisible to some weights).
  • Geolocation records that don't cover 'all remaining' (default) regions → NXDOMAIN holes.
  • Forgetting cache: policy changes apply only after TTL expires.
Root cause analysis

Common issues

Error
Some users get a cross-region record
Root cause

Resolver IP ≠ user location (VPN, carrier NAT)

Fix

Rely on latency instead of geo for user-experience, or use CDN/front-routing.

Error
Failover record never fails over
Root cause

Health check marks region healthy or TTL caches the old answer

Fix

Verify the health path/probe; lower TTL; wait out caches.

When things break

Debugging tips

  • dig which record you get: resolver IP drives the choice — test from multiple locations.
  • Validate health checks: switch the health path and watch record selection change.
  • Geolocation gaps: add a 'Default' coverage record so unmapped resolvers still get an answer.
  • Weighted drift: check Traffic Distributed metrics per weighted record over time.
Interviews

Interview checkpoint

Practice

Hands-on lab

Model Routing Policies and Their Failover Behavior
25 min · intermediate
In progress
Objectives
  • Simulate latency/geo/weighted selection
  • Model health-check gating
  • Reason about cache impact

Model Routing Policies and Their Failover Behavior

25 min · intermediate

0/3 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/1
1

Why attach a health check to a latency-routed record?

Go deeper

Official documentation

AWS — Route 53 routing policies
docs
Azure — Traffic Manager profiles
docs
GCP — Cloud DNS architecture
docs