Index

DNS Resolution

Lab The TTL dial

100%Open SVG ↗
THE ACTUAL MECHANISM -- the same story, drawn as the real DNS internals1) WHY THE 2nd VISIT IS INSTANT -- the cache ladder1. browser cache2. OS / stub resolver cache3. recursive resolver cacheall MISS -> do the full walk ->each answer is kept for its TTL (the 32s sticky note above).low TTL = fresher, more lookups. high TTL = faster, stale longer.2) THE WALK -- your resolver does the running (iterative)youresolver1.1.1.1root (.).com TLDauthoritative NSroot -> 'ask .com' .com -> 'ask example's NS' NS -> '104.20.23.154'you asked ONCE (recursive); the resolver made 3 hops (iterative) FOR you.transport: UDP port 53 (TCP if the reply is big -- the TC bit, see the L2 x-ray).3) WHAT YOU CAN ASK FOR -- record typesA -> IPv4 address (104.20.23.154)AAAA -> IPv6 addressCNAME -> alias ('www' -> another name)MX -> mail serversNS -> which nameserver is authoritativeTXT -> free text (SPF, domain verification)the concierge asked for a 'house number' -- that was an A record.same story, real names. you now own both layers.the jargon, now that you already own the story:the concierge = "recursive resolver" city directory = "root server" .com office = "TLD server"the family's address book = "authoritative name server" sticky note = "cache" · its 32-second life = "TTL"you never run around the city yourself — the concierge does. that one design decision is why the internet scales.the city directoryknows which office runs eachstreet ending: .com .org .in.com registry officeknows who keeps the recordsfor every single .com nameexample.com's address bookthe only place that trulyknows the house number1 · "which office runs .com?"«not mine — ask the .com office»2 · "who keeps example.com's records?"«kept at ns1.example.com»3 · "house number for example.com?"«104.20.23.154 — and a spare door: 172.66.147.243»where you feel this: the tiny pause before a page loads onhotel wifi — and why the refresh right after feels instant(the sticky note did it)Visiting a friend when nobody memorizes addressesthe first few milliseconds after you hit enter on example.com — told as a story about a very good concierge"I want to visit example.com…but where IS that?"youthe concierge(plot twist: yours livesinside your wifi router)your one and only question…and the answer just appearsexample.com =104.20.23.154(good for 32 seconds)the concierge's sticky note — keptfor the next person who asks

Lessons that use this board

Visiting a friend when nobody memorizes addresses the first few milliseconds after you hit enter on example.com — told as a story about a very good concierge "I want to visit example.com… but where IS that?" you the concierge (plot twist: yours lives inside your wifi router) your one and only question …and the answer just appears example.com = 104.20.23.154 (good for 32 seconds) the concierge's sticky note — kept for the next person who asks the city directory knows which office runs each street ending: .com .org .in .com registry office knows who keeps the records for every single .com name example.com's address book the only place that truly knows the house number 1 · "which office runs .com?" «not mine — ask the .com office» 2 · "who keeps example.com's records?" «kept at ns1.example.com» 3 · "house number for example.com?" «104.20.23.154 — and a spare door: 172.66.147.243» where you feel this: the tiny pause before a page loads on hotel wifi — and why the refresh right after feels instant (the sticky note did it) the jargon, now that you already own the story: the concierge = "recursive resolver" city directory = "root server" .com office = "TLD server" the family's address book = "authoritative name server" sticky note = "cache" · its 32-second life = "TTL" you never run around the city yourself — the concierge does. that one design decision is why the internet scales. THE ACTUAL MECHANISM -- the same story, drawn as the real DNS internals 1) WHY THE 2nd VISIT IS INSTANT -- the cache ladder 1. browser cache 2. OS / stub resolver cache 3. recursive resolver cache all MISS -> do the full walk -> each answer is kept for its TTL (the 32s sticky note above). low TTL = fresher, more lookups. high TTL = faster, stale longer. 2) THE WALK -- your resolver does the running (iterative) you resolver 1.1.1.1 root (.) .com TLD authoritative NS root -> 'ask .com' .com -> 'ask example's NS' NS -> '104.20.23.154' you asked ONCE (recursive); the resolver made 3 hops (iterative) FOR you. transport: UDP port 53 (TCP if the reply is big -- the TC bit, see the L2 x-ray). 3) WHAT YOU CAN ASK FOR -- record types A -> IPv4 address (104.20.23.154) AAAA -> IPv6 address CNAME -> alias ('www' -> another name) MX -> mail servers NS -> which nameserver is authoritative TXT -> free text (SPF, domain verification) the concierge asked for a 'house number' -- that was an A record. same story, real names. you now own both layers.

Saved in this browser only.

DNS Telegram →