Follow the Trail

From the root to the truth

The situation

Where does an answer actually come from? `dig +trace` makes the resolver show its working — walking from the **root**, to the **TLD** (`.com`), to the **authoritative** server that holds the real record. Watch a name resolve from scratch.

A cold recursive query walks the hierarchy: **root → TLD → authoritative**. Each level only knows where to ask next; the authoritative server gives the final answer. `dig +trace` does this walk in front of you.

💡Only the **authoritative** server's answer is the source of truth. Everything above it is just delegation — pointers to who to ask.

The query path

💻

you

stub

🧭

resolver

recursive

🌳

root

🏷️

TLD

.com

📜

auth

example.com

the recursive resolver walks the tree → the authoritative server gives the final answer

The recursive resolver does the walking; your stub just waits for the answer.

▶

4:00

Video explainer · coming soon

Recursive vs authoritative DNS

Who walks the tree, who holds the truth, and why it matters in an outage.

📖

Want the full operator version?

Recursive vs Authoritative DNS

The full operator view of recursion, delegation, and caching.

6 min · intermediate · Open the guided deep dive →

Why it matters in production: When a record is wrong everywhere, `dig +trace` tells you whether the problem is at your resolver, the delegation, or the authoritative zone itself.

Objective

Trace example.com from the root and identify the authoritative server that gives the final answer.

learner@nameforge

The Nameforge lab is live. Type `help` to see what this lab understands.

Use the chips below to get started — then go off-script.

learner@nameforge:~$

Evidence

○Traced the query from the root
○Saw the walk begin at the root
○Reached the authoritative server

Next: Run `dig +trace example.com`.

Hints

Stuck? Reveal hints one at a time — the validation panel already tells you what evidence is missing.