How a DNS trace works
DNS is built as a chain of handoffs. The root nameservers know who runs .com. The .com nameservers know who runs example.com. And that domain's own nameserver holds the final record. Normally a public resolver does this whole walk for you and just hands back the result. This tool does the walk itself, in the open, so you can watch every handoff instead of trusting a single cached answer.
Root→.com→example.com→AnswerAt each stop, a server either hands back the answer or points the trace one step closer to it.
What each step tells you
A referral names the servers for the next zone instead of supplying the final record. Follow those server names to see which provider becomes responsible at each step.
Sometimes those next nameservers live inside the very domain you are looking up, like ns1.example.com serving example.com. That creates a loop: to find the nameserver you would need to look up the domain, but to look up the domain you need the nameserver. Glue is how DNS breaks the loop. The parent zone tacks the nameserver's IP address straight onto the referral, so the trace can move on without getting stuck. When you see glue in a step, that is the shortcut address that came bundled with the referral.
For each step, the trace keeps everything together: the server it asked, how long the reply took, the response code, the nameservers it was pointed to, any glue, the TTL, and the raw reply. That way you can trace where every detail came from.
Where a DNS trace can stop
A trace can finish with the requested records, NXDOMAIN for a nonexistent name, or a valid NOERROR response with no records of the requested type. That last case is often called NODATA. An existing name does not need to have every record type, so an empty AAAA answer is not automatically a failure.
| Where it stops | What that usually means |
|---|---|
| At the root | The top-level domain, like the part after the last dot, may not exist, or the trace never reached a root server in the first place. |
| At the TLD | The .com or other TLD zone did not hand off the domain to any nameservers, so there was nowhere to go next. |
| Before the domain's server | The handoff named some nameservers, but the trace could not find a usable public address to reach them. |
| At the domain's server | Inspect the response code. A timeout, refusal, or SERVFAIL differs from a valid empty answer for the requested type. |
| After an alias | The name is a CNAME pointing somewhere else, and that target is missing, unreachable, or points back in a loop. |
DNS trace and DNS lookup are different
DNS Lookup tells you the answer a resolver like Cloudflare, Google, or an authoritative server is handing out right now. DNS Trace Explorer skips those cached answers and walks the chain of handoffs from the root instead. Reach for the lookup when you want the answer real people are getting. Reach for the trace when you want to understand how DNS gets to that answer, or why it cannot.
The trace runs from the stack127 server, so it shows what that one machine sees. It cannot tell you what your ISP has cached, and it does not test whether a change has spread worldwide. It can display DNSSEC records, but the DNSSEC chain checker is the tool that verifies their signatures and chain of trust. The submitted name is sent to the servers involved in resolving it, so this is not a private-network or browser-only check.
For the terminology behind referrals and negative answers, see RFC 8499. If the trace completes but people still get different answers, compare the sources with the DNS change checker.