DNS and Socket Tools — dig, ss

Past raw reachability, the questions get specific: is it DNS, is anything listening, and what process owns this connection? Three tools answer them. dig interrogates DNS precisely — which server, which record type, what TTL — without the indirection your application's resolver adds. ss (and the deprecated netstat it replaced) shows socket state: who is listening, who is connected, how many sockets are stuck in each state. lsof closes the loop by mapping a socket back to the process holding it.

These are the three questions you reach for the moment ping succeeds but the application still fails. A successful ping proves the IP is reachable; it says nothing about whether the name resolved to that IP, whether a process is bound to the port, or whether a firewall sits between the listener and the client. Most "the service is up but I can't connect" tickets are exactly one of those three, and these tools separate them in under a minute.

dig — Precise DNS Queries

dig queries DNS directly and lets you control every variable: which server with @server, which record type, and how much output. The +short form gives you just the answer; the full form shows the answer, authority, and additional sections plus the TTL, which is what tells you whether you are looking at a fresh record or a cached one about to expire. Crucially, dig bypasses your host's NSS stack, so it talks to DNS even when /etc/hosts would override the application.

# ask a specific resolver, see the TTL in the answer section
dig @1.1.1.1 api.example.com A +noall +answer
# api.example.com.  300  IN  A  93.184.216.34   (300s TTL)
# follow the delegation from the root down — bypasses caches
dig api.example.com +trace
# .            NS a.root-servers.net.
# com.         NS a.gtld-servers.net.
# example.com. NS ns1.example.com.    <- authoritative answer here

The +trace mode is the one that settles arguments. It walks the delegation from the root servers down to the authoritative nameserver, ignoring every cache on the way, so it shows you the real current record rather than whatever your resolver cached an hour ago. When the app sees one address and you "know" the record changed, +trace proves whether the change has actually propagated to authority or is still stuck behind a TTL somewhere.

ss and netstat — Socket State

ss reads socket state straight from the kernel and answers two questions fast: what is listening, and what connections exist in which state. ss -tlnp lists TCP listeners with their owning process; ss -tn state established shows live connections. The state column is where the diagnosis lives — a pile of sockets in one state usually names the bug.

# what is listening, on which address, owned by which pid
ss -tlnp
# State  Local Address:Port   Process
# LISTEN 0.0.0.0:443          users:(("nginx",pid=812))
# LISTEN 127.0.0.1:5432       users:(("postgres",pid=901))  <- localhost only!
# count connection states at a glance
ss -tan | awk '{print $1}' | sort | uniq -c
#   2 LISTEN
# 184 TIME-WAIT   <- normal churn from a busy client
# 137 CLOSE-WAIT  <- the app is not close()-ing sockets

Two state counts carry meaning. A large TIME-WAIT pile is normal on a busy client that opens many short connections — it is the kernel holding the socket for twice the maximum segment lifetime to absorb stray packets, and it clears itself. A growing CLOSE-WAIT pile is an application bug, not a network one: the peer closed, but your app never called close(), so the socket is stuck waiting on the app. Reading a CLOSE-WAIT pileup as a network fault sends you debugging the wrong machine entirely.

netstat answers the same questions but parses /proc the slow way and is deprecated on modern Linux; ss is the same questions with a faster, kernel-native answer. The only reason to reach for netstat is a host too old to ship ss.

lsof — Socket to Process

lsof maps a port or connection back to the exact process and file descriptor that owns it — the answer to "what is holding port 8080" or "which process opened this connection to the database." On a host where you already have the listener address from ss, lsof -i tells you the binary, its pid, and the user, which is everything you need to restart the right thing or find the leak.

# who owns the listener on 8080, and as which user
lsof -nP -iTCP:8080 -sTCP:LISTEN
# COMMAND   PID   USER   FD   TYPE  NODE NAME
# java     4471   app   77u  IPv4  TCP  *:8080 (LISTEN)

Port Not Listening versus Firewalled versus DNS Wrong

The payoff is telling three failures apart that all present as "can't connect." Port not listening: ss -tlnp on the server shows nothing bound to the port — the process is down or bound to 127.0.0.1 instead of 0.0.0.0, a one-character config bug that looks like a network outage. Listening but firewalled: ss shows the listener present and healthy, but a connect from the client times out — the listener is fine and a firewall in between is dropping the SYN.

DNS wrong: the name resolves to the wrong IP, so you are connecting to a host that was never going to answer — dig +short against the right address, and a getent hosts to see what the app actually resolves, separate this in one step. The diagnostic flow is mechanical: dig the name to confirm the IP, ss on the server to confirm the listener, then a client-side connect to test the path between — whichever step fails names the layer.

Is it DNS? Which server returns what record, with what TTL?→dig

Is anything actually listening on the port, in which socket state?→ss

What process owns this socket or port number?→lsof