Lesson 4 started with a hand-wave: "DNS resolves app.example.com to the ALB's IPs." That hand-wave hides an entire globally distributed system — and in the cloud, DNS isn't just a lookup table. It's a traffic steering layer: it can split users by weight, send them to the nearest region, or fail an entire region over in seconds.
How a name becomes an address
No single server knows all names. Resolution is a delegation chase: each level of the hierarchy knows only who to ask next. Step through it:
The resolution chase
Click Next step to follow the query for app.example.com. This whole dance typically takes a few tens of milliseconds — then gets cached.
Ready
The browser wants app.example.com. Its own cache is empty. Press Next step.
Two details worth keeping: the recursive resolver does the legwork and caches the answer for the record's TTL — which is why DNS changes "propagate slowly" (they don't propagate at all; caches just expire). And inside a VPC, instances use the built-in resolver at VPC base IP + 2 (e.g. 10.0.0.2) — that's how private hosted zones and endpoint DNS tricks work later in this course.
The records you'll actually meet
Type
Maps
Note
A
name → IPv4 address
The workhorse.
AAAA
name → IPv6 address
Same, for IPv6.
CNAME
name → another name
Forbidden at the zone apex (example.com itself).
ALIAS
name → AWS resource
Route 53 special: points at an ALB/CloudFront/S3 by identity, works at the apex, resolves to whatever IPs the resource has right now. This is why you never hardcode ALB IPs — they change.
TXT
name → arbitrary text
Domain verification, SPF/DKIM for email.
MX
name → mail servers
Email routing, with priorities.
NS
zone → its name servers
The delegation glue you just watched in the stepper.
DNS as a traffic steering layer
Route 53 answers queries with policy. The same name can resolve differently per query — and that's a feature. Try the four policies you'll actually encounter:
Routing policy simulator
Pick a policy and fire 20 queries. For latency, change the client's region. For failover, take the primary down and watch the health check reroute everyone.
eu-central-1 ALB
0
us-east-1 ALB
0
Failover is the star. Pair a failover record with a Route 53 health check on the primary region and you get cross-region disaster recovery driven entirely by DNS — no load balancer spans regions, so DNS is the only layer that can. The catch: clients respect TTLs, so keep them short (30–60s) on records you may need to flip.
Check yourself
1. You changed an A record but users still hit the old IP. Most likely cause?
Route 53's own servers update in seconds. The delay lives in every recursive resolver that cached the previous answer. This is why you drop the TTL before a planned migration, not during it.
2. You want example.com (the bare apex) to point at your ALB. What do you use?
CNAMEs are illegal at the apex, and the ALB's IPs change without notice, so a static A record will eventually break. ALIAS is Route 53's answer: apex-legal, and it tracks the ALB's real IPs automatically.
3. With latency-based routing, what actually determines which region a user gets?
It's measured latency, not geography — and note it's the resolver's latency, not the user's. A user on a VPN or an odd corporate resolver can be steered "wrong." (Geolocation routing is the separate policy that uses map location.)