Computer Networking Cheatsheet
DNS
Use this Computer Networking reference while you build software engineering projects, review code, or refresh the syntax you reach for most.
Resolution path
DNS turns a name into an address by walking down the hierarchy. Nothing in the chain knows the whole answer.
browser cache → OS stub resolver → recursive resolver (ISP, 1.1.1.1) | | iterative queries v root servers (.) → "ask the .com TLD" TLD servers (.com) → "ask ns1.example.com" authoritative (example.com) → 93.184.216.34 (answer)
The recursive resolver does the walking and caches the result. The
authoritative server holds the zone file and answers with the aa flag set.
A stub resolver just asks its configured resolver and trusts the reply.
Record types
| Type | Holds | Example value |
|---|---|---|
A | IPv4 address | 93.184.216.34 |
AAAA | IPv6 address | 2606:2800:220:1:248:1893:25c8:1946 |
CNAME | alias to another name | www → lb.example.net. |
MX | mail exchanger plus priority | 10 mail.example.com. |
NS | authoritative nameservers for the zone | ns1.example.com. |
TXT | arbitrary text, SPF, DKIM, domain proofs | "v=spf1 include:_spf.google.com ~all" |
SOA | zone authority, serial, timers | see below |
PTR | reverse lookup, IP → name | 34.216.184.93.in-addr.arpa |
SRV | service host plus port and priority | _sip._tcp 10 60 5060 sip.example.com. |
CAA | which CAs may issue certs | 0 issue "letsencrypt.org" |
SVCB / HTTPS | endpoint hints, ALPN, ECH | 1 . alpn="h3,h2" |
DNSKEY / DS / RRSIG | DNSSEC keys and signatures | — |
ALIAS / ANAME | vendor CNAME-at-apex workaround | provider specific |
A CNAME cannot coexist with any other record at the same name, which is why
you cannot put one at the zone apex (example.com) where SOA and NS must live.
Providers solve it with ALIAS records or flattening.
Query and inspect with dig
dig example.com # A record, full answer sections dig +short example.com # just the answer values dig AAAA example.com +short dig MX example.com +short dig TXT _dmarc.example.com +short dig NS example.com +short dig SOA example.com dig -x 8.8.8.8 +short # reverse, PTR dig @1.1.1.1 example.com # ask a specific resolver dig @ns1.example.com example.com # bypass caches, ask authoritative dig +trace example.com # walk root → TLD → authoritative dig +norecurse @a.root-servers.net example.com dig +dnssec example.com # show RRSIG, check the ad flag dig example.com any # usually refused now, RFC 8482
Flags in the header tell you what happened:
| Flag | Meaning |
|---|---|
qr | this is a response |
aa | authoritative answer, straight from the zone |
rd | recursion desired, the client asked for it |
ra | recursion available on that server |
ad | authenticated data, DNSSEC validated |
| RCODE | Meaning |
|---|---|
NOERROR | success, though ANSWER may still be 0 records |
NXDOMAIN | the name does not exist at all |
SERVFAIL | resolver failed, often a DNSSEC validation failure |
REFUSED | the server will not answer you, ACL or wrong zone |
NODATA | name exists, no record of that type (NOERROR, 0 answers) |
NXDOMAIN and NOERROR with zero answers are different bugs. The first means
the name is wrong, the second usually means you asked for the wrong type.
TTL, caching, and zone timers
TTL is set by the zone owner in seconds and every cache along the way honors it.
dig shows the remaining TTL, so a value counting down means you hit a cache.
example.com. 3600 IN SOA ns1.example.com. admin.example.com. ( 2026091501 ; serial, bump on every change 7200 ; refresh, how often secondaries check 3600 ; retry, after a failed check 1209600 ; expire, secondaries stop answering after this 3600 ) ; minimum, negative-caching TTL for NXDOMAIN
Migration discipline: lower the TTL to 60-300 s at least one old-TTL period before you change a record, cut over, verify, then raise it back. Skipping that is why "DNS propagation" seems to take days. There is no propagation, only expiring caches.
Local resolver configuration
cat /etc/resolv.conf # nameserver, search, options resolvectl status # systemd-resolved, per-link resolvers resolvectl query example.com resolvectl flush-caches resolvectl dns eth0 1.1.1.1 1.0.0.1 getent hosts example.com # honors nsswitch, unlike dig nslookup example.com # portable, less detail than dig host example.com scutil --dns # macOS resolver config dscacheutil -flushcache # macOS, plus killall -HUP mDNSResponder
Two traps. /etc/hosts wins over DNS for getent and for applications, but
dig ignores it entirely, so a host that pings fine while dig disagrees is
almost always a hosts-file entry. And search domains append suffixes to short
names, which can turn db into db.corp.example.com and produce surprising
answers.
Security and privacy layers
| Mechanism | Protects | Port · transport |
|---|---|---|
| DNSSEC | integrity, proves the answer is the zone's | UDP/TCP 53, adds RRSIG · DS |
| DoT (DNS over TLS) | privacy from the network | TCP 853 |
| DoH (DNS over HTTPS) | privacy, blends with web traffic | TCP 443 |
| DoQ (DNS over QUIC) | privacy, lower latency | UDP 853 |
| DNS cookies | off-path spoofing | EDNS0 option |
DNSSEC signs, it does not encrypt, and DoH encrypts, it does not authenticate the zone. They solve different problems and are commonly deployed together.
Classic attacks to know: cache poisoning (inject a forged answer, mitigated by source-port randomization, 0x20 encoding, and DNSSEC), subdomain takeover (a dangling CNAME to a deprovisioned cloud host that an attacker can claim), and NXDOMAIN hijacking by resolvers that return ad pages instead of an honest error.
dig +dnssec example.com | grep -E 'flags:|RRSIG' delv example.com # validating resolver, states the chain kdig -d @1.1.1.1 +tls example.com # DoT probe, knot-dnsutils curl -sH 'accept: application/dns-json' \ 'https://cloudflare-dns.com/dns-query?name=example.com&type=A'