DNS

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.

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.

Your laptop is not usually walking the entire DNS tree itself. It asks a recursive resolver, and that resolver either answers from cache or performs the delegation walk. This is why two users can see different behavior: they may be using different recursive resolvers with different cached answers.

Tiny example: your browser asks the OS for api.example.com; the OS asks 1.1.1.1; the resolver returns a cached A record with 127 seconds of TTL remaining. No authoritative server is contacted for that request.

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.

In plain terms: DNS resolution is delegation, not search. The root does not know your app IP; it knows who handles .com. The .com servers do not know your API IP; they know who handles example.com. The authoritative server finally owns the record.

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.

TTL is a trade-off knob. Short TTLs make migrations and failover easier, but increase query volume and dependence on authoritative DNS. Long TTLs reduce load and survive brief DNS provider issues better, but stale answers linger after mistakes.

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.

The “24-48h ahead” part matters because old long TTLs must age out before the lower TTL takes effect everywhere. Lowering TTL five minutes before a migration does not retroactively shorten answers resolvers already cached yesterday.

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.

CNAMEs are convenient because providers can change their own target IPs without asking you to edit your zone. The cost is indirection: debugging requires following the whole chain, and apex/root names have special constraints depending on DNS provider features.

Avoid long or circular chains. Each extra hop is another lookup and another place for TTLs, provider outages, or misconfiguration to surprise you during an incident.

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

Separate “authoritative says X” from “my laptop still sees Y.” Authoritative checks tell you what the zone currently publishes; ordinary resolver checks tell you what users may still receive from caches.

Incident move: during DNS problems, test multiple recursive resolvers and the authoritative nameserver directly. That tells you whether the issue is your zone, one resolver’s cache, or client-side caching.

Trade-offs

Use short TTLs around planned migrations, canaries, and failovers. Use longer TTLs for stable records where query cost and resilience matter more than instant changes. Do not use DNS TTL as your only high-availability plan for fast backend failure.

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.