Walk a name from the root down

short · 35 min · Objective 3.4

Task

Resolve a name the long way, one delegation at a time, from the root servers to the authoritative answer. Recursive and iterative resolution is a definition question until you have done the iteration by hand.

Steps

  1. Ask the root servers where .com lives: dig @a.root-servers.net com NS +norecurse. Note that the root does not answer the question you asked; it refers you to the TLD servers. That referral is what "iterative" means.
  2. Ask one of those TLD servers about the domain: dig @a.gtld-servers.net example.com NS +norecurse. Again a referral, this time to the domain's authoritative servers.
  3. Ask an authoritative server for the actual record: dig @<authoritative> example.com A +norecurse. This one answers, and the answer is flagged authoritative — look for the aa flag.
  4. Now do it the short way and compare: dig example.com. Your resolver did all three steps on your behalf, which is what "recursive" means.
  5. Let dig show the whole walk automatically: dig +trace example.com. Compare its output against the three steps you did by hand.

Verify

dig +trace example.com | grep -E "NS|A" | head -12
dig example.com +noall +answer
dig example.com +noall +stats | grep -E "Query time|SERVER"
dig example.com | grep -E "flags:"

The trace must show the root, then the TLD, then the authoritative servers. Query the same name twice and the second query time should drop to near zero — that is the cache, measured. And the flags: line shows aa when you ask an authoritative server directly and omits it when you ask a resolver.

Notes

The vocabulary maps onto what you just did. Recursive is a resolver promising to do the whole job and return an answer. Iterative is what the root and TLD servers do — they answer with a referral, not a result. Authoritative means the server holds the zone rather than a cached copy.

The cache measurement is the best diagnostic habit from this lab. A name that resolves fast the second time is cached; a name that stays slow every time has a resolver problem or an unreachable authoritative server. And a stale cached answer after a record change is exactly what TTL controls — which is why you lower the TTL before a migration, not during it.