DNS Resolution, Start to Finish

Every time you type a domain into a browser, a chain of lookups fires off before a single packet reaches the site you want. Most of that chain is invisible, and most explanations of it stop at "it's like a phone book." Here's what actually happens, step by step, including the parts people usually skip.

The stub resolver is not smart

Your operating system doesn't do real DNS resolution on its own. It runs a stub resolver, a thin piece of code that just forwards your query to whatever DNS server is configured in /etc/resolv.conf on Linux or in your network adapter settings on Windows. Check yours with:

cat /etc/resolv.conf

That file usually points to your router (like 192.168.1.1), your ISP's resolver, or a public one like 1.1.1.1 or 8.8.8.8. The stub resolver has no cache logic of its own beyond what the OS or a local daemon like systemd-resolved provides.

The recursive resolver does the real work

Once your query hits a recursive resolver, that server takes over the job of finding the answer, even if it has to ask multiple other servers to get there. If the answer is already cached from a previous lookup, you get it back immediately. Check the TTL with:

dig example.com

Look at the ANSWER SECTION — the number before the record type (like 300 before A) is the TTL in seconds. That's how long resolvers are allowed to cache the record before asking again.

If nothing is cached, the recursive resolver starts a walk down the DNS hierarchy from the root.

Root, TLD, and authoritative servers

There are 13 root server addresses (a.root-servers.net through m.root-servers.net), each backed by many physical machines through anycast routing. The root server doesn't know where example.com lives, but it knows which servers handle .com, so it hands back a referral.

The resolver then asks a .com TLD server, which again doesn't know the final answer but knows which nameservers are authoritative for example.com specifically. You can see this delegation yourself:

dig +trace example.com

That command shows every hop: root, then TLD, then the authoritative nameservers for the domain, ending with the actual A or AAAA record. It's the single best command for understanding DNS visually instead of theoretically.

The authoritative nameserver is the last stop. It's the server the domain owner actually configured, often through a registrar's DNS panel or a service like Route 53 or Cloudflare DNS. This is the only server in the whole chain that has the real, canonical answer instead of a cached copy or a referral.

Record types you'll actually run into

An A record maps a name to an IPv4 address, AAAA does the same for IPv6. CNAME points one name to another name rather than an IP, which is how CDNs like Cloudflare or Fastly route traffic without exposing raw IPs. MX records handle mail routing, and TXT records carry arbitrary text, most commonly used now for SPF, DKIM, and domain verification strings. NS records tell the world which servers are authoritative for a zone, and that's the record type that makes delegation possible in the first place.

Where caching actually lives

Caching happens at multiple layers simultaneously: the browser itself (Chrome has its own DNS cache viewable at chrome://net-internals/#dns), the OS resolver cache, the local router, and the recursive resolver upstream. This is why a DNS change can appear to work instantly on one device and take hours to show up on another — you're not hitting the same cache.

When you lower a record's TTL before a planned migration, you're not speeding anything up immediately. You're just shrinking the window during which stale data can persist once the change actually happens. Do this at least one TTL cycle in advance, not five minutes before the cutover.

Why this matters for troubleshooting

When a site is unreachable, dig +trace tells you exactly which layer is broken: a root/TLD problem looks completely different from a misconfigured authoritative server or a stale cache on your own machine. Comparing dig example.com against a known-good resolver, like dig example.com @1.1.1.1, isolates whether the problem is your local resolver or the domain's actual DNS setup.

DNS looks simple from the outside because it usually resolves in under 100ms and nobody thinks about it. Underneath, it's a distributed, cached, hierarchical query system that's been running largely unchanged in structure since the 1980s, which is a pretty good argument for how well the original design held up.

If you want to go further with this, Korra Studio has related segments on DEFENSE_GRID covering DNS security extensions, DNS tunneling as an exfiltration technique, and building your own resolver from scratch in Python.