How does DNS resolution work?

Question

IT Interview Practice · Accepted Answer

**DNS** (Domain Name System) is the internet's phone book: it translates a human-readable name like `example.com` into an IP address like `93.184.216.34`. Resolution is a hierarchical lookup, usually done for you by a **recursive resolver** (your ISP's or a public one like 8.8.8.8) that walks the tree of **authoritative** name servers on your behalf:

```text
Browser ──▶ Recursive Resolver ──▶ Root (.)          "ask .com's servers"
                     │        ◀──
                     ├────────▶ TLD (.com)            "ask example.com's servers"
                     │        ◀──
                     └────────▶ Authoritative         "example.com = 93.184.216.34"
                                (example.com)   ◀──
Browser  ◀── 93.184.216.34
```

The resolver asks the **root** servers (which know the TLD servers), then the **TLD** servers for `.com` (which know who is authoritative for `example.com`), then the **authoritative** server (which holds the actual record). To avoid repeating this every time, results are **cached** at every level — browser, OS, and resolver — each honoring the record's **TTL** (time-to-live). A warm cache resolves in microseconds; a cold lookup may cost several round trips.

Common **record types**: `A` (name → IPv4), `AAAA` (name → IPv6), `CNAME` (alias to another name), `MX` (mail servers), `TXT` (arbitrary text, used for SPF/verification), and `NS` (delegates a zone). You can inspect resolution directly:

```bash
dig example.com A       # shows the A record and which server answered
```

## Why it matters

DNS sits on the critical path of *every* request that starts from a name, so a slow or misconfigured resolver adds latency to everything. Interviewers like this question because it reveals whether you understand **hierarchy and caching** — the two ideas that let a global, distributed system answer billions of queries fast. It's also a frequent source of real production incidents ("it's always DNS"): expired records, wrong TTLs, or propagation delays after a change, so knowing how caching and TTL work is directly practical.

Why it matters

Related questions