DNS records, IP addressing, subnetting, common protocols, and diagnostic tools. Use when configuring DNS records, debugging resolution or connectivity, planning subnets, analyzing HTTPS/TLS errors, or diagnosing latency and routing issues.
Networking problems resolve bottom-up: name, reachability, route, port,
application. Know which record type, which protocol, and which tool
answers each question, and most incidents collapse to a handful of
dig/ss/curl commands.
DNS maps names to addresses through a hierarchical chain: stub resolver, recursive resolver, root, TLD, authoritative server. The record types you need day-to-day:
TTL: time-to-live in seconds. Lower the TTL before a migration
(300s), raise it after (3600–86400s). Always check the current TTL
before making changes: dig +noall +answer example.com A.
CIDR notation: 192.168.1.0/24 means a 24-bit network prefix, leaving
8 bits for hosts (254 usable after subtracting network and broadcast).
Private ranges (RFC 1918):
10.0.0.0/8 — 16M addresses; large networks and cloud VPCs172.16.0.0/12 — 1M addresses; Docker default bridge range192.168.0.0/16 — 65K addresses; home and office networksQuick subnet math: /24 = 256, /25 = 128, /26 = 64, /27 = 32, /28 = 16 (subtract 2 for usable hosts).
TCP gives reliable ordered delivery with a 3-way handshake. UDP is connectionless and cheap — good when speed matters more than guaranteed delivery.
Handshake order: ClientHello (supported ciphers, SNI), ServerHello
(chosen cipher, certificate), key exchange, encrypted session. Common
failure modes are expired certs, hostname mismatch, missing
intermediate CA, and protocol version mismatch. Debug with
curl -vI https://example.com or
openssl s_client -connect example.com:443.
ss -tlnp # TCP listeners with process names
ss -ulnp # UDP listeners with process names
ss -tlnp sport = :443 # what is listening on 443?
Well-known ports: 0–1023 (root). Registered: 1024–49151. Ephemeral: 49152–65535.
# ufw (Ubuntu/Debian)
ufw allow 80/tcp
ufw allow from 10.0.0.0/8 to any port 5432
ufw status numbered
# iptables (direct)
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -j ACCEPT
iptables -L -n --line-numbers
Always allow SSH (port 22) before enabling a firewall. Test rules before persisting.
Health checks should verify application readiness, not just TCP connectivity.
When something does not work, go bottom-up:
dig example.com — does it resolve?ping -c 3 <ip> — is the host up?traceroute <ip> — where does the path break?curl -v telnet://<ip>:<port> — is the port open?curl -vI https://example.com — does the service
respond correctly?Agent-specific failure modes — provider-neutral pause-and-self-check items:
example.com, not www.example.com) conflicts with SOA and MX records and violates the DNS specification — many resolvers will silently drop one or the other. Use an ALIAS or ANAME record if your DNS provider supports it, or an A record pointing at a load balancer IP for the apex.dig example.com queries your default recursive resolver which may return a cached (and outdated) answer. Always compare dig @8.8.8.8 example.com (public cache) against dig @ns1.provider.com example.com (authoritative) to know what the actual current record is versus what is cached.* * * in a traceroute means the host is down. A hop that shows * * * means that router rate-limits or drops ICMP TTL-exceeded messages — it is not forwarding the probe, but it may still be forwarding actual application traffic. Only conclude the path is broken if * * * continues from that hop onward with no subsequent hops responding.ss -tlnp sport = :<port>) to confirm the service is bound before concluding the issue is network-related.openssl s_client -connect host:443 -showcerts to see the full chain, not just the end-entity certificate, so you know which certificate in the chain is the problem.; A and AAAA
example.com. 3600 IN A 93.184.216.34
example.com. 3600 IN AAAA 2606:2800:220:1:248:1893:25c8:1946
; CNAME
www.example.com. 3600 IN CNAME example.com.
; MX (lower priority tried first)
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.
; TXT (SPF, DKIM, verification)
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
selector._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGf..."
; SRV: _service._proto.name TTL IN SRV priority weight port target
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sip1.example.com.
; SOA
example.com. 86400 IN SOA ns1.provider.com. admin.example.com. (
2024010101 ; serial
3600 ; refresh
900 ; retry
604800 ; expire
300 ; negative cache TTL
)
; PTR (reverse DNS, lives in in-addr.arpa)
34.216.184.93.in-addr.arpa. 3600 IN PTR example.com.
PTR records must be set at your IP provider (hosting/cloud), not your domain registrar. CNAMEs cannot live at the zone apex — use ALIAS/ANAME if your provider supports it, or a plain A record.
| Property | TCP | UDP |
|---|---|---|
| Connection | 3-way handshake (SYN/ACK) | Connectionless |
| Reliability | Guaranteed, ordered | Best-effort, unordered |
| Flow control | Yes (window-based) | None |
| Overhead | Higher (20-byte header min) | Lower (8-byte header) |
| Use cases | HTTP, SSH, SMTP, databases | DNS, video, VoIP, gaming |
| Code | Meaning |
|---|---|
| 200 | OK |
| 201 | Created (POST/PUT) |
| 204 | No Content (DELETE) |
| 301 | Moved Permanently (cacheable) |
| 302 | Found (temporary redirect) |
| 304 | Not Modified (client cache valid) |
| 400 | Bad Request (malformed syntax) |
| 401 | Unauthorized (authentication required) |
| 403 | Forbidden (authenticated but not authorized) |
| 404 | Not Found |
| 429 | Too Many Requests (check Retry-After) |
| 500 | Internal Server Error |
| 502 | Bad Gateway (upstream invalid response) |
| 503 | Service Unavailable |
| 504 | Gateway Timeout (upstream did not respond) |
Common TLS problems and checks:
# Expiration and dates
openssl s_client -connect host:443 < /dev/null 2>/dev/null \
| openssl x509 -noout -dates
# Full chain (verify intermediates are sent)
openssl s_client -connect host:443 -showcerts < /dev/null
# Force a specific version
openssl s_client -connect host:443 -tls1_3
# SNI virtual-host workaround
curl --resolve host:443:IP https://host/
Enforce TLS 1.2+ minimum — 1.0/1.1 are obsolete.
dig recipesdig example.com # default A lookup
dig example.com AAAA # IPv6
dig example.com MX # mail servers
dig example.com TXT # SPF/DKIM/verification
dig @8.8.8.8 example.com # query a specific resolver
dig @ns1.provider.com example.com # query authoritative directly
dig +trace example.com # full resolution chain from root
dig +short example.com # terse answer
dig +noall +answer example.com # clean output with TTL
dig -x 93.184.216.34 # reverse DNS lookup
dig @ns1.example.com example.com AXFR # zone transfer (if permitted)
# traceroute / tracepath
traceroute example.com
traceroute -T -p 443 example.com # TCP trace (bypasses ICMP blocks)
traceroute -n example.com # skip DNS lookups
tracepath example.com # no root needed, discovers MTU
# mtr — live traceroute + packet loss stats
mtr example.com
mtr -rw -c 100 example.com # report mode: 100 pkts, wide output
mtr -T -P 443 example.com # TCP mode on port 443
# ping
ping -c 5 example.com
ping -c 5 -s 1472 example.com # test large packets (MTU issues)
Reading traceroute: * * * at a single hop often means that router
rate-limits ICMP and is not a real problem. * * * from a hop onward
with no recovery means traffic is being dropped there. Increasing
latency with distance is normal; sudden jumps indicate congestion.
curl debugging recipes# Connection debugging
curl -v https://example.com # DNS, TCP, TLS, headers
curl -vI https://example.com # verbose + HEAD only
curl -v --trace-time https://example.com # add timestamps
# DNS/routing control
curl --resolve example.com:443:93.184.216.34 https://example.com
curl -H "Host: example.com" http://10.0.0.5:80/
curl -4 https://example.com # force IPv4
curl -6 https://example.com # force IPv6
# TLS debugging
curl -vI https://example.com 2>&1 | grep -E 'SSL|TLS|subject|issuer|expire'
curl -k https://self-signed.example.com # skip verification
curl --cacert /path/ca.pem https://internal # custom CA
# Timing breakdown
curl -o /dev/null -s -w "\
DNS: %{time_namelookup}s\n\
Connect: %{time_connect}s\n\
TLS: %{time_appconnect}s\n\
First byte: %{time_starttransfer}s\n\
Total: %{time_total}s\n" https://example.com
# ss (modern netstat replacement)
ss -tlnp # TCP listeners with processes
ss -ulnp # UDP listeners
ss -tlnp sport = :443 # who owns port 443?
ss -tn state established # established TCP connections
ss -tn dst 10.0.0.5 # connections to a host
ss -s # summary statistics
# tcpdump (requires root)
sudo tcpdump -i any port 53 -n # DNS traffic
sudo tcpdump -i any host 10.0.0.5 -n # host traffic
sudo tcpdump -i any port 80 -A -n # HTTP, ASCII dump
sudo tcpdump -i any -w capture.pcap port 443 # save for Wireshark
sudo tcpdump -i any 'tcp[tcpflags] & (tcp-syn) != 0' # SYN packets
sudo tcpdump -i any 'tcp[tcpflags] & (tcp-rst) != 0' # RST packets
| Step | Question | Tool |
|---|---|---|
| 1 | Does the name resolve? | dig +short example.com |
| 2 | Is the host reachable? | ping -c 3 <ip> |
| 3 | What path do packets take? | mtr -rw -c 20 <ip> |
| 4 | Is the port open? | ss -tlnp sport = :PORT |
| 5 | Does the service respond? | curl -vI https://example.com |
| 6 | What is on the wire? | sudo tcpdump -i any port PORT |
DNS record not propagating after change. Compare authoritative answer vs cached answer; verify the change actually reached the authoritative server; then wait for the old TTL to expire:
dig @8.8.8.8 example.com A # public resolver (may be cached)
dig @ns1.provider.com example.com A # authoritative (should be new)
dig +trace example.com A # full resolution chain
Service unreachable on a specific port. Isolate DNS vs network vs