DNS: how a name becomes an address

In the last lesson we skipped one line: "turn api.hisaab.measdev.me into an IP address." That line is the Domain Name System, and it hides an entire distributed database that answers trillions of queries a day. You use it constantly — every fetch, every page load — and it fails in ways that will eat a whole afternoon if you don't understand its one central trick: caching, at every single hop. Almost every DNS mystery is a caching story.

Start from what you know: you type a name, you get to a server. Now go down.

The resolution chain

No single machine knows every name on the internet. Instead, the answer is assembled by walking a hierarchy, reading the name right to left. api.hisaab.measdev.me is really api.hisaab.measdev.me. — that trailing dot is the invisible root.

Four kinds of player are involved:

• Stub resolver — the tiny client in your OS. It doesn't do the walking; it asks one resolver and trusts the answer. This is what getaddrinfo() (and therefore fetch) actually calls.
• Recursive resolver — the workhorse (your ISP's, or 8.8.8.8 / 1.1.1.1). It does the legwork and caches aggressively.
• Root and TLD servers — the top of the tree. Roots know where the .me servers are; the .me (TLD, top-level domain) servers know where measdev.me's authoritative servers are.
• Authoritative nameserver — the machine that actually holds the records for measdev.me. Its answer is the truth; everyone else is quoting a cache.

Here's a cold lookup, top to bottom:

  your app            recursive resolver              the hierarchy
  (stub)                  (8.8.8.8)
    │                        │
    │  api.hisaab.measdev.me │
    ├───────────────────────►│
    │                        │   "who serves .me ?"
    │                        ├──────────────────────────►  Root servers
    │                        │◄──────────────────────────  "ask the .me TLD servers"
    │                        │
    │                        │   "who serves measdev.me ?"
    │                        ├──────────────────────────►  .me TLD servers
    │                        │◄──────────────────────────  "ask ns1.measdev.me (authoritative)"
    │                        │
    │                        │   "A record for api.hisaab.measdev.me ?"
    │                        ├──────────────────────────►  Authoritative NS
    │                        │◄──────────────────────────  "A = 203.0.113.10, TTL 300"
    │  203.0.113.10          │
    │◄───────────────────────┤   (now cached at the resolver)
    │                        │

Note who does the work: the stub asks once. The recursive resolver makes up to three more round trips walking root → TLD → authoritative. On a cold miss that's real time — tens of milliseconds, sometimes over a hundred if the servers are far. Which is exactly why none of it happens most of the time.

Caching and TTLs: the whole point

Every record carries a TTL (time to live) in seconds — the answer's own expiry date. TTL 300 means "you may cache me for 5 minutes; after that, ask again." That number, set by whoever runs the domain, is cached at every hop the answer passes through:

The resolver cache is the load-bearing one. Because it's shared, the first user anywhere behind 8.8.8.8 who looks up your domain pays the cold-walk cost; everyone after them for the next TTL seconds gets a sub-millisecond cached hit. This is why a domain you've never visited resolves instantly anyway — someone warmed the cache for you.

The TTL is a tradeoff you set deliberately. Low TTL (30–60s) = changes take effect fast, but more query load and slightly slower average lookups. High TTL (86400 = a day) = fast and cheap, but a mistake or a planned IP change is pinned in caches worldwide for up to a day. The standard move is to lower the TTL a day or two before a planned migration, cut over, then raise it again.

Drive it yourself. Resolve a name and watch the resolver walk root → TLD → authoritative; the answer lands in the caches with a live TTL countdown. Resolve again before it expires and you get an instant hit — no walk. Let the TTL run to zero and the next lookup is cold again. Flip who's asking to another user on the same resolver: their device cache is empty, yet they still get an instant hit off the shared resolver cache someone else warmed. Try the www (CNAME, extra hop) and ghost (NXDOMAIN, the "no" is cached too) names as well.

Negative caching: the "no" is cached too

If you ask for a name that doesn't exist, the authoritative server returns NXDOMAIN ("no such domain") — and that answer is cached too, governed by the SOA record's minimum field. This is negative caching, and it's a classic trap: you fetch a subdomain before you've created its DNS record, get NXDOMAIN, then create the record — and it still fails for minutes, because your resolver cached the "no." You didn't do anything wrong; you're waiting out a cached negative.

The record types you'll actually touch

DNS holds many record types; in practice you deal with a handful. Using measdev.me as the running example:

Two gotchas worth internalizing. A CNAME is a redirect at the DNS layer — resolving www returns "actually, go resolve measdev.me," costing another lookup step; and a name with a CNAME can't also carry other records, which is why you can't CNAME a bare apex domain. TXT records are the internet's junk drawer: domain-ownership verification (Google, Apple), email anti-spoofing (SPF/DKIM), all live here as plain strings.

Why DNS rides UDP (mostly)

A DNS query is tiny — a question in, an answer out, both usually under 512 bytes. Running that over TCP would mean a three-way handshake (a full round trip) just to ask a one-packet question. So DNS uses UDP by default: fire the question in one packet, get the answer in one packet, no handshake, no connection state. For a lookup you do before every connection, that saved round trip matters enormously.

UDP has no delivery guarantee, so the resolver just retries on timeout — cheap, because the query is idempotent. DNS falls back to TCP in two cases: when the response is too large for a single UDP datagram (the server sets a "truncated" flag and the client retries over TCP), and for zone transfers between nameservers. So the rule is "UDP for the common case, TCP when the answer won't fit."

Hands-on: watch the walk with dig

dig +trace makes the resolver do its recursion out loud, printing each hop instead of just handing you the final answer. Annotated:

$ dig +trace api.hisaab.measdev.me

; <<>> DiG 9.18 <<>> +trace api.hisaab.measdev.me
;; global options: +cmd

.            518400  IN  NS  a.root-servers.net.   ← (1) the root nameservers
.            518400  IN  NS  b.root-servers.net.
;; Received 811 bytes from 127.0.0.53#53(127.0.0.53)

me.          172800  IN  NS  a0.nic.me.            ← (2) root replies: ".me lives here"
me.          172800  IN  NS  b0.nic.me.
;; Received 645 bytes from 198.41.0.4#53(a.root-servers.net)  ← asked a root

measdev.me.  86400   IN  NS  ns1.measdev.me.       ← (3) .me TLD replies: authoritative NS
measdev.me.  86400   IN  NS  ns2.measdev.me.
;; Received 122 bytes from 199.253.59.1#53(a0.nic.me)         ← asked a .me server

api.hisaab.measdev.me. 300 IN A 203.0.113.10       ← (4) authoritative: the actual answer
;; Received 74 bytes from 203.0.113.53#53(ns1.measdev.me)     ← asked the authoritative NS

Read it as a descent: root (1) points you to the .me servers (2), which point you to measdev.me's authoritative servers (3), which finally give you the A record (4) with its TTL 300. Each ;; Received ... from line names which server answered that step — you're literally watching the four-hop walk from the diagram above. The +trace bypasses your resolver's cache on purpose, so this is the full cold path every time.