How DNS works, end to end

Filed under Notes on July 17, 2026 · updated

DNS 101: why it exists, the domain namespace, the recursive lookup through root, TLD, and authoritative servers, and caching. Part 1 of a DNS series.

You type hugosibony.com, hit Enter, the page loads. In between, your machine hits one problem: it connects to IP addresses, and hugosibony.com isn’t one. DNS turns the name into an address like 172.67.213.189.

Addresses are built for machines. You won’t memorize 172.67.213.189, let alone its IPv6 form 2606:4700:3030::6815:560c, and it changes when the site moves servers. DNS lets the name stay put while the number underneath changes.

DNS is a distributed system, not a lookup table, because a lookup table doesn’t scale. In the 1980s every host on the ARPANET shared one hand-maintained HOSTS.TXT file, downloaded from a single server. It buckled as the network grew: name collisions, stale copies, one machine feeding everyone. So DNS replaced it with a distributed, delegated, cached tree.

The name is a tree

Read www.hugosibony.com right to left. At the top sits the invisible root, written as a trailing dot. Under it, the top-level domain com. Under that, the registered domain hugosibony. Under that, any subdomains the owner creates, like www. Each dot-separated piece is a label (up to 63 bytes; 255 for the whole name). Written in full, www.hugosibony.com., it is a fully-qualified domain name.

Each level hands control of the level below to someone else, a delegation, so no single server has to know everything. That tree is exactly the path a lookup walks: root, then com, then hugosibony.

The lookup

Your machine has the name and needs the address. Press Enter:

hugosibony.com press Enter
Press Enter to look up hugosibony.com.
connected to 172.67.213.189 The name is now an IP. The browser can connect.
  1. recursive query · RD=1

    Your browser

    Needs an IP, not a name. Sends one query: "do the whole lookup for me."

    hugosibony.com A?
  2. iterative queries · RD=0

    The resolver

    Your ISP, or something like 1.1.1.1. Cache is empty, so it walks the tree itself, one server at a time.

    hugosibony.com A?

  3. Root server

    Doesn't have the IP, but knows which servers run .com.

    Ask the .com servers.

  4. .com server

    Doesn't have it either, but knows the hugosibony.com nameservers.

    Ask the hugosibony.com nameservers.

  5. Authoritative server

    Cloudflare runs the hugosibony.com zone. It has the answer.

    hugosibony.com. 300 IN A 172.67.213.189

The resolver now caches this for the record's TTL (300s), so the next lookup skips the whole trip.

No server holds the whole map. Each one points a step closer (a referral) until the authoritative server, which owns the domain, returns the address. Your browser sends one recursive query (“find this for me”); the resolver does the iterative queries up the tree for you.

See it yourself: dig hugosibony.com runs the same lookup in a terminal.

Caching

Every answer carries a TTL: how long it may be cached. Caches sit in your browser, your OS, and the shared one in your resolver. The first lookup misses and does the work; the rest are instant until the clock runs out. It’s also why a DNS change takes a while to land: old answers stay live until their TTL expires.

Caching & TTL

The first lookup does the work; the rest ride the cache until its time-to-live runs out.

Cache empty
no cached record, click look up hugosibony.com. 30 IN A 104.21.86.12
TTL 30s

TTL is in seconds, set by the zone operator. This demo uses 30 s so it’s watchable, the real hugosibony.com record is 300 s. A hit serves the remaining TTL; it never resets the clock.

Where the answer gets cached
  • Browser cache per-app, seconds–minutes
  • OS stub-resolver cache per-machine
  • Recursive resolver cache shared by everyone using it

Each layer counts down its own copy of the TTL independently. The recursive resolver’s cache is the big shared one, one miss there spares every client behind it.

Negative caching: “does not exist” answers (NXDOMAIN / no-data) are cached too, for the time set by the zone’s SOA minimum field (RFC 2308), so a typo stays fast-failing, not re-queried every time.

Lower TTL = fresher records but more queries. Higher TTL = fewer queries but changes propagate more slowly.

References

  • RFC 1034 and RFC 1035: DNS concepts, the namespace, and the recursive/iterative model. RFC 1034 §1 explains why the host table gave way to a distributed database.
  • RFC 8499: DNS terminology (stub resolver, recursive resolver, zone, referral, glue).
  • RFC 2308: negative caching and how TTLs bound it.

DNS series

  1. How DNS works (this post)
  2. Inside a DNS packet
  3. Encrypting DNS
  4. How malware abuses DNS

Practical companion: Which resolver to choose.

Last updated on
-- views