How DNS Resolution Works

In one line

Your machine asks a recursive resolver, which walks the hierarchy from the root servers to the TLD servers to the domain's authoritative servers, caching each answer for its TTL.

0/4 · 0%

Think of it like this

Finding someone's office. You ask reception (the RECURSIVE RESOLVER). Reception doesn't know, so they ask the city directory (ROOT), which points to the district office (.com TLD), which points to the company's own receptionist (AUTHORITATIVE server), who finally gives the room number. Reception writes it down (CACHE) so next time is instant.

Key ideas

01
The resolution chain: STUB resolver on your machine → RECURSIVE resolver (your ISP's, 8.8.8.8, 1.1.1.1, or the VPC resolver at .2 in AWS) → ROOT servers (.) → TLD servers (.com, .in) → the domain's AUTHORITATIVE name servers (e.g. Route 53, AWS course Topic 7.2), which hold the actual records.
02
Every layer CACHES answers for the record's TTL. Most lookups never leave the recursive resolver's cache, which is why DNS is fast, and why changes take time to propagate.
03
On Linux, name resolution goes through /etc/nsswitch.conf (files first, then DNS), /etc/hosts (static overrides), and /etc/resolv.conf (which resolvers to use, plus search domains and ndots). systemd-resolved often sits in between at 127.0.0.53.
04
Negative answers are cached too: NXDOMAIN (the name doesn't exist) is cached for the zone's negative TTL (from the SOA record). Querying a name before you create it can leave a 'doesn't exist' answer cached for minutes.

Code & diagrams

DnsResolutiondiagram

Rendering diagram…

trace.shbash

dig +trace api.example.com          # walk the chain yourself from the root
cat /etc/resolv.conf                # which resolver? which search domains?
getent hosts api.example.com        # resolve the way applications do (honours /etc/hosts)

Explain it without notes

You changed a DNS record five minutes ago, but some users still reach the old server. Why, and what could you have done beforehand?

Practice

Run dig +trace for a domain you use. How many steps does it take, and which name servers are authoritative?

Trade-offs

↔
Long TTLs mean fewer queries, faster lookups, and resilience if your DNS provider has an outage; short TTLs mean faster changes and failover. Use short TTLs only where you actually need quick changes.

Done when you can

I can describe the stub → recursive → root → TLD → authoritative chain.
I know where Linux looks for resolvers and static entries.
I understand positive and negative caching and TTL-based propagation.