Articles

What ping, traceroute, ipconfig and dig can and cannot prove

What each basic network tool really answers, how to read its result, and the conclusions it does not support.

Reading: 6 minNetworking

Article cover: What ping, traceroute, ipconfig and dig can and cannot prove

Each of these four tools answers one narrow question about a network, and none of them, alone, proves that the network works or that a service is reachable. The useful skill is knowing which question each tool answers and which conclusions its output does not support.

The model: one question per tool, and what it does not prove

The four tools probe different things, so their results are evidence about different things: one protocol end to end, one path hop by hop, the local host only, one query to one resolver.

Tool Question it answers What it does not prove
ping Does an ICMP echo request reach the target, does a reply come back, and how long was the round trip? That the host is up, or that any service on it is reachable.
traceroute / tracert Which hops the probes pass through, and at which hop a probe stops being answered? That a silent hop is faulty, or that the return path is identical.
ipconfig / ip What is configured locally: addresses, routes, interfaces. Anything about the remote end.
nslookup / dig What a DNS server answers for a name, and how it answers. That the name is reachable, or that another resolver would agree.

Terms. ICMP (Internet Control Message Protocol) carries the probes ping and traceroute use; RTT (round-trip time) is measured by the tool itself; TTL (Time to Live) is the hop counter each router decrements; a hop is one routed step; a resolver is the DNS server a query is sent to.

ping: ICMP reachability and round-trip time

ping sends an ICMP Echo Request and waits for an Echo Reply (RFC 792; type 8 request, type 0 reply). The RTT printed on each line is measured on the sending host.

ping -c 4 192.0.2.10
ping -6 -c 4 r2.example.net

A failed ping does not mean the host is down: the request or the reply can be dropped by a firewall or a host policy, and firewalls may filter “even ICMP echoes”. A single success proves one round trip, for one protocol, on one path, at one moment. A ping that succeeds by IP address while failing by name points at name resolution, not connectivity.

traceroute / tracert: the hops the probes cross

traceroute exploits the TTL field (RFC 791; Hop Limit in RFC 8200): each router decrements it, and at zero returns an ICMP Time Exceeded message (type 11, RFC 792; ICMPv6 in RFC 4443). Probes start at TTL 1 and increase by one, and the tool records the source of each Time Exceeded. Windows tracert works the same way, stops at 30 hops by default, and prints * for a hop that does not answer. The list is the outbound path only: RFC 1393 notes the classical algorithm “does not trace the return path, which may differ from the outbound path”. A silent hop is not proof of a fault.

ipconfig / ip: the local configuration

These commands describe the local host, never the far end. On Windows ipconfig shows addresses, subnet mask and default gateway for all adapters; /all adds details such as DNS servers; /flushdns clears the resolver cache. On Linux ip address shows addresses and ip route the routing table. A wrong gateway or a missing address explains why the other tools here fail, but neither command says anything about a remote target.

ip -brief address
ip route show

nslookup / dig: DNS resolution

DNS maps names to records (RFC 1035; resolver and authoritative roles in RFC 8499). dig interrogates name servers and displays the answers returned by the server it queried; with no server argument it uses the servers in /etc/resolv.conf. Read the reply structure — the repeated question, the answer section, the header flags for recursion — as evidence about the resolver, not the target host. If the default resolver fails while the same query to another server with @server succeeds, the likely fault is the resolver or its reachability, not the name.

dig example.net A
dig +short example.net
dig @192.0.2.53 example.net MX

The common mistake: one probe as proof

Treating one successful ping as proof that “the network is fine”, or that a service is up, is the classic error. A reply proves that ICMP round-tripped once on one path. A web, database or mail service uses TCP or UDP on another port and can be filtered independently of ICMP, so reachable and serviceable are separate questions. Three rules follow: an unanswered ping does not prove a host is dead; a silent traceroute hop does not prove a fault; a DNS answer does not prove the host is reachable.

Security note

The aggressive options — flood mode, high-rate probes, TCP tracing and address sweeps — turn a diagnostic into a scan and can look like reconnaissance or a denial-of-service attempt. Use them only on networks you own or are authorised to test. A host or port that answers is an exposure, not by itself a vulnerability.

Level and prerequisites

L1 — fundamentals. No prerequisites beyond a rough idea of what an IP address and a host name are; no configuration experience is required.

Where to go next

References

  • RFC 792 — Internet Control Message Protocol (Echo, Time Exceeded).
  • RFC 791 — Internet Protocol (Time to Live).
  • RFC 8200 — IPv6 (Hop Limit).
  • RFC 4443 — ICMPv6 (Time Exceeded).
  • RFC 1393 — Traceroute Using an IP Option (outbound vs return path).
  • RFC 1035 — Domain names, implementation and specification.
  • RFC 8499 — DNS Terminology (resolver, recursive, authoritative).
  • RFC 5737 — IPv4 address blocks reserved for documentation.
  • iputils ping(8) and traceroute traceroute(8) manual pages.
  • iproute2 ip(8), ip-address(8), ip-route(8) manual pages.
  • ISC BIND 9 manpage for dig.
  • Microsoft Learn — ping, tracert, ipconfig, nslookup.