The TTL dial
You changed the address. How long until the world stops sending people to the old one?
A house moves, and the address book is updated the same second. Five concierges are still holding sticky notes with the old number, each one good until its own seconds run out. The panels show those notes, who asked what this step, and the count of people still being sent to an address that is gone.
Board: DNS Resolution →Twenty-eight steps of the clock, five concierges, one record. Step through them yourself. Nothing plays automatically.
try this Set Seconds the concierge keeps the note to 300, press Add next question through the run, and watch the stranded count in The tally.
Now: second 0–19
1 of 28 askedThe sticky notes
One sticky note per concierge, each with its own clock.
- your wifi router
- the hotel wifi
- the office concierge
- your phone's carrier
- the public one (1.1.1.1)
This step
The address book says 104.20.23.154.
- 1sclient 18 → the office conciergewalk 179ms
- 4sclient 09 → your phone's carrierwalk 169ms
- 8sclient 03 → the office conciergenote 14ms
- 14sclient 10 → the public one (1.1.1.1)walk 181ms
- 17sclient 07 → the hotel wifiwalk 143ms
The tally
4
questions the address book had to answer itself
The note is good for five minutes. You change the address, and a reader's page is broken. When does their own concierge stop sending them to the machine that is gone?
Why a minute matters
A minute is the value a record is usually left at without anyone choosing it. Three visits in four never leave the building, which looks like a clean win until the failover. Some concierges re-ask within seconds. Others still hold a fresh-looking note that names a machine which no longer answers, and the address book cannot take it back.
The tradeoff: Most of the cache benefit for a stale window under a minute. Choose it on purpose rather than by default.
What the dial actually costs
One dial, two bills. Turn the note's life up and the address book goes quiet, the walks stop and every lookup feels instant. Turn it down and the change you just made is live almost at once. No position does both. The number you set is the decision.
A stale answer is not an error. The concierge works, the note is intact, and the address book already holds the new number. The note is a correct answer to a question asked earlier, and the protocol has no way to tear it up. Nothing in this lab reports an error, because by the protocol's rules nothing has gone wrong.
Staleness sticks to the same people. Each person here asks their own concierge: the one in their router, their hotel, their office. A stale note strands the same quarter of the crowd over and over until it expires. Run five minutes and watch the stranded count sit at the whole crowd for step after step. It then drops in blocks as each concierge's note runs out, one at a time.
The bill for a short TTL is paid by the address book, every day. At a blink, nearly every lookup in this run reaches the authoritative server, and every visitor pays the walk before their page starts loading. That cost is continuous. The stale window only costs you on the day you change something, so the dial tends to drift upward until an outage moves it back.
Limits of this model
One record, one change, five concierges. Real resolution runs a ladder of caches: browser, operating system, then resolver. Each holds its own copy with its own remaining life, so the real stale window is the deepest one in the ladder.
Every concierge here honours the note's life exactly. Real resolvers clamp a TTL they think is unreasonable, keep serving an expired answer while they re-ask, and forget notes early under memory pressure. The number you set is an upper bound on freshness, and no resolver guarantees it.
The walk costs a flat 140ms here. The second visit is instant because the first one already did the running. A real first walk depends on where the root, the TLD server and the authoritative server are. Anycast keeps that from being a trip across the planet.