How DNS Works: Resolution, Hierarchy & Caching Explained

01 · Foundations

What is DNS?

DNS (Domain Name System) is the internet's phonebook — it translates human-friendly domain names like google.com into the numeric IP addresses machines actually use to route traffic.

Every device on the internet is ultimately reachable at an IP address — something like 142.250.190.14. Humans are bad at remembering numbers and good at remembering words, so DNS exists as a translation layer: type a name, get back an address. Without DNS, you'd need to memorize an IP address for every website you visit.

DNS usually runs before HTTP because the client needs an IP address before it can open the connection that carries the web request.

A single lookup can walk through a resolver, root, TLD, and authoritative server before returning an IP.

The defining characteristics

Hierarchical

The namespace is a tree: root → top-level domain (.com, .org) → domain (example.com) → subdomain (www.example.com). Each level delegates responsibility to the level below it.

Distributed

No single organization or server owns all of DNS. Root servers, TLD registries, and individual domain owners each manage their own slice of the namespace.

Cached everywhere

Browsers, operating systems, and recursive resolvers all cache answers, usually using TTL (time-to-live) as the freshness limit. In practice some layers cap TTLs or retain data differently, which is why caching behavior is similar in spirit but not perfectly identical everywhere.

Primarily UDP-based

Most DNS queries fit in a single small UDP exchange — no handshake, no connection state, just a fast query/response. DNS also uses TCP for cases like zone transfers and truncated or larger responses, covered in more detail in Engineering Insights.

Interactive

Visual Learning

Watch one domain name travel the full resolution chain — recursive lookup, multi-layer caching, every record type, propagation, failover, and load distribution — as a single continuous system, not twelve separate explanations.

02 · History

Why DNS Exists

Before DNS (1983), the entire internet's name-to-address mapping lived in a single text file — HOSTS.TXT — manually updated and distributed by one organization.

In the early ARPANET, every host on the network was listed in a single HOSTS.TXT file maintained by the Stanford Research Institute. Administrators emailed in changes, and the master file was periodically downloaded by every machine on the network. This obviously didn't scale: as the network grew, the file grew, updates became stale faster than they could propagate, and there was no way to delegate control of a name to whoever actually owned it.

Paul Mockapetris designed DNS in 1983 specifically to solve this: replace one giant centrally-managed file with a distributed, hierarchical, delegatable naming system where anyone could register and manage their own subtree of the namespace, and lookups would be resolved dynamically over the network instead of from a static local file.

03 · Naming

Domain Names & IP Addresses

A domain name is a human-readable label; an IP address is the numeric address a network actually routes packets to. DNS is the bridge between the two.

Domain name structure

Read right to left: www.shop.example.com — . (implicit root) → com (TLD) → example (second-level domain, the one you register) → shop (subdomain) → www (another subdomain). Each dot marks a delegation boundary.

IPv4

A 32-bit address written as four dotted decimal octets, e.g. 93.184.216.34. Only about 4.3 billion unique addresses exist — long since exhausted for direct allocation, which is part of why IPv6 and techniques like NAT exist.

IPv6

A 128-bit address written as eight colon-separated hex groups, e.g. 2606:2800:220:1::1. Effectively unlimited address space, designed to replace IPv4 long-term.

04 · Structure

The DNS Hierarchy

DNS is organized as an inverted tree, and every query walks down it one delegation at a time.

Root servers

13 logical root server addresses (backed by hundreds of physical servers worldwide via anycast) sit at the very top. They don't know any domain's IP — they only know which server is authoritative for each top-level domain (.com, .org, .net, country codes...).

TLD servers

Top-level domain servers (e.g. Verisign for .com) know which nameservers are authoritative for every domain registered under that TLD — but not the domain's actual records.

Authoritative nameservers

The final stop — these servers actually hold the records (A, MX, TXT, etc.) for a specific domain, managed by whoever owns that domain (or their DNS provider, like Cloudflare or Route 53).

Worked trace: resolving www.example.com (illustrative)

textTrimmed, illustrative `dig +trace www.example.com` shape — the NS names, TTLs and the 192.0.2.80 answer (an RFC 5737 documentation address) are examples, not live data

$ dig +trace www.example.com

.                 518400 IN NS   a.root-servers.net.        ← 1. root zone: who serves "."
com.              172800 IN NS   a.gtld-servers.net.        ← 2. root referral: ask a .com TLD server
example.com.      172800 IN NS   ns1.example-dns.net.       ← 3. TLD referral: ask the zone's authoritative server
www.example.com.     300 IN A    192.0.2.80                 ← 4. authoritative answer (final)

Each step returns a referral (NS records) until the last server answers with the actual A record. A recursive resolver does this walk once, then caches each result for its own TTL: the NS referrals for hours or days, the final A record for 300 s here. That is why most later lookups for the same name never leave the resolver.

05 · Data model

DNS Records

A DNS zone is just a set of typed key-value records — each type serves a different purpose.

The most common record types and what each one maps.

A / AAAA

The core mapping: hostname → IPv4 (A) or IPv6 (AAAA) address. This is what almost every lookup ultimately resolves to.

CNAME

An alias — points one hostname to another hostname (which is then resolved again). Commonly used for www.example.com → example.com, or pointing a custom domain at a third-party service.

MX

Mail exchange — tells the internet which server(s) handle email for a domain, with a priority value for failover ordering.

TXT

Arbitrary text — used for domain ownership verification and increasingly for email security (SPF, DKIM, DMARC records all live here).

NS

Declares which nameservers are authoritative for a zone — this is literally what a referral response contains as a resolver walks down the hierarchy.

06 · Server roles

Recursive Resolver & Authoritative Nameserver

These two server roles are the ones learners mix up most — and they behave completely differently.

Recursive resolver

The server your client actually talks to (often your ISP's, or a public one like 8.8.8.8 / 1.1.1.1). It does all the work of walking the hierarchy on your behalf and returns one final answer. It also caches aggressively — this is the layer that benefits the most from caching, since it's shared across every client using it.

Authoritative nameserver

The server that actually holds the real records for a domain — the source of truth. It never queries anyone else on your behalf; it just answers directly from its own zone data (or says "no such record").

07 · Performance

DNS Caching & TTL

Caching is what makes DNS fast in practice — a full hierarchical lookup only happens once per TTL window, not on every request.

Each layer is checked before falling through to the next — most lookups never reach the authoritative server.

TTL (time-to-live)

A number of seconds, set by the domain owner on each record, telling caches how long they should normally be allowed to reuse an answer before refreshing it. In practice some software caps TTLs or may not expire cached data at exactly the same moment.

Browser cache

The smallest, shortest-lived cache — checked first, often capped at a low value (sometimes just 60 seconds) regardless of the record's actual TTL, for safety.

OS / resolver cache

The operating system's stub resolver and the recursive resolver both maintain longer-lived caches — the resolver's cache in particular is shared across every client using that resolver, amplifying the benefit.

This same TTL-driven caching idea reappears one layer up the stack: a CDN caches entire HTTP responses at the edge using the same freshness-window logic DNS applies to records.

08 · The other direction

Reverse DNS

Forward DNS answers "what IP does this name have?" Reverse DNS answers the opposite: "what name does this IP have?"

Reverse lookups use a special pseudo-domain — in-addr.arpa for IPv4 (with the IP's octets reversed) and ip6.arpa for IPv6 — and a dedicated record type, PTR. Unlike forward records, PTR records must be set up by whoever controls the IP address block (usually an ISP or cloud provider), not by the domain owner.

09 · Security

DNS Security (DNSSEC)

Plain DNS has no built-in way to verify that a response actually came from the real authoritative server and wasn't tampered with in transit — DNSSEC adds cryptographic signatures to close that gap.

The problem: cache poisoning

Because classic DNS responses are unauthenticated, an attacker who can guess or intercept a query can inject a forged response, poisoning a resolver's cache with a malicious IP for a legitimate domain.

The fix: signed records

DNSSEC adds a chain of cryptographic signatures from the root down to individual records, so a validating resolver can verify a response is authentic and hasn't been altered.

Key takeaways

DNS translates human-readable names into machine-routable IP addresses, replacing a single centrally-managed hosts file with a distributed hierarchy.
Resolution walks down a tree: root → TLD → authoritative nameserver, but recursive resolvers cache aggressively so most lookups never go that deep.
Records are typed (A, AAAA, CNAME, MX, TXT, NS, PTR) — each serving a distinct purpose beyond a simple name → IP mapping.
The recursive resolver does the work on the client's behalf; the authoritative nameserver is the actual source of truth.
TTL controls how long every cache layer may reuse an answer — the single biggest lever for both performance and change-propagation speed.
DNSSEC adds cryptographic authenticity to responses, closing the cache-poisoning gap in plain DNS.