DNS and Networking Tools Every Developer Should Know

Terminal 2026-02-09 · 5 min read dns networking curl debugging http

DNS and Networking Tools Every Developer Should Know

DNS misconfiguration is behind a surprising number of production incidents. An API call that worked yesterday fails today because a DNS record changed, a certificate expired, or a CDN edge node is returning stale content. Knowing how to debug these issues quickly separates a productive developer from one who opens a support ticket and waits.

DNS Lookup Tools

dig

dig is the standard DNS lookup tool. It comes pre-installed on most Unix systems.

# Basic lookup
dig example.com

# Query specific record type
dig example.com MX
dig example.com TXT
dig example.com AAAA

# Query a specific DNS server
dig @8.8.8.8 example.com

# Short output (just the answer)
dig +short example.com A

# Trace the full resolution path
dig +trace example.com

# Check if a record has propagated
dig @1.1.1.1 +short example.com A    # Cloudflare
dig @8.8.8.8 +short example.com A    # Google
dig @9.9.9.9 +short example.com A    # Quad9

The +trace flag is the most useful: it follows the entire DNS resolution chain from root servers to the authoritative nameserver, showing exactly where a lookup breaks.

dog

dog is a modern replacement for dig with colored output and sensible defaults.

brew install dog

# Cleaner output than dig
dog example.com
dog example.com MX TXT A AAAA
dog example.com --type CNAME @1.1.1.1

dog's output is color-coded and easier to read at a glance. It queries all record types simultaneously when you specify multiple types.

nslookup vs dig

nslookup still works but dig is preferred — it shows more detail, supports all record types, and its output is more scriptable. Use dig.

HTTP Debugging

curl

curl is the Swiss Army knife of HTTP. Every developer should know its key flags.

# Basic request
curl https://api.example.com/users

# Show response headers
curl -I https://api.example.com/users

# Show request AND response headers (verbose)
curl -v https://api.example.com/users

# POST with JSON body
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer token123" \
  -d '{"name": "Alice", "email": "[email protected]"}'

# Follow redirects
curl -L https://example.com

# Show timing breakdown
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nFirst byte: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://api.example.com/health

# Save response to file and show HTTP status
curl -o response.json -w "%{http_code}" https://api.example.com/users

# Resolve a domain to a specific IP (bypass DNS)
curl --resolve api.example.com:443:1.2.3.4 https://api.example.com/health

The timing breakdown (-w flag) is invaluable for diagnosing slow API calls. If time_namelookup is high, it's a DNS issue. If time_connect is high, it's a network routing issue. If time_starttransfer is high, the server is slow.

The --resolve flag lets you test a specific server without changing DNS — perfect for verifying a deployment before switching traffic.

xh

xh is a modern HTTP client built in Rust, inspired by HTTPie but faster.

brew install xh

# GET request (default)
xh api.example.com/users

# POST with JSON (automatic content-type)
xh POST api.example.com/users name=Alice [email protected]

# Custom headers
xh api.example.com/users Authorization:"Bearer token123"

# Download a file
xh --download https://example.com/file.zip

xh formats JSON responses with syntax highlighting automatically. For API development and testing, it's more pleasant than curl.

Network Diagnostics

mtr

mtr combines ping and traceroute into a continuous display. It shows packet loss and latency at each hop between you and the destination.

brew install mtr

# Run mtr (requires root for raw sockets on some systems)
sudo mtr example.com

# Report mode (run 100 pings, then exit with summary)
mtr -r -c 100 example.com

# TCP mode (useful when ICMP is blocked)
mtr -T -P 443 example.com

mtr's real-time display shows where packet loss or latency spikes happen in the network path. If hop 5 shows 50% packet loss but the final destination doesn't, the intermediate router is deprioritizing ICMP (normal). If the final destination shows loss, there's a real problem.

ss (socket statistics)

ss shows network socket information. It replaced netstat.

# Show all listening TCP sockets with process info
ss -tlnp

# Show all established connections
ss -tnp

# Show sockets on a specific port
ss -tlnp sport = :3000

# Show TCP connection states
ss -s

When "port 3000 is already in use," ss -tlnp sport = :3000 tells you exactly which process is holding it.

tcpdump

tcpdump captures network packets. It's the command-line equivalent of Wireshark.

# Capture HTTP traffic on port 80
sudo tcpdump -i any port 80 -A

# Capture DNS traffic
sudo tcpdump -i any port 53

# Capture traffic to/from a specific host
sudo tcpdump -i any host api.example.com

# Save capture to file (for Wireshark)
sudo tcpdump -i any -w capture.pcap port 443

# Show only TCP SYN packets (connection attempts)
sudo tcpdump -i any 'tcp[tcpflags] & tcp-syn != 0'

For most debugging, the -A flag (show packet contents as ASCII) on a specific port is enough. For deeper analysis, save to a .pcap file and open in Wireshark.

TLS/SSL Debugging

openssl

openssl's s_client command is the standard way to debug TLS issues.

# Check certificate details
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -text

# Check certificate expiry
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Check the full certificate chain
openssl s_client -connect example.com:443 -showcerts

# Test specific TLS version
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3

# Check SNI (Server Name Indication)
openssl s_client -connect 1.2.3.4:443 -servername example.com

testssl.sh

testssl.sh is a comprehensive TLS testing tool that checks for protocol support, cipher suites, vulnerabilities, and certificate issues.

git clone --depth 1 https://github.com/drwetter/testssl.sh.git
./testssl.sh/testssl.sh https://example.com

It produces a detailed report covering everything from protocol versions to known vulnerabilities (Heartbleed, POODLE, etc.). Run it before deploying a new TLS configuration.

Local Network Tools

nmap

nmap scans networks and discovers hosts and services.

# Scan common ports on a host
nmap example.com

# Scan specific ports
nmap -p 80,443,8080 example.com

# Scan your local network
nmap -sn 192.168.1.0/24

# Service version detection
nmap -sV -p 1-1000 example.com

Wireshark

Wireshark provides deep packet inspection with a graphical interface. Use it when tcpdump's text output isn't enough — TLS handshake analysis, protocol-specific decoding, and filtering through large captures are where Wireshark shines.

brew install --cask wireshark

# Capture with tcpdump, analyze in Wireshark
sudo tcpdump -i any -w capture.pcap host api.example.com
# Then open capture.pcap in Wireshark

Practical Debugging Workflows

"My API call is timing out":

curl -v https://api.example.com/endpoint — see where it hangs
dig +short api.example.com — does DNS resolve?
mtr api.example.com — is there network packet loss?
curl --resolve api.example.com:443:$IP https://api.example.com/endpoint — bypass DNS

"SSL certificate error":

echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates — is it expired?
openssl s_client -connect example.com:443 -showcerts — is the chain complete?
curl -vI https://example.com 2>&1 | grep -i "ssl\|cert" — what does the client see?

"DNS changes aren't propagating":

dig @ns1.your-registrar.com example.com A — what does the authoritative nameserver say?
dig @1.1.1.1 example.com A and dig @8.8.8.8 example.com A — what do public resolvers see?
Check the TTL: dig example.com A — if TTL is 3600, wait up to an hour