Trace resolution and query authority

When a DNS answer looks wrong, you need to know where it went wrong. Three different views of the same name tell you that. Let’s build them one at a time.

View 1: the trace

Start by following the referrals from the root:

dig +trace flaviocopes.com

With +trace, dig does the iterative lookup itself. Root, then .com, then the flaviocopes.com nameservers. Your configured resolver isn’t involved.

This shows you the delegation path as it is right now. It does not show what any particular user’s resolver has cached. Different question, different tool.

View 2: ask authority directly

Next, find the authoritative nameservers and query one of them:

dig NS flaviocopes.com +short
authoritative_server=$(dig NS flaviocopes.com +short | head -n 1)
dig @"$authoritative_server" A flaviocopes.com +norecurse

+norecurse tells the server “answer only from what you hold, don’t go asking around”.

Look for the aa flag in the response. That’s the server telling you it’s authoritative for this data. A server can reply without being authoritative, so check the flag instead of assuming.

View 3: your recursive resolver

The plain query you’ve been running all along:

dig A flaviocopes.com

This is what your machine, and anyone using the same resolver, sees right now.

Read the three together

Each view isolates a layer:

1. dig A flaviocopes.com shows the recursive resolver’s answer, cache included.
2. dig +trace flaviocopes.com A shows where the parent zones send the lookup.
3. dig @"$authoritative_server" A flaviocopes.com +norecurse shows what the source publishes.

Now the diagnosis falls out of the differences.

Authority has the new value and the resolver has the old one? The resolver is holding a cached answer whose TTL hasn’t expired. Wait, or test through a different resolver.

The trace lands on nameservers you don’t recognize? The parent delegation is wrong. Fix it at the registrar.

The correct authoritative server returns the wrong value? The zone itself is wrong. Fix the record.

Two more habits

Query at least two authoritative servers when results don’t add up. A secondary can lag behind with stale data or a broken zone transfer.

And separate a clean negative answer from SERVFAIL or a timeout. NXDOMAIN means “not there”. SERVFAIL and timeouts mean something is broken.

+trace itself can fail on networks that block direct DNS traffic to the root servers, even while normal lookups work. Treat each command as one piece of evidence, not the verdict.

Try this: collect the recursive, trace, and direct-authority views for one hostname. For each way they could disagree, write a one-line diagnosis.