Trace resolution and query authority

Run a trace to follow referrals from the root:

dig +trace flaviocopes.com

This makes dig perform iterative queries itself. It is different from asking your configured recursive resolver, so it is useful for seeing the delegation path. It does not show what a particular user’s resolver still has cached.

Then find the authoritative nameservers and ask one directly:

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

In the direct response, look for the aa flag and inspect the answer rather than assuming that any responding server is authoritative.

These three views isolate different layers:

1. dig A flaviocopes.com shows what your configured recursive resolver returns.
2. dig +trace flaviocopes.com A follows root and parent referrals.
3. dig @"$authoritative_server" A flaviocopes.com +norecurse asks the published source directly.

If authority has the new answer but a recursive resolver has the old one, the resolver probably has a cached answer whose TTL has not expired. If the trace reaches unexpected nameservers, investigate the parent delegation. If the correct authoritative server returns the wrong value, fix the zone itself.

Query at least two authoritative servers when results are inconsistent. One secondary may have stale data or a transfer problem. Also distinguish a valid negative answer from SERVFAIL or a timeout; they point to different causes.

+trace can fail on networks that block the direct DNS traffic it needs even when normal recursive lookups work. Treat every command as one piece of evidence.

Your action is to collect the recursive, trace, and direct-authority views for one hostname. Write a one-line diagnosis for each possible disagreement between them.