How a name becomes an address
A resolver walks from the root to the one server that knows the answer, then remembers it for exactly as long as the TTL says. Move a site to a new server without stranding anyone in a cache.
What happens when you press Enter, in the Web track, treats DNS as one step: name in, address out (or exit 6). Inside that step is a small treasure hunt, and a cache that decides how fast any change you make reaches everyone else.
The walk
Your laptop doesn’t know where shop.bamboo.example lives, and neither does any single server on the internet. DNS is a tree, and each level only knows who’s in charge of the level below (RFC 1034):
- Your laptop sends one question to a recursive resolver - your router, your ISP, or a public one like 1.1.1.1.
- With an empty cache, the resolver asks a root server. The root does not know the answer, only who runs .example.
- The resolver asks the .example servers. They do not know either - only that bamboo.example is served by ns1.bamboo.example.
- The resolver asks ns1.bamboo.example itself, which answers: an address, and a TTL - how many seconds that answer may be kept.
- The resolver keeps the answer for exactly that long. Until it expires, nobody else is asked - including after you change the record.
The TTL is “the time interval (in seconds) that the resource record may be cached” (RFC 1035). It makes DNS fast: a popular name is looked up once, then answered from memory thousands of times. It also makes DNS slow to change. When you edit a record, you change only the zone’s server. Every cache that already holds the old answer keeps using it until its copy expires, and you can’t reach out and clear other people’s caches.
Move a site
The shop is moving from 203.0.113.10 to 203.0.113.20, and the record has a one-hour TTL. Your job is to switch off the old server without a single visitor being sent to it. The resolver here stands in for the thousands out there, each of which filled its cache at a different moment.
You changed an A record five minutes ago. Your laptop still gets the old address; a colleague gets the new one. Why?
Every resolver caches independently. Yours fetched the record before the change and may keep it for the full TTL. Your colleague's resolver asked after the change and got the new answer. Both are working correctly.
A record's TTL is 86400. You need to move it with almost no stale traffic. When do you lower the TTL to 60?
Caches keep whatever TTL they were given. To make sure nobody is still holding a 24-hour answer when you switch, the short TTL has to have been the only one handed out for at least 86400 seconds.
Everything above ran in your browser. Now do it on a real cluster withthe tilt platform. You need Docker, kind and Tilt, about 15 GB of free disk and 8 GB of spare RAM. Setup guide · Can my machine run it?
dig shows the TTL counting down in a real cache, and +trace does the root-to-zone walk itself:
dig example.com A +noall +answer # note the TTL column
sleep 10; dig example.com A +noall +answer # same answer, TTL about 10 lower: cached
dig example.com A +trace # root -> .com -> the zone's own serversWith the tilt platform up, look at the search list a pod really gets:
kubectl run dnsprobe --rm -it --image=busybox:1.36 --restart=Never -- cat /etc/resolv.confSources
Missions and quizzes above earn their own XP. This marks the lesson done.