Skip to content
Browse

/flags/dig/dig-trace

dig +trace: follow DNS delegation from the root servers

The commands on this page have not been executed by our verification runner yet.updated
tool
dig / nslookup
command
dig
flag
+trace
default
off (dig asks one recursive resolver and prints its answer)

dig +trace example.com resolves the name the way a recursive resolver does, but shows every step: it asks a root server for the com. delegation, asks a com. server for example.com.'s name servers, then asks those authoritative servers for the record. Use it to see where a lookup goes wrong (a broken delegation, a missing glue record, a name server that does not answer) and to see the authoritative answer without any resolver cache in between.

Usage

bash
dig +trace example.com
dig +trace example.com MX
dig +trace +nodnssec example.com       # hide RRSIG/DS records to shorten the output
dig +trace @192.0.2.53 example.com     # @ only chooses where the root server list comes from

The output has one block per level. Each block lists the NS records returned for the next zone and ends with a line such as ;; Received 1170 bytes from 198.41.0.4#53(a.root-servers.net) in 20 ms, which names the server that answered at that step. The last block holds the authoritative answer.

Reading a failed trace

What you seeMeaning
The trace stops after the TLD step with a timeoutThe name servers listed for your domain do not answer (wrong NS at the registrar, server down, firewall)
Different NS sets in the TLD block and in your zoneDelegation at the registrar and NS records in the zone disagree; update one to match the other
NXDOMAIN from the authoritative serversThe record really does not exist in the zone those servers serve
Answer differs from dig without +traceA resolver cache still holds old data (wait for the TTL) or the resolver uses different servers

Notes

  • +trace sends iterative (non-recursive) queries itself, so it needs direct access to port 53 on the internet. On networks that allow DNS only to an internal resolver, it times out at the first step.
  • The first step asks the configured resolver (or @server) for the root NS list.
  • To query one authoritative server directly without tracing, use dig @ns1.example.com example.com +norecurse.
  • +trace implies +dnssec in recent BIND versions, which adds RRSIG and DS lines; add +nodnssec for a shorter view.

Sources

Related pages

cheat sheets · digdig cheat sheet: DNS lookups from the command linedig cheat sheet: query A, AAAA, MX, TXT and NS records, ask a specific server, use +short, +trace and -x, and read NOERROR, NXDOMAIN and SERVFAIL statuses.flags · digdig +short: print only the answer (IP address or record data)dig +short prints only the answer data, such as IP addresses or MX hosts, one per line for scripts. Empty output also hides NXDOMAIN, so check the status.codes · dnsDNS response codes (RCODE): NOERROR, NXDOMAIN, SERVFAIL, REFUSEDDNS RCODE values from 0 NOERROR to 23 BADCOOKIE: what NXDOMAIN, SERVFAIL, REFUSED and FORMERR mean, NODATA vs NXDOMAIN, and what to check for each one.compare · dnsA record vs CNAME record: differences and when to use eachAn A record maps a name to an IP; a CNAME makes it an alias of another name. A CNAME cannot share a name with other records, so the zone apex needs A or ALIAS.