dns-network

name	dns-network
description	Network debugging with DNS lookups, connectivity testing, and latency diagnosis. Use when user mentions "dns", "dig", "nslookup", "traceroute", "ping", "network debugging", "why is this slow", "connection timeout", "dns resolution", "curl timing", "network latency", "MTR", "netcat", or diagnosing network issues.

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 (* * *) mean that hop is filtering probes -- not necessarily a problem.

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 (Wi-Fi) or en1 instead of eth0. Run tcpdump -D to list available interfaces.

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

Task	Command
Resolve hostname	dig +short example.com
Reverse lookup	dig -x 1.2.3.4
Check MX records	dig +short example.com MX
Trace DNS path	dig +trace example.com
Test port open	nc -zv host 443
Find what is on a port	lsof -i :8080
Listening ports	ss -tlnp
Path analysis	mtr -r -c 50 host
Capture DNS traffic	sudo tcpdump -i any -n port 53
Full curl timing	curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} firstbyte:%{time_starttransfer} total:%{time_total}\n" URL