Troubleshoot Network Issues with dig and traceroute

By Khimananda Oli | Last reviewed: August 2026

When a service fails to connect or a website loads slowly, guessing wastes hours. You need to systematically isolate whether the failure is DNS resolution, routing, or application-layer rejection. Learning to troubleshoot network issues with dig and traceroute gives you the precise evidence required to distinguish between a misconfigured nameserver, a blocked port, and an upstream ISP outage. This guide provides the exact diagnostic workflow I use on production Ubuntu servers and cloud infrastructure.

How do you interpret dig output to confirm DNS resolution?

DNS failures are the most common cause of "site down" tickets that aren't actually outages. Before checking routes, you must confirm the name resolves correctly. The default dig output is verbose; for troubleshooting, specific flags isolate exactly what matters. If you are new to Linux server administration, reviewing Ubuntu network troubleshooting fundamentals helps contextualize these tools within the broader OS networking stack.

Essential dig flags for rapid diagnosis

• +short: Returns only the IP address(es). Use this first. If empty, resolution failed entirely.
• @server: Queries a specific nameserver (e.g., @8.8.8.8). Bypasses local cache to test authoritative data.
• +trace: Walks the entire delegation chain from root servers down. Critical for diagnosing broken NS records or glue record issues.
• +dnssec: Validates DNSSEC signatures. A missing RRSIG when expected indicates validation failure, not just absence.
• ANY: Deprecated and often filtered. Never rely on it. Query specific types: A, AAAA, CNAME, MX, TXT, NS.

<!-- Verify basic A record resolution -->
$ dig +short example.com
93.184.216.34

<!-- Test against Google DNS to bypass local resolver cache -->
$ dig @8.8.8.8 +short example.com
93.184.216.34

<!-- Full trace to diagnose delegation problems -->
$ dig +trace example.com
; <<>> DiG 9.18.28 <<>> +trace example.com
;; Received 28 bytes from 198.41.0.4#53(a.root-servers.net)

A common mistake is assuming a successful dig means DNS is fine. Check the ANSWER SECTION count and the flags. A response with status: NOERROR but zero answers means the name exists but has no record of that type — distinct from NXDOMAIN (name doesn't exist) or SERVFAIL (server error). In SOC 2 audit contexts, documenting these distinctions matters because SERVFAIL often signals infrastructure misconfiguration rather than user error.

Diagnosing TTL and caching anomalies

If dig returns correct results but users still see old content, check the TTL value in the full output. A TTL of 86400 means resolvers cache for 24 hours. During migrations, lower TTLs to 300 seconds at least 48 hours before cutover. After changes, use dig @resolver +noall +answer +authority to verify both the answer and which nameserver provided it — stale secondary servers frequently serve outdated zones without error.

What does traceroute reveal about packet forwarding paths?

Once DNS is confirmed, traceroute maps the Layer 3 path packets take to reach the destination. It works by sending packets with incrementally increasing TTL values; each router decrements TTL, discards expired packets, and sends back ICMP Time Exceeded. This reveals every hop, its latency, and where packets stop.

Choosing the right protocol mode

The default UDP mode is frequently blocked by firewalls. Always specify the protocol explicitly based on your target:

1. ICMP mode (-I): Best for general path discovery. Requires root/sudo. Most likely to pass through intermediate routers.
2. TCP mode (-T -p 443): Essential when testing connectivity to a specific service port. Uses SYN packets that mimic real application traffic.
3. UDP mode (default): Legacy behavior. High ports (33434+) are commonly filtered. Only useful if you specifically need to test UDP paths.

<!-- ICMP traceroute (requires sudo) -->
$ sudo traceroute -n -I example.com
 1  10.0.0.1      0.432 ms  0.389 ms  0.401 ms
 2  203.0.113.1   1.234 ms  1.198 ms  1.256 ms
 3  198.51.100.5  12.456 ms 12.389 ms 12.501 ms

<!-- TCP traceroute to HTTPS port -->
$ sudo traceroute -n -T -p 443 api.example.com
 1  10.0.0.1      0.445 ms  0.398 ms  0.412 ms
 2  * * *
 3  198.51.100.5  12.678 ms 12.543 ms 12.701 ms

The -n flag disables reverse DNS lookups at each hop, preventing artificial delays and avoiding confusion when PTR records are missing or incorrect. Always use it in production diagnostics.

Reading asterisks and asymmetric routing correctly

Three asterisks (* * *) at a single hop followed by responsive subsequent hops almost always means that router blocks ICMP TTL-exceeded messages — not that the path is broken. Cloud providers and transit networks routinely rate-limit control plane traffic. Only treat consecutive timeouts extending to the final destination as evidence of a routing black hole.

Asymmetric routing causes confusing traces where return paths differ from forward paths. If latency jumps dramatically at one hop then stabilizes, or if different runs show different intermediate IPs, the path is asymmetric. This is normal in ECMP and BGP-anycast environments. Correlate with mtr (which combines ping and traceroute statistically) to distinguish transient jitter from persistent loss.

How do dig and traceroute compare for different failure scenarios?

These tools solve fundamentally different problems. Using the wrong one wastes time. Understanding their complementary roles is central to efficient incident response, especially when coordinating with teams managing databases like those described in PostgreSQL administration essentials where connection failures may be DNS, network, or auth-related.

In practice, I run dig first in every connectivity investigation. If resolution succeeds and returns expected addresses, only then do I proceed to path analysis. This ordering eliminates ~40% of "network" tickets that are actually DNS propagation delays or stale local caches.

When should you escalate beyond dig and traceroute?

These tools diagnose Layers 3–4. Many production failures occur above this level. Recognizing their limits prevents wasted effort and guides escalation to the right team or tool.

Application-layer issues masquerading as network problems

If dig resolves correctly and traceroute reaches the destination with acceptable latency, but connections still fail, the issue is typically TLS negotiation, HTTP response codes, authentication, or application logic. At this point, switch to curl -v, openssl s_client, or application-specific debugging. For services behind observability stacks, correlating network diagnostics with metrics and traces (as covered in the four golden signals of monitoring) closes the gap between infrastructure health and user experience.

Cloud-native and container networking edge cases

In Kubernetes environments, pod-to-pod communication traverses overlay networks, CNI plugins, and service meshes that standard host-level traceroute cannot see. A successful external traceroute doesn't validate internal cluster networking. Use kubectl exec to run diagnostics from within pods, and leverage eBPF-based tools like Cilium's connectivity checker for in-cluster path validation. Similarly, VPC peering, Transit Gateways, and private endpoints introduce routing layers invisible to public traceroute — consult cloud provider flow logs and route table analysis instead.

Compliance and audit documentation requirements

For ISO 27001 or SOC 2 evidence collection, raw terminal output isn't sufficient. Capture timestamped outputs with context: dig +short example.com @8.8.8.8 | tee -a /var/log/netdiag/$(date +%F).log. Include the ticket reference, tester identity, and environmental notes. Automated evidence pipelines (using CI jobs or cron-triggered scripts) produce auditable artifacts that satisfy reviewers without manual screenshot collection. This discipline transforms ad-hoc troubleshooting into repeatable, compliant operational practice.

Building Reliable Network Diagnostics Into Your Workflow

Mastering how to troubleshoot network issues with dig and traceroute isn't about memorizing flags — it's about developing a systematic elimination mindset. Start every investigation with DNS verification before touching routing. Interpret traceroute asterisks skeptically. Know when to escalate to application-layer tools or cloud-specific diagnostics. Document findings with enough context for future incidents and audits.

If your team struggles with recurring connectivity incidents or needs help building automated diagnostic pipelines that satisfy compliance requirements, reach out to discuss your infrastructure. Structured troubleshooting saves more time than any single tool — and it's a skill that compounds across every platform you operate.