DNS & Network Debugging

Practical workflows for diagnosing DNS, connectivity, and latency problems.

DNS Lookups

dig (preferred tool)

# A record (IPv4)
dig example.com

# Specific record types
dig example.com AAAA      # IPv6
dig example.com MX        # Mail servers
dig example.com CNAME     # Canonical name
dig example.com TXT       # TXT records (SPF, DKIM, verification)
dig example.com NS        # Nameservers
dig example.com SOA       # Start of authority

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

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

# Trace the full resolution path (root -> TLD -> authoritative)
dig +trace example.com

# Reverse lookup (IP to hostname)
dig -x 93.184.216.34

# Show all records you can get
dig example.com ANY +noall +answer

# Batch lookup from file (one domain per line)
dig -f domains.txt +short

nslookup

nslookup example.com
nslookup example.com 8.8.8.8        # Use specific server
nslookup -type=MX example.com       # MX records
nslookup -type=TXT example.com      # TXT records

host (quick and simple)

host example.com
host -t MX example.com
host 93.184.216.34                   # Reverse lookup

Checking DNS Propagation

When you change DNS records, check multiple resolvers to see if the change has spread:

for dns in 8.8.8.8 1.1.1.1 208.67.222.222 9.9.9.9; do
  echo "--- $dns ---"
  dig @$dns example.com +short
done

Check the authoritative nameserver directly to confirm the record is correct at the source:

# Find authoritative NS
dig +short example.com NS
# Query it directly
dig @ns1.example.com example.com +short

Connectivity Testing

ping

ping example.com                     # Continuous (Ctrl+C to stop)
ping -c 5 example.com               # Send 5 packets
ping -c 5 -i 0.2 example.com       # 200ms interval between packets
ping -W 2 example.com               # 2-second timeout per packet (Linux)
ping -t 2 example.com               # 2-second timeout per packet (macOS)

What to look for: packet loss percentage and round-trip time variation. Consistent high latency is different from intermittent packet loss -- they point to different problems.

traceroute / tracepath

traceroute example.com               # Show each hop to destination
traceroute -n example.com            # Skip reverse DNS (faster)
traceroute -T -p 443 example.com    # TCP traceroute on port 443
traceroute -I example.com            # Use ICMP instead of UDP

Read the output hop by hop. A sudden jump in latency at a specific hop identifies where the slowdown is. Stars (

* * *

mtr (combines ping + traceroute)

mtr example.com                      # Interactive, live-updating
mtr -r -c 100 example.com           # Report mode, 100 cycles
mtr -rw -c 50 example.com           # Wide report (full hostnames)
mtr -T -P 443 example.com           # TCP mode on port 443

mtr is the best single tool for diagnosing path-level problems. The Loss% and Avg columns per hop tell you exactly where packets are being dropped or delayed.

curl Timing Breakdown

This is the go-to for diagnosing "the site is slow" complaints:

curl -o /dev/null -s -w "\
    DNS lookup:  %{time_namelookup}s\n\
   TCP connect:  %{time_connect}s\n\
   TLS handshake: %{time_appconnect}s\n\
  First byte:   %{time_starttransfer}s\n\
  Total time:   %{time_total}s\n\
  HTTP code:    %{http_code}\n" \
  https://example.com

How to read the output:

• time_namelookup high (>100ms): DNS is slow. Check resolver, try 8.8.8.8.
• time_connect - time_namelookup high: Network path to server is slow.
• time_appconnect - time_connect high: TLS negotiation is slow (cert chain issues, slow server).
• time_starttransfer - time_appconnect high: Server is slow to generate the response (backend problem).
• time_total - time_starttransfer high: Large response body or slow transfer rate.

curl verbose mode for HTTP debugging

# Full request/response headers and TLS details
curl -v https://example.com

# Even more detail (hex dump of traffic)
curl --trace - https://example.com

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

# Follow redirects and show each hop
curl -vL https://example.com 2>&1 | grep -E '< HTTP|< Location'

Port Testing

netcat (nc)

# Check if a port is open
nc -zv example.com 443
nc -zv example.com 80

# Scan a range of ports
nc -zv example.com 20-25

# With timeout
nc -zv -w 3 example.com 443

# Test UDP port
nc -zuv example.com 53

Checking listening ports on local machine

# ss (modern replacement for netstat)
ss -tlnp                             # TCP listening ports with process names
ss -ulnp                             # UDP listening ports
ss -tlnp | grep :8080               # Check specific port
ss -s                                 # Summary statistics

# netstat (older but universal)
netstat -tlnp                        # TCP listening (Linux)
netstat -an | grep LISTEN            # All listening (macOS)

# lsof
lsof -i :8080                       # What process is on port 8080
lsof -i -P -n | grep LISTEN         # All listening ports

tcpdump Basics

# Capture all traffic on an interface
sudo tcpdump -i eth0

# Filter by host
sudo tcpdump -i eth0 host example.com

# Filter by port
sudo tcpdump -i eth0 port 443
sudo tcpdump -i eth0 port 53        # DNS traffic

# Filter by protocol
sudo tcpdump -i eth0 tcp
sudo tcpdump -i eth0 udp and port 53

# Save to file for Wireshark analysis
sudo tcpdump -i eth0 -w capture.pcap port 443

# Read a capture file
sudo tcpdump -r capture.pcap

# Show packet contents in ASCII
sudo tcpdump -A -i eth0 port 80

# Limit capture to N packets
sudo tcpdump -c 100 -i eth0 port 443

# Common combo: DNS queries leaving this machine
sudo tcpdump -i any -n port 53

On macOS, use

en0

en1

eth0

tcpdump -D

Local Configuration Files

/etc/hosts

Static hostname-to-IP mappings. Checked before DNS.

# View current entries
cat /etc/hosts

# Add a temporary override (useful for testing before DNS changes)
echo "93.184.216.34 example.com" | sudo tee -a /etc/hosts

# Remove it when done
sudo sed -i '/example.com/d' /etc/hosts    # Linux
sudo sed -i '' '/example.com/d' /etc/hosts # macOS

/etc/resolv.conf

DNS resolver configuration.

cat /etc/resolv.conf

# Typical contents:
# nameserver 8.8.8.8
# nameserver 8.8.4.4
# search mycompany.internal

On systems using systemd-resolved, the actual config may be managed elsewhere. Check with

resolvectl status

On macOS, DNS is managed by the system. Check with

scutil --dns

Diagnostic Workflows

"The site is slow"

1. Run the curl timing breakdown to isolate which phase is slow.
2. If DNS is slow: check

   dig +short

   time, try alternate resolvers.
3. If connect is slow: run

   mtr -r -c 50

   to find where latency spikes.
4. If TLS is slow: check

   curl -v

   for cert chain issues or protocol negotiation problems.
5. If first-byte is slow: the problem is server-side. Check application logs and server resources.
6. If transfer is slow: check response size, consider compression, test bandwidth.

"I can't connect to the service"

1. Can you resolve the hostname?

   dig +short hostname

2. Can you reach the IP?

   ping -c 3 <ip>

3. Is the port open?

   nc -zv hostname port

4. Is something listening locally?

   ss -tlnp | grep :port

5. Is a firewall blocking?

   sudo iptables -L -n

   (Linux) or check security groups if cloud-hosted.
6. Is the route correct?

   traceroute -n hostname

"DNS isn't resolving"

1. Check what resolver you are using:

   cat /etc/resolv.conf

   or

   scutil --dns

   (macOS).
2. Query the resolver directly:

   dig @<resolver-ip> hostname

3. Query a known-good public resolver:

   dig @8.8.8.8 hostname

4. If public works but local does not: local resolver or network is the problem.
5. If neither works: check if the domain actually has records:

   dig +trace hostname

6. Check for /etc/hosts overrides that might be interfering.

"Works from my machine but not from the server"

1. Compare DNS results from both machines:

   dig +short hostname

2. Compare routes:

   mtr -r -c 20 hostname

   from both.
3. Check if the server has outbound firewall rules or proxy settings.
4. Check if the server uses a different resolver (corporate DNS, VPN split-tunnel).
5. Check environment variables:

   env | grep -i proxy

Quick Reference

dig +short example.com

dig -x 1.2.3.4

dig +short example.com MX

dig +trace example.com

nc -zv host 443

lsof -i :8080

ss -tlnp

mtr -r -c 50 host

sudo tcpdump -i any -n port 53

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} firstbyte:%{time_starttransfer} total:%{time_total}\n" URL