A normal dig asks one resolver and trusts its answer. dig +trace does something different and far more revealing: it performs the resolution itself, hop by hop, the way a recursive resolver would.

What +trace actually does

DNS is a delegated, hierarchical system. No single server knows everything; each level points you at the next. dig +trace example.com walks that chain and prints it:

  1. It starts by asking a root server about the name. The root does not know example.com, but it knows who runs .com, so it returns the NS records for the .com servers (a referral).
  2. dig then asks one of those .com servers, which likewise does not hold example.com but knows which servers are authoritative for it, and returns another referral.
  3. Finally dig asks one of the domain's own authoritative servers, which returns the actual answer.

Each step shows up as a set of NS records (the delegation) followed by the query to the next level down. The last block is the authoritative answer.

Why it is so useful

Because +trace follows the real chain instead of a cached copy, it shows you exactly where a problem lives. If the .com servers hand back the wrong NS records for your domain, you have a delegation problem at the registrar. If the delegation is right but the authoritative servers time out or disagree, the problem is at your DNS host. A plain lookup would just show a SERVFAIL or a stale answer; +trace shows which hop failed.

It is also the clearest way to understand DNS. Watching a name resolve from the root down, referral by referral, makes the hierarchy concrete in a way that a single answer never does.

Reading it well

A couple of things to keep in mind: +trace does its own iterative resolution, so it bypasses your configured resolver entirely, which is why its result can differ from a normal lookup when your resolver's cache is stale. And each referral is a set of NS records, not the final answer, so read down to the last block for the actual data. If a level returns records you did not expect, that level is where to look first.

+trace does not test your resolution path

+trace is the right tool for reading a delegation chain, and the wrong tool for proving that name resolution works, because it deliberately bypasses your resolver. It iterates from the root itself, asking each server in turn.

So +trace can succeed beautifully while every application on the host still fails, because what is broken is the resolver +trace never used — its forwarders, its cache, its access rules, or the path to it.

Use +trace to find out where a delegation is wrong. Use an ordinary query to find out whether resolution works. They answer different questions and the second one is usually the one being asked.