DNS Fundamentals

TL;DR

• DNS is a distributed, hierarchical, cached database mapping names to addresses (and other records) — resolution walks the tree from root to authoritative server.
• A recursive query returns one complete answer from a single resolver; an iterative query returns “here’s the next place to ask” and the caller keeps walking the chain.
• CNAME aliases a hostname to another hostname and cannot coexist with any other record type at the same name — this is a hard spec constraint, not a convention.
• TTL controls how long resolvers cache a record; lowering it well before a migration is the standard way to bound stale-IP blast radius after cutover.
• CoreDNS, Kubernetes Services, and Ingress hostnames are all built on top of this same standard DNS machinery — troubleshooting “why can’t my pod reach this hostname” always reduces to the mechanisms below.

Core Concepts

The DNS Hierarchy

                    . (root)
                      │
            ┌─────────┴─────────┐
           .com                .org
            │
      ┌─────┴─────┐
  example.com   google.com
      │
  www.example.com

DNS is a distributed, hierarchical database. Resolution walks this tree from the root down, delegating authority at each level: root nameservers know who’s authoritative for .com; the .com TLD servers know who’s authoritative for example.com; the example.com nameservers hold the actual records.

Record Types

Recursive vs Iterative Resolution

Client ──▶ Recursive Resolver ──▶ Root NS ──▶ TLD NS ──▶ Authoritative NS
   ▲              │                                            │
   └──────────────┴────────────────────────────────────────────┘
                        (final answer returned)

• Iterative query: each server gives the best answer it has, or a referral to the next server closer to the answer — the client (or recursive resolver) follows each referral itself.
• Recursive query: the client asks one resolver and expects a complete final answer — that resolver does all the iterative work on the client’s behalf and caches the result.

A laptop or container typically only ever performs recursive queries against a configured resolver (/etc/resolv.conf); that resolver performs the iterative legwork against the wider DNS hierarchy on the client’s behalf.

TTL and Caching

Every record carries a TTL (time-to-live) that governs how long any resolver in the chain may cache it before re-querying. Leaving TTL at a high default (e.g. 24 hours) during a planned migration means any resolver that already cached the old value keeps returning it for up to the full TTL duration, regardless of how quickly the authoritative record is updated. Standard mitigation: lower the TTL (e.g. to 60–300 seconds) days in advance of a cutover, let the low value propagate and expire any long-cached copies, perform the cutover, confirm stability, then raise TTL back to a normal value afterward.

CNAME Constraints

A CNAME record at a given name cannot coexist with any other record type at that exact same name (no A, TXT, MX, etc. alongside it) — this is a hard DNS specification rule, not a soft convention. Violating it causes zone validation failures or undefined, resolver-dependent behavior. This is why the root/apex of a zone (example.com itself) almost never uses a CNAME — the apex typically needs MX/TXT/NS records too — and instead relies on provider-specific mechanisms like an “ALIAS” or “ANAME” record that mimics CNAME behavior while remaining spec-compliant at the zone apex.

Recursive vs Iterative Query

Command / Configuration Reference

Query a specific record type directly:

dig example.com A
dig example.com CNAME
dig -x 8.8.8.8          # reverse lookup (PTR)

Trace the full iterative resolution path manually, bypassing any local cache:

dig +trace example.com

Check what resolver a host/container is configured to use:

cat /etc/resolv.conf

Quick resolution test without dig:

nslookup example.com
getent hosts example.com

Common Pitfalls

• Pitfall: dig example.com returns instantly while dig +trace example.com takes noticeably longer and shows many hops. Why: the plain query is recursive and may be served from cache by the configured resolver; +trace deliberately performs the full iterative walk from root through TLD to authoritative servers, bypassing cache. Fix: use dig +trace specifically to debug delegation/zone issues, not as a routine lookup — it is inherently slower by design.
• Pitfall: an A record is updated during an urgent migration but a fraction of clients keep hitting the old IP for hours afterward. Why: TTL was left at a high default (e.g. 24 hours), so any resolver that cached the old value keeps serving it until that TTL expires, independent of how fast the authoritative record changed. Fix: lower the TTL to a small value (e.g. 60–300 seconds) days before the planned cutover, wait for the old TTL to fully expire everywhere, perform the change, then raise TTL back once stability is confirmed.
• Pitfall: a zone fails validation, or a name behaves inconsistently across resolvers, after adding a CNAME alongside other records at the same name. Why: this violates the DNS specification directly — a CNAME must be the only record at that name. Fix: never combine CNAME with A/TXT/MX/etc. at the same name; at a zone apex that needs multiple record types, use a provider-specific ALIAS/ANAME record instead.

Interview Questions

• Why does dig +trace take longer than a normal dig query? — tests understanding of recursive vs. iterative resolution and caching layers.
• What operational risk does leaving TTL high create during a migration, and how do you mitigate it? — tests planning around DNS propagation and cache staleness.
• Why can’t a CNAME coexist with other record types at the same name, and how do zone apexes work around it? — tests depth on DNS spec constraints beyond surface-level record definitions.
• Walk through what happens, server by server, when a recursive resolver looks up www.example.com for the first time (cold cache). — tests the mental model of the full hierarchy walk (root → TLD → authoritative).
• What’s the practical difference between an A record and a CNAME, and when would each be the wrong choice? — tests whether the candidate understands aliasing implications (e.g. CNAME at apex).