How to Trace DNS Resolution: Debug Lookups with dig and nslookup

When a domain fails to resolve, loads slowly, or returns an unexpected IP, the root cause is almost always somewhere in the DNS resolution chain. A single lookup against your local resolver hides what actually happened — which nameservers were queried, which responded, and where the chain broke. To see the full story, you need a DNS trace.

This guide shows you how to trace a DNS resolution end to end using standard tools, read the output, and diagnose the most common failure modes.

What Is a DNS Trace?

A DNS trace is a step-by-step walk through the recursive resolution of a domain name, starting from the root nameservers and following the delegation chain all the way down to the authoritative nameserver for the domain. Unlike a standard lookup that returns only the final answer, a trace shows every intermediate query and response, making it possible to pinpoint exactly where a resolution fails or misbehaves.

How DNS Resolution Works (Quick Primer)

Every domain resolution follows the same hierarchy:

1. Root nameservers (.) — 13 logical servers that know which nameservers handle each top-level domain (TLD).
2. TLD nameservers (.com, .org, .fr, …) — delegate to the registered domain's authoritative nameservers.
3. Authoritative nameservers — hold the actual records (A, AAAA, MX, TXT, …) for the domain.

A recursive resolver (your ISP's DNS, 1.1.1.1, 8.8.8.8, Pi-hole, etc.) walks this chain on your behalf and caches the results. When you trace the resolution yourself, you bypass the cache and observe the raw delegation path.

Running a DNS Trace with dig

The dig command (part of bind-utils on Linux, bind9-dnsutils on Debian/Ubuntu, and shipped by default on macOS) is the standard tool for DNS debugging. Its +trace flag runs a full recursive trace from the root:

dig +trace example.com

The output lists, for each level, the nameservers queried and their responses. A typical trace for example.com looks like this:

;; global options: +cmd
.                       86400   IN      NS      a.root-servers.net.
.                       86400   IN      NS      b.root-servers.net.
...
;; Received 811 bytes from 192.168.1.1#53(192.168.1.1) in 4 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
...
;; Received 1174 bytes from 198.41.0.4#53(a.root-servers.net) in 12 ms

example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.
;; Received 289 bytes from 192.5.6.30#53(a.gtld-servers.net) in 24 ms

example.com.            86400   IN      A       93.184.216.34
;; Received 56 bytes from 199.43.135.53#53(a.iana-servers.net) in 18 ms

Each block shows the delegation at that level, the TTL, the nameserver that answered, and the query time. The final block contains the authoritative answer.

Alternatives: nslookup and drill

nslookup (available everywhere, including Windows) is simpler but less flexible. It does not support a recursive trace, but you can manually query each level:

nslookup -type=NS com.
nslookup -type=NS example.com. a.gtld-servers.net
nslookup example.com. a.iana-servers.net

drill (from ldns) is a modern replacement for dig with cleaner output and better DNSSEC support:

drill -T example.com

On Windows, Resolve-DnsName in PowerShell is the modern equivalent, though it does not produce a trace by itself.

Reading the Trace Output

Three fields matter when interpreting a trace:

• TTL (first number) — how long the record can be cached. A very low TTL (under 60 s) often signals load-balancing or a recent change; a high TTL (24 h+) means changes will propagate slowly.
• Source nameserver (from X.X.X.X#53(hostname)) — who answered at each step. If the same nameserver appears at multiple levels, something is misconfigured.
• Query time (in N ms) — latency to each nameserver. A single slow hop can add hundreds of milliseconds to every uncached resolution.

Common DNS Issues and How to Spot Them

• NXDOMAIN — the authoritative nameserver returns "name does not exist". Check for typos, expired domains, or incorrect delegation at the TLD level.
• SERVFAIL — a nameserver in the chain is unreachable or returning malformed responses. Run the trace twice: if the failing nameserver changes, the issue is transient; if it is consistent, the problem is on that specific server.
• Slow resolution — look at query times per level. A slow root or TLD query is rare and suggests local network issues. A slow authoritative query points to the domain operator.
• Stale data — if a trace shows the correct IP but your browser hits an old one, your recursive resolver is still caching. Flush with sudo resolvectl flush-caches (systemd-resolved), sudo dscacheutil -flushcache (macOS), or ipconfig /flushdns (Windows).
• Propagation issues — after a DNS change, different resolvers see different values until TTLs expire. Query several public resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9) to check consistency.
• Lame delegation — a TLD delegates to nameservers that do not answer authoritatively for the zone. Visible as a SERVFAIL from one or more nameservers while others work.

DNS Trace vs DNS Lookup: Know the Difference

A plain dig example.com hits your recursive resolver, returns the cached answer, and tells you nothing about the path. A trace bypasses the cache and walks the chain itself. Use a lookup to check the result; use a trace to debug the process.

When Tracing Is Not Enough

DNS is only half of a connection. Once a name resolves, your packets still have to find the server through BGP-routed networks. If DNS returns the right IP but the service is unreachable or slow, run a traceroute to the resolved address to see where the network path fails. Tools like TraceMapper combine both perspectives: they resolve the hostname, then visualize the network path hop by hop, so you can rule out DNS and focus on the actual route.

Key Takeaways

• Use dig +trace (or drill -T) to walk the full delegation chain from root to authoritative nameserver.
• Check TTLs, source nameservers, and query times at each level to identify which hop misbehaves.
• NXDOMAIN, SERVFAIL, and slow hops each point to different classes of problem — delegation, nameserver health, or latency.
• Flush local caches and query multiple public resolvers when diagnosing propagation issues.
• After a DNS problem is ruled out, a traceroute on the resolved IP completes the diagnostic picture.