Skip to main content
Deprogit
Solutions Verified Editorial Review 6 min read

Network Diagnostics: Using Ping, Traceroute, and DNS Lookup

A masterclass in fundamental command-line network diagnostics: the mechanics of ICMP Echo, TTL decrementing in traceroute, and DNS record queries.

M

Md. Atik

• Updated Oct 2026
ICMP Echo Ping and Traceroute Hop Traversal Diagram
ICMP Echo Ping and Traceroute Hop Traversal Diagram

When network connectivity fails or latency degrades, network engineers do not rely on graphical diagnostic wizards. They turn to the command-line trio that has formed the backbone of IP troubleshooting for four decades: ping, traceroute (or tracert), and DNS lookup tools (nslookup, dig) [1, 2, 3].

While these utilities are simple to execute, interpreting their output accurately requires an understanding of underlying protocols—specifically ICMP message types, IP Time-To-Live (TTL) mechanics, and DNS query recursions [1, 2]. In this technical guide, we examine the inner workings of each tool, analyze common diagnostic output patterns, and explain how to avoid false conclusions [1, 2, 3].

1. Ping: Mechanics of ICMP Echo Request and Reply

The ping utility operates on the Internet Control Message Protocol (ICMP), defined in RFC 792 [1]. Unlike application traffic, ICMP messages are encapsulated directly in IP datagrams without a TCP or UDP transport layer [1].

How Ping Operates

  1. The sending host constructs an ICMP Type 8 (Echo Request) message containing a timestamp and payload sequence number [1].
  2. The destination host processes the datagram and responds with an ICMP Type 0 (Echo Reply) containing the identical payload.
  3. The sender calculates Round-Trip Time (RTT): $$\text{RTT} = \text{Time}{\text{Reply Received}} - \text{Time}{\text{Request Sent}}$$
C:\> ping 8.8.8.8 -n 4

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=14ms TTL=117
Reply from 8.8.8.8: bytes=32 time=15ms TTL=117
Reply from 8.8.8.8: bytes=32 time=14ms TTL=117
Reply from 8.8.8.8: bytes=32 time=14ms TTL=117

Ping statistics for 8.8.8.8:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 14ms, Maximum = 15ms, Average = 14ms

Analyzing Ping Metrics

  • Packet Loss: A loss rate greater than 0% indicates physical link errors, excessive interface buffer drops, or aggressive firewall rate-limiting [1].
  • Jitter (RTT Variance): Stable RTTs indicate a healthy path. Fluctuations between 15 ms and 250 ms suggest buffer congestion or wireless radio interference.
  • TTL Value: Reflects how many router hops the response traversed before reaching your workstation. Each router decrements the TTL field by 1.

2. Traceroute: Mechanics of Hop-by-Hop Discovery

While ping verifies whether a destination is reachable, traceroute (Unix/Linux) or tracert (Windows) maps the exact routed path taken by packets across intermediate Autonomous Systems [2].

How Traceroute Discovers Intermediate Routers

Traceroute exploits the IP header Time-To-Live (TTL) field [2]:

  1. Probe 1 (TTL = 1): The client sends a packet with TTL=1. The first-hop router decrements TTL to 0, drops the packet, and returns an ICMP Type 11 Code 0 (Time Exceeded) datagram back to the sender [1, 2]. The sender records Hop 1's IP address and RTT.
  2. Probe 2 (TTL = 2): The client increments TTL to 2. The packet traverses Hop 1 (TTL becomes 1) and reaches Hop 2, which decrements TTL to 0 and returns an ICMP Time Exceeded message.
  3. This process continues iteratively until the destination host is reached [2].
C:\> tracert deprogit.com

Tracing route to deprogit.com [172.67.182.204]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1 (Local Gateway)
  2     2 ms     2 ms     2 ms  10.200.0.1 (ISP Aggregation Router)
  3     4 ms     3 ms     3 ms  103.14.x.x (ISP Core Gateway)
  4     5 ms     4 ms     5 ms  ixp-dhaka.bdix.net [103.26.x.x]
  5    14 ms    14 ms    14 ms  172.67.182.204 (Destination)

Trace complete.

Critical Pitfall: Router ICMP Rate-Limiting

When a traceroute hop displays * * * Request timed out, junior administrators often assume the router has failed. In reality:

  • Router CPUs prioritize forwarding transit data plane traffic. Generating ICMP Time Exceeded replies is handled by the low-priority control plane [1, 2].
  • Many core routers rate-limit or discard ICMP generation. If subsequent hops (Hops 4, 5, etc.) respond with low latency and zero packet loss, the intermediate timeout is purely cosmetic and does not represent network degradation [2].

3. DNS Lookup: Querying Resource Records (dig & nslookup)

When an IP address is reachable via ping but the domain name fails to open in a web browser, the Domain Name System is the failure point [3].

Using nslookup for Rapid Record Verification

To verify specific DNS records (A, AAAA, MX, TXT):

# Querying A records for IPv4
nslookup deprogit.com

# Querying Mail Exchange (MX) records
nslookup -type=mx deprogit.com

# Querying SPF / DMARC verification TXT records
nslookup -type=txt deprogit.com

Using dig for Advanced DNS Debugging

On Linux, macOS, or advanced administration environments, dig (Domain Information Groper) outputs raw DNS header flags and authoritative response data [3]:

dig deprogit.com +trace

The +trace argument instructs dig to perform full iterative resolution—querying the IANA root nameservers (.), followed by top-level domain (TLD) nameservers (.com), and finally the domain's authoritative nameservers. This pinpoints the exact delegation stage where DNS records fail [3].

Diagnostic Utilities Comparison

Utility Underlying Protocol Primary Use Case Key Diagnostic Metric
Ping ICMP Echo (RFC 792) Reachability & link stability Packet loss %, Average RTT, Jitter [1]
Traceroute UDP/ICMP + TTL Exceeded (RFC 1393) Hop-by-hop path mapping Latency per hop, routing changes [2]
nslookup / dig DNS Port 53 UDP/TCP (RFC 1035) Name resolution & record verification Query status (NOERROR / NXDOMAIN), TTL [3]

Practical Troubleshooting Workflow

When troubleshooting a suspected network outage:

  1. Ping the Local Gateway: If ping 192.168.1.1 fails, resolve local Ethernet or Wi-Fi connectivity first.
  2. Ping a Known Public IP: If ping 8.8.8.8 succeeds, outbound routing is operational.
  3. Ping the Target Domain: If ping deprogit.com returns "could not find host," DNS resolution is failing.
  4. Run Traceroute: If pinging an external IP fails or spikes, execute tracert to pinpoint which autonomous router hop introduces packet loss [2].

For enterprise network architecture, routing diagnostics, and perimeter optimization, review our services on our Network Security Solutions page.

Key Takeaways

  • Ping uses ICMP Echo Request/Reply to measure round-trip time and packet loss across end-to-end paths.
  • Traceroute incrementally increases IP TTL values to elicit ICMP Time Exceeded messages from intermediate routers.
  • Asterisks (* * *) on intermediate traceroute hops often reflect CPU control-plane rate-limiting rather than network packet loss.
  • Tools like dig and nslookup isolate domain delegation failures from IP routing and transport problems.

Need help with this? Contact us.

Sources

[1] IETF, "RFC 792: Internet Control Message Protocol (ICMP)", 1981. URL: https://www.rfc-editor.org/rfc/rfc792.html (Standards-track foundational specification defining ICMP message types, Echo Request/Reply, and error reporting).

[2] IETF, "RFC 1393: Traceroute Using an IP Option", 1993. URL: https://www.rfc-editor.org/rfc/rfc1393.html (Standard defining traceroute packet traversal, Time-to-Live field decrementing, and ICMP routing signaling).

[3] IETF, "RFC 1035: Domain Names - Implementation and Specification", 1987. URL: https://www.rfc-editor.org/rfc/rfc1035.html (Standards-track core specification for DNS message formats, resource record types, and resolver query algorithms).

Last reviewed: October 2026

Share this technical guide:
Authentic Documentation

Sources & References

3 Verified Sources
  1. [1]

    IETF • 1981

    Claim supported: Foundational standards specification establishing ICMP message formats, Echo Request, and Time Exceeded messages.

  2. [2]

    IETF • 1993

    Claim supported: Standard RFC detailing traceroute packet mechanisms, Time-to-Live (TTL) field mechanics, and ICMP routing messages.

  3. [3]

    IETF • 1987

    Claim supported: Core standard defining DNS message syntax, query formats, resource records, and resolver mechanics.

Last reviewed: October 31, 2026 Deprogit Editorial & Authentic Source Policy
M
Published by Technical Team

Md. Atik

Engineering and network operations publication from Deprogit. Providing vendor-neutral guides on enterprise network architecture, web engineering, cloud infrastructure, and cybersecurity best practices.

Discussion (0)

Share your feedback, questions, or field experiences.

Leave reply ↓

No comments yet. Be the first to share your perspective!

Leave a Comment

Your email address will not be published. Required fields are marked *