DNS trace

Trace the DNS delegation path for a domain

DNS trace walks the delegation path for a domain name — from the DNS root, through each zone cut, to the nameservers that claim authority over the name you entered. Each delegation hop is a live query to the authoritative servers listed at that level — not a cached answer from a public recursive resolver.

Enter a domain above to see every hop: which nameservers manage each zone, the glue addresses that let the next hop run, and how each server responded — including timeouts, refusals, and cases where different servers disagree.

How Wirewiki traces DNS delegation

Wirewiki's trace is built for operators who need to see delegation health, not just the final answer a recursive resolver would return. It follows the same iterative idea as RFC 1034 section 5.3.3, but makes several choices that differ from dig +trace:

  • Delegation-focused queries. At every hop Wirewiki sends an NS query for your full domain name. That follows the chain of zone cuts (root → TLD → registrable zone → …) rather than tracing a single record type such as A.
  • Every nameserver at each level, in parallel. All NS hosts listed for a zone are queried at once. If they disagree, you get an Inconsistent responses switcher to compare each group's answer side by side — something a single-path dig +trace run will not show.
  • Root bootstrap via local resolver. The trace starts from a . NS query through Wirewiki's local resolver (not a static hints file on disk). That priming response may be cached briefly by TTL; every hop below the root is always queried fresh.
  • Glue filled in when missing. If a referral names in-domain nameservers but omits their addresses from the Additional section, Wirewiki resolves those hostnames through the same local resolver so the trace can continue. Strict iterative tracing would stall here.
  • Context on every glue IP. Each nameserver address shows ASN, country, anycast hints, and reserved-range labels where applicable — the same enrichment used across Wirewiki's DNS tools.
  • No sign-up, no upsell. Wirewiki does not sell DNS hosting or managed DNS; the tool is the product.

What is a DNS trace?

The DNS namespace is split into zones. Each zone is a contiguous subtree of names served by a set of authoritative nameservers. A delegation (zone cut) is where a parent zone publishes NS records pointing at the child's nameservers. Resolving any name therefore means walking down that ladder: ask who serves ., then who serves com., then who serves example.com., until you reach servers that answer authoritatively for the name you care about.

A DNS trace makes that walk visible. Instead of trusting a recursive resolver to hide the hops, you see each referral, each nameserver list, and each terminal outcome. That is the standard way to answer questions like "is my domain delegated to the right nameservers?", "did the registrar change propagate to the parent zone?", or "which hop is timing out?".

DNS delegation from the root zone down to a domain's authoritative nameservers
Each zone cut is one delegation step. Parent zones publish NS records; child zones publish authoritative NS at their apex.

How DNS delegation works

When an authoritative server does not hold the zone for your query name, it returns a referral: empty Answer section, NS records in the Authority section, the AA (authoritative answer) bit cleared, and often glue — A or AAAA records in Additional for nameserver hostnames that live inside the zone being delegated. Glue is bootstrap data so the resolver can open a TCP/UDP session to the next hop without another round trip.

At the zone that actually contains your name, one of several things happens. The server may return its own NS set in the Answer section with AA set (Wirewiki labels this authority over the domain). It may return a CNAME in Answer (the name is an alias — Wirewiki shows the target and stops). It may return NXDOMAIN (the name does not exist). Or it may return an SOA in Authority with AA set but no delegation NS — meaning the name falls inside that zone's tree even though this particular query was for nameserver records.

Iterative DNS trace querying nameservers from root to authority
Wirewiki queries every nameserver at each level in parallel, then follows referrals downward.

Reading your trace results

After you trace a domain, the results page is a top-down tree aligned with the delegation path.

  1. Root zone card. The first card lists the root nameservers Wirewiki obtained during bootstrap (home icon, zone label .). Each row is an NS hostname plus any glue addresses Wirewiki could reach.
  2. Delegation dividers. Between levels you will see a line labelled all servers delegate to, these servers delegate to, or this server delegates to — depending on how many parent servers agreed on the same referral.
  3. Zone cards. Each deeper hop is another card named after the referred zone (for example com. or example.com.) with the subtitle “These servers manage the … zone”.
  4. Terminal callout. The tree ends in a green or orange banner explaining the outcome: authority claimed, CNAME returned, NXDOMAIN, SOA containment, or server errors (timeout, unreachable, refused).
  5. Inconsistent responses. When parallel queries to sibling nameservers return different referrals or different terminals, a radio control appears so you can walk each branch separately. This is common during DNS migrations when parent and child zones are briefly out of sync.

Long nameserver lists collapse behind Show more when they exceed the card height — click to expand the full set. Every glue IP is clickable through to Wirewiki's IP and ASN pages where enrichment is available.

Worked example: tracing www.example.com

A typical trace for www.example.com looks like this:

  1. Root zone. Wirewiki lists the root nameservers (from priming) and queries each in parallel for www.example.com NS. They refer to the com. nameservers — a referral with glue for a.gtld-servers.net and siblings.
  2. com. zone. The com. servers refer to example.com.'s nameservers. If your registrar still points com. at old NS but your DNS host has already updated apex NS, you may see Inconsistent responses here — that is the migration signal.
  3. example.com. zone. The authoritative servers for example.com respond. Most often Wirewiki ends with a green banner: These servers claim authority over www.example.com and lists the zone's apex NS set. If the name is a CNAME, you see the alias target instead and the trace stops.

Registrar NS vs apex NS. The NS set in your registrar's delegation panel must match the NS records at the zone apex (example.com, not www). Trace shows both sides of that relationship: parent referrals come from the registrar's glue/NS, the terminal authority card shows what the zone itself publishes.

Response types you will see

Outcome What it means Typical next step
Referral (delegation card continues) This server is not authoritative for your name; Authority contains NS for a child zone and AA is not set. Follow the referred nameservers downward.
Authority (green callout) AA is set and the Answer section contains NS for the domain you traced. These are the nameservers the zone publishes for itself. Compare this list to what your registrar or DNS host claims to have published.
SOA (green callout) AA is set, Authority holds SOA, and the banner names the zone that contains your domain. The server is authoritative for a parent of your name but returned no NS in Answer for this query. Normal for some qnames; trace a child name or check NS at the zone apex separately.
CNAME (green callout) Answer contains a CNAME. Wirewiki shows the alias target and stops. Run a new trace on the canonical name if you need to continue past the alias.
NXDOMAIN (orange callout) The server claims authority but says the name does not exist. Confirm spelling; check whether the name should exist in this zone; look for a stale cut above.
Error (timeout / unreachable / refused / SERVFAIL) The nameserver never returned a usable response, or returned SERVFAIL. Test reachability to that host and port 53; fix firewall, lame delegation, or zone/DNSSEC errors on the server.

Wirewiki vs dig +trace

dig +trace is the usual command-line reference for tracing DNS. Wirewiki is complementary: it is built for delegation troubleshooting at scale, not for reproducing a single resolver's cached path.

Aspect dig +trace Wirewiki DNS trace
Default question Traces whatever QTYPE you pass (often A) NS for your full domain at every hop
Nameservers queried One server chosen from each referral (implementation-dependent) All NS hosts at each level, in parallel
Disagreeing servers You see one path per run Branch switcher when responses diverge
Cache No cache inside +trace Live queries at each delegation hop; root priming may be cached by TTL
Root bootstrap Static root hints file Live . NS query via local resolver
Missing glue May stall or resolve NS names separately Resolves missing in-domain glue via local resolver
CNAME handling Prints CNAME and stops Same — shows CNAME, does not chase
Enrichment Raw DNS wire format ASN, country, provider hints on glue IPs

Common problems and what to check

What you see Likely cause What to verify
Trace stops before the expected zone Missing in-domain glue in the referral, or nameserver IPs unreachable Additional section of the previous hop; firewall path to port 53
Inconsistent responses between branches Parent and child NS sets out of sync during a migration Registrar glue vs child apex NS; TTL not expired everywhere
Orange NXDOMAIN at the zone you control Name not in zone file, or wrong zone cut above Zone file / DNS panel; whether the name should be a CNAME elsewhere
Errors on every server in a card Lame delegation, network block, or server down Ping/traceroute to NS host; TCP/UDP 53 from your network
Authority NS list ≠ registrar NS Stale parent delegation or wrong child apex Registrar delegation vs DNS host apex NS records
CNAME at the name you traced Expected for aliases; trace continues at the target Re-run trace on the canonical name

Trace DNS delegation from the command line

macOS, Linux (dig)
dig +trace example.com
Copied
macOS, Linux (NS delegation only)
dig +trace example.com NS
Copied
Windows (nslookup debug)
nslookup -debug example.com
Copied

dig +trace uses your system's resolver for glue resolution in some cases and follows one server per hop. For the parallel, glue-enriched view Wirewiki shows, use the trace above or share a results URL with a colleague.

DNS trace shows who should answer for a name. These tools answer the next questions once delegation looks correct:

  • DNS lookup — all common record types from the authoritative nameservers in one view.
  • DNS propagation — compare answers from public and local resolvers after you change a record.
  • NS lookup — focus on the nameserver set and glue for a zone apex.
  • DNS history — see how published records changed over time for archived domains.
  • SPF lookup — walks include chains in TXT records (a different kind of DNS tree).

Frequently asked questions

Is DNS trace the same as DNS propagation check?

No. Propagation compares final answers from many recursive resolvers around the world. Trace walks the authoritative delegation chain from the root downward and shows each zone's nameservers. Use trace to verify delegation; use propagation to see whether resolvers have picked up a record change.

Why does Wirewiki query NS instead of A?

An NS query at each hop follows zone cuts directly. An A trace still hits referrals on the way down, but terminal shapes differ (you may end on an address record instead of the zone's nameserver list). Wirewiki optimises for "who is authoritative for this name?" — the question operators ask when debugging delegation.

What does “Inconsistent responses” mean?

Wirewiki queried every nameserver at a zone level in parallel and got materially different answers — different referral targets, different authority claims, or a mix of success and timeout. That usually indicates partial propagation, a mistake in one nameserver's zone file, or a lame server still listed in NS.

Why can the trace continue when glue is missing?

Strict iterative resolution requires glue in the referral when the nameserver hostname lies inside the child zone. Wirewiki resolves those hostnames through its local recursive resolver so you can still see the next hop. That matches operational reality but is not identical to a purist dig +trace run with no helper resolver.

Does trace follow CNAME chains?

No. If a server returns a CNAME, Wirewiki displays it and stops — the same behaviour as dig +trace. Start a new trace on the canonical target if you need to continue.

Can I trace a subdomain separately from the apex?

Yes. Enter any domain name — www.example.com, mail.example.com, or example.com. The walk still passes through the same parent zones; only the terminal outcome may differ.

How is this different from traceroute?

Traceroute follows IP routing hops (ICMP/UDP) to a host. DNS trace follows DNS delegation — which nameserver refers you to which zone. A routing problem and a DNS problem can both make a site unreachable; they require different tools.

Are results cached?

Each trace issues live queries to the authoritative nameservers at every delegation hop. Wirewiki may cache the root priming response (the list of root servers) for up to its TTL; everything below the root is always fetched fresh. Re-run a trace after you change delegation to see the update. Authoritative servers may still serve their own cached negative answers within TTL — that is normal DNS behaviour on their side.

Does Wirewiki validate DNSSEC?

Queries include the DNSSEC OK (DO) bit so signed responses can carry signatures, but Wirewiki does not run a full chain-of-trust validation. A SERVFAIL from a validating-aware server may still appear as an error on the trace even when unsigned delegation looks fine.