010 · DNS · RESOLUTION · NAMESERVER

DNS

How domain names resolve to IP addresses — the internet's phone book.

If you are new here: DNS turns hostnames (api.example.com) into IP addresses (93.184.216.34). It looks like one lookup; under the hood it is delegation (root → .comexample.com) plus caching controlled by TTL.

Record typeTypical use
A / AAAAIPv4 / IPv6 address for a name
CNAMEAlias to another name (another lookup follows)
NSWhich nameserver is authoritative for a zone
TXTArbitrary text (SPF, DKIM, ACME challenges)

The Problem

You type api.example.com and expect the right IP in milliseconds. DNS is the distributed naming system that answers that question — not a single database, but cached delegation from root to authoritative servers. When your laptop already cached the answer, a cache hit skips the internet entirely.

In plain terms: DNS is the internet’s phone book — humans remember names, routers need numbers, and TTL decides how long answers are sticky.

Analogy: Asking a librarian for a book — sometimes they remember from yesterday (cache), sometimes they walk the stacks chain (delegation) to the real shelf (authoritative).

When the stub cache is cold

When the stub has no valid entry, it asks a recursive resolver (your ISP, Cloudflare 1.1.1.1, Google 8.8.8.8) to do the heavy lifting.

Walking the chain

Recursives start from hints to the root, follow referrals to the TLD (.com), then to the authoritative zone that owns your record. CNAME or A answers eventually land on an IP.

Trace delegation (example):

dig +trace api.example.com A

You will see referrals from root to .com to the authoritative nameservers for example.com.

TTL caching

Each answer carries a TTL — how long resolvers may reuse it. TTL trades freshness for load on authorities.

See TTL on an answer:

dig api.example.com A +noall +answer

Example line (numbers illustrative):

api.example.com.  300  IN  A  203.0.113.50

Here 300 seconds is how long many resolvers will cache that A record.

When TTL expires

After expiry, resolvers must re-query. That is why DNS changes propagate slowly and why you lower TTL before a migration.

Playbook before a cutover: Lower TTL (e.g. 300s) 24–48h ahead; make the change; after stable, raise TTL again if you want less query load.

CNAME indirection

CNAME records point names to other names — common for CDNs. Each hop adds a lookup; misconfigured loops break resolution.

Example: www.example.com → CNAME → example.cdn-provider.net → A record at the CDN.

Operational reality

Blue‑green cuts and failover often pre-lower TTL, then publish new authoritative data and wait for old caches to die.

Authoritative check (asks a specific nameserver, bypassing your stub cache):

dig @ns1.example.com api.example.com A

Trade-offs

Short TTLLong TTL
Faster propagation on changesFewer queries, cheaper, more “sticky” during incidents
More load on authoritative NSStale answers linger after mistakes

Why this matters for you

DNS is config-as-code: IaC your zones, review changes, audit who can update registrar and DNS accounts — hijacked DNS bypasses TLS by pointing clients at the wrong host.

DIAGRAMDrag nodes · pan · pinch or double-click to zoom
FRAME 1 OF 8

Your browser already cached api.example.com → 203.0.113.10 — no network round trip, the tab resolves instantly.