Curious Pandas

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.

16 min+40 XP for finishing

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):

Visual guideOne lookup, from the root down
One lookup, from the root downYour laptop asks a recursive resolver. With an empty cache, the resolver asks a root server, which refers it on to the .example servers, which refer it on to ns1.bamboo.example, the zone's own server. That server gives the answer and a TTL, and the resolver keeps the answer in its cache for that many seconds.your laptopstub resolverresolverrecursive, cachingroot serverknows the TLDs.example serversknow the zonescacheanswer + TTLzone serverns1.bamboo.exampleA?asksrefers onrefers onstoresOne lookup, from the root downYour laptop asks a recursive resolver. With an empty cache, the resolver asks a root server, which refers it on to the .example servers, which refer it on to ns1.bamboo.example, the zone's own server. That server gives the answer and a TTL, and the resolver keeps the answer in its cache for that many seconds.your laptopstub resolverresolverrecursive, cachingroot serverknows the TLDs.example serversknow the zonescacheanswer + TTLzone serverns1.bamboo.exampleA?asksrefers onrefers onstores
  1. Your laptop sends one question to a recursive resolver - your router, your ISP, or a public one like 1.1.1.1.
  2. With an empty cache, the resolver asks a root server. The root does not know the answer, only who runs .example.
  3. The resolver asks the .example servers. They do not know either - only that bamboo.example is served by ns1.bamboo.example.
  4. The resolver asks ns1.bamboo.example itself, which answers: an address, and a TTL - how many seconds that answer may be kept.
  5. 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.

Moving shop.bamboo.examplesimulated clockt = 0 s
The zone says
The resolver remembers
Old server 203.0.113.10
    Check yourself+10 XP

    You changed an A record five minutes ago. Your laptop still gets the old address; a colleague gets the new one. Why?

    Check yourself+10 XP

    A record's TTL is 86400. You need to move it with almost no stale traffic. When do you lower the TTL to 60?

    Do it for real · your machine+50 XP bonus

    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 servers

    With 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.conf
    Self-reported. We can't see your machine, and we don't want to. This is a bonus, never required.

    Sources

    Finished reading?

    Missions and quizzes above earn their own XP. This marks the lesson done.