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 → .com → example.com) plus caching controlled by TTL.
| Record type | Typical use |
|---|---|
| A / AAAA | IPv4 / IPv6 address for a name |
| CNAME | Alias to another name (another lookup follows) |
| NS | Which nameserver is authoritative for a zone |
| TXT | Arbitrary text (SPF, DKIM, ACME challenges) |
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 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.
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 AYou will see referrals from root to .com to the authoritative nameservers for example.com.
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 +answerExample line (numbers illustrative):
api.example.com. 300 IN A 203.0.113.50Here 300 seconds is how long many resolvers will cache that A record.
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 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.
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| Short TTL | Long TTL |
|---|---|
| Faster propagation on changes | Fewer queries, cheaper, more “sticky” during incidents |
| More load on authoritative NS | Stale answers linger after mistakes |
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.
Your browser already cached api.example.com → 203.0.113.10 — no network round trip, the tab resolves instantly.