How to debug DNS issues with dig, nslookup, and traceroute

This guide walks through a systematic DNS debugging workflow using three command-line tools: nslookup, dig, and traceroute. By the end, you will have a repeatable process for diagnosing DNS resolution failures, tracing delegation paths, and identifying network-level routing problems.

What You Need Before Starting

• A Linux or macOS system with terminal access
• The dig command (part of the dnsutils or bind-utils package)
• The nslookup command (part of the same package as dig)
• The traceroute command (pre-installed on most systems)
• The domain name or IP address you want to debug

Install all three tools on Ubuntu or Debian with one command:

sudo apt install dnsutils traceroute

On macOS, all three tools ship with the operating system.

How the Three DNS Tools Work Together

Each tool in this guide serves a distinct role in the DNS debugging process.

nslookupperforms quick DNS lookups and confirms whether a domain resolves at all. The nslookup command queries a DNS server and returns the IP address mapped to a domain name. Use nslookup as the first step to establish a baseline.

dig (Domain Information Groper)provides detailed DNS query output including TTL values, authoritative flags, query timing, and the full delegation path. The dig command sends queries to specific DNS servers and displays the raw DNS response. Use dig when nslookup confirms a problem and you need to identify the exact cause.

traceroutemaps the network path between your machine and a destination server. The traceroute command sends packets with incrementally increasing TTL values to discover each router (hop) along the route. Use traceroute when DNS resolves correctly but the destination is unreachable — the issue may be a network routing problem rather than a DNS problem.

Step 1: Verify Basic DNS Resolution with nslookup

nslookup provides the fastest way to check whether a domain resolves to an IP address. Run a basic query to establish whether DNS resolution works at all.

nslookup example.com

The nslookup command returns the DNS server used for the query and the resolved IP address:

Server:    127.0.0.53
Address:   127.0.0.53#53

Non-authoritative answer:
Name:    example.com
Address: 93.184.216.34

A successful response means DNS resolution works from your machine using your configured resolver. The "Non-authoritative answer" label indicates the response came from a DNS cache rather than the domain's authoritative nameserver.

Check DNS Resolution Against a Specific Server

nslookup can query a specific DNS server to determine whether the problem is isolated to your configured resolver. Test against a public DNS server like Google Public DNS (8.8.8.8) or Cloudflare DNS (1.1.1.1):

nslookup example.com 8.8.8.8

If the domain resolves against a public DNS server but fails against your local resolver, the problem lies in your local DNS configuration — check /etc/resolv.conf on Linux or your network adapter's DNS settings.

Check Specific Record Types with nslookup

nslookup retrieves specific DNS record types by setting the query type. Check MX records for email configuration:

nslookup -type=MX example.com

Check nameserver (NS) records to verify the domain's authoritative DNS servers:

nslookup -type=NS example.com

For a full walkthrough of nslookup query types, see the nslookup article.

Step 2: Perform Detailed DNS Analysis with dig

dig provides richer diagnostic output than nslookup. Use dig when you need TTL values, response timing, authoritative flags, or the full delegation chain.

Query a Specific Record Type with dig

Run a dig query for the A record (IPv4 address) of a domain:

dig example.com A

The dig command returns a structured response with multiple sections:

;; ANSWER SECTION:
example.com.    86400   IN  A   93.184.216.34

;; Query time: 42 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)

The ANSWER SECTION shows the resolved record. The TTL value (86400 seconds = 24 hours) indicates how long DNS caches will store this response. The Query time reveals the DNS lookup latency.

Query an Authoritative Nameserver Directly with dig

dig can bypass DNS caches and query the authoritative nameserver directly. First, find the authoritative nameserver:

dig example.com NS +short

Then query that nameserver directly for the A record:

dig @a.iana-servers.net example.com A

Querying the authoritative server eliminates DNS cache as a variable. If the authoritative server returns a different result than your local resolver, the problem is stale cache data. Flush your local DNS cache to resolve it.

Trace the Full DNS Delegation Path with dig

The +trace flag instructs dig to follow the entire DNS resolution path from the root servers down to the authoritative nameserver. This reveals broken delegations — the most common cause of DNS failures that are not related to the domain itself.

dig example.com +trace

The dig +trace output shows each step of the resolution chain:

.                   518400  IN  NS  a.root-servers.net.
com.                172800  IN  NS  a.gtld-servers.net.
example.com.        172800  IN  NS  a.iana-servers.net.
example.com.        86400   IN  A   93.184.216.34

A broken delegation appears as a gap in this chain — one level returns nameserver records that point to servers which do not respond or do not have the zone configured. The dig +trace output pinpoints exactly where the chain breaks.

For more dig techniques, see the dig article.

Step 3: Flush DNS Cache to Eliminate Stale Data

DNS caching can mask changes or cause stale records to persist. Flush the local DNS cache before concluding that a DNS change has not propagated.

=== "Ubuntu / Debian (systemd-resolved)"

sudo systemd-resolve --flush-caches

=== "macOS"

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

After flushing, re-run the dig and nslookup queries from Steps 1 and 2. Compare the TTL values — a freshly resolved record has a TTL matching the authoritative zone's configured value, while a cached record has a decremented TTL.

Step 4: Trace the Network Path with traceroute

traceroute identifies network routing problems that are separate from DNS. If DNS resolution succeeds (Steps 1–2) but the destination is unreachable, traceroute reveals where packets stop along the network path.

traceroute example.com

The traceroute command displays each hop between your machine and the destination:

 1  gateway (192.168.1.1)  1.234 ms  1.112 ms  0.998 ms
 2  isp-router (10.0.0.1)  8.456 ms  8.321 ms  8.198 ms
 3  * * *
 4  destination (93.184.216.34)  42.567 ms  42.432 ms  42.301 ms

Each line represents one hop. The three time values show round-trip time (RTT) for three probe packets. Asterisks ( * * *) indicate a hop that did not respond — this usually means the router blocks ICMP or UDP probe packets rather than an actual failure.

Interpret traceroute Results for DNS Debugging

traceroute results fall into three categories:

All hops respond, destination reached.The network path is healthy. If the service is still unreachable, the problem is at the application layer — check the web server, firewall rules, or port configuration.

Hops stop responding at a specific point.A firewall or routing issue blocks traffic at that hop. Contact the network administrator for the hop where packets stop. This is unrelated to DNS.

High latency at specific hops.Consistently high RTT values at a particular hop indicate congestion or a slow link. Compare the latency pattern across multiple traceroute runs to distinguish transient congestion from a persistent problem.

For more traceroute techniques, see the traceroute article.

Step 5: Combine Results to Identify the Root Cause

Use this decision tree to map your findings to the root cause:

How to Verify the DNS Issue Is Resolved

After applying a fix, verify the resolution with all three tools:

1. Run nslookup example.com to confirm the domain resolves to the expected IP address.
2. Run dig example.com A +short to verify the correct record and check the TTL value.
3. Run traceroute example.com to confirm the network path reaches the destination.

Compare the results against the expected values. A fully resolved DNS issue produces consistent results across all three tools, returns the correct IP address, and shows a complete network path to the destination.

What to Do Next

• For individual tool references, see the dig article, nslookup article, and traceroute article.
• To debug web server issues after confirming DNS works, see the Web Server Setup Guide.
• To configure DNS records for your domain, consult your DNS provider's documentation.