Why names exist
You have already leaned on hostnames without examining them: the S3 URL in lesson 4-1, and the load balancer, whose public address AWS hands you as a name rather than a number. Next unit's database does the same. Time to look at the machinery.
DNS (Domain Name System) is the internet's name-lookup service: given a hostname like myapp.com, it returns the current IP address. It exists because addresses change constantly. Servers get replaced, load balancers move, databases fail over to a standby, and every config file that stored the name keeps working through all of it, while every config file that stored the number breaks. That is the working rule: configure names, let DNS resolve the number at the last moment.
A lookup is called resolving a name, and the software that does it (built into every OS and browser) is a resolver.
DNS as a lookup table
DNS at its core is a lookup table maintained by whoever owns the domain. This function is that table for myapp.com.
lookup() { case $1 in myapp.com) echo "3.91.44.10" ;; api.myapp.com) echo "3.91.44.11" ;; *) echo "NXDOMAIN (no record for that name)" ;; esac } echo "myapp.com -> $(lookup myapp.com)" echo "api.myapp.com -> $(lookup api.myapp.com)" echo "shop.myapp.com -> $(lookup shop.myapp.com)"
Output
myapp.com -> 3.91.44.10 api.myapp.com -> 3.91.44.11 shop.myapp.com -> NXDOMAIN (no record for that name)
Two names resolve because they have records. shop.myapp.com does not, and the answer is NXDOMAIN, short for non-existent domain, which is DNS's way of saying no such name.
That third line is worth recognizing, because NXDOMAIN appears in real error messages and means something specific: the name genuinely has no record, as opposed to a name that resolves to a server which is refusing connections. The two failures look identical in a browser and need completely different fixes.
Records, TTLs, and Route 53
Each row in that table is a record. The two you will actually touch:
- An A record maps a name to an IP address:
myapp.com → 3.91.44.10. - A CNAME record maps a name to another name:
www.myapp.com → myapp.com. This is how you point at AWS resources whose IPs you never learn, like a load balancer.
Every record carries a TTL (time to live): the number of seconds a resolver may cache the answer before it must ask again. TTLs exist because the world cannot re-ask DNS on every request, and caching keeps lookups fast and cheap. The trade-off is staleness: with a TTL of 86,400 (one day), a changed record keeps serving the old address from caches for up to a day. Records that must move fast, like a database endpoint that fails over, use short TTLs.
Route 53 is AWS's DNS service (named for port 53, where DNS listens). You buy or import a domain, it hosts your records for $0.50 per month per domain, and its alias records point straight at AWS resources such as a load balancer or a CloudFront distribution, tracking their addresses for you.
The caching decision every resolver makes
A resolver keeps a cached answer only while it is inside the TTL. Here a record was cached at t=1000 with a 60-second TTL, the kind of short TTL a failover-sensitive endpoint uses.
cached_at=1000 ttl=60 check() { local now=$1 if [ $((now - cached_at)) -lt $ttl ]; then echo "t=$now: answered from cache ($((cached_at + ttl - now))s of TTL left)" else echo "t=$now: cache expired, ask DNS again" fi } check 1030 check 1100
Output
t=1030: answered from cache (30s of TTL left) t=1100: cache expired, ask DNS again
Reading the two checks
- At t=1030 the answer is 30 seconds old, well inside the 60-second TTL, so the resolver answers from memory without touching the network.
- At t=1100 the answer is 100 seconds old, past the TTL, so the resolver re-asks and picks up any new address within a minute of a change.
- That is the whole trade-off in one script. Short TTLs make failover fast at the cost of more lookups, and long TTLs cut lookup traffic at the cost of serving stale addresses.
Lowering a TTL before a migration
You lower the TTL from 86,400 to 60 the day before because caches worldwide may serve the old address for up to the TTL, so shrinking it today means tomorrow's switch propagates in about a minute instead of a day.
The TTL is a promise to caches: this answer is good for this many seconds. Any resolver that cached the old IP just before your switch keeps serving it until its own copy expires, and you have no way to reach into those caches and clear them.
There is a subtlety that catches people. Lowering the TTL does not take effect immediately either, because resolvers holding the old record also hold the old TTL. You have to lower it and then wait out the previous TTL before the short value is universally in force, which is why this is done a day ahead rather than an hour ahead.
Afterwards you raise the TTL back up, since a permanent 60-second TTL multiplies your lookup traffic for no ongoing benefit.