DNS Resolution

What you'll explore

1. 01

   Recursive Resolution: Nobody Knows the Whole Tree

   No single server holds the internet's names. A recursive resolver answers a client by walking the delegation tree top-down: ask a root server for the TLD's nameservers, ask the TLD for the zone's authoritative nameservers, ask the authoritative server for the record. That's three or more round trips of real network latency on a cold lookup — which is why the resolver caches aggressively and why the very first connection to a new domain is measurably slower than the ones that follow. On the client side the glibc stub resolver just fires one query at its configured resolver and waits; the recursion happens upstream. When 'the site is slow to start but fast once it loads', DNS resolution on the critical path is the first thing to rule out, not the last.

2. 02

   TTL: The One Number That Trades Latency for Freshness

   Every cached record carries a TTL, and that single number is a bet. A high TTL keeps DNS off the critical path (great for latency) but means a failover or IP change takes that long to propagate — clients keep dialing the dead address until the cache expires. A low TTL makes changes propagate fast but puts a lookup in front of more connections, adding round trips. TTL=0 is the extreme: the resolver serves the answer for the current lookup but caches nothing, so every request re-queries. Negative answers cache too (see NXDOMAIN, RFC 2308). Debugging starts at the resolver's own cache and the record's remaining TTL (dig shows it counting down), not at the application — a 'DNS change that hasn't taken effect' is almost always a TTL still ticking somewhere.

3. 03

   Record Types: Same Protocol, Very Different Answers

   One query mechanism carries many record types, and the type changes what you get back and how many lookups it takes. A/AAAA return addresses. CNAME is an alias: the resolver must then resolve the canonical name's address, so a CNAME chain across zones costs extra round trips (an in-zone target the authoritative server can bundle; a cross-zone one it can't). MX and NS return names that themselves need resolving. PTR walks the in-addr.arpa/ip6.arpa reverse tree. TXT carries free-form data (SPF, domain verification) and is a favorite for oversized responses. The stub resolver parses all of them the same way — pulling TYPE/CLASS/TTL/RDATA out of the wire response record by record — but the number of dependent lookups is a per-type property worth knowing when you're counting the cost of a page's first paint.

4. 04

   DNSSEC: Authenticates the Answer, Doesn't Hide It

   DNSSEC exists because plain DNS has no way to prove an answer wasn't forged (cache poisoning, on-path tampering). It signs records with a chain of trust: the root's key signs the TLD's key, which signs the zone's key (DS → DNSKEY), and each answer carries an RRSIG the resolver verifies back up to a trust anchor. If validation fails the resolver returns SERVFAIL rather than a possibly-forged answer — which is why a broken key rollover takes a whole zone dark. The crucial mental-model correction: DNSSEC provides authenticity and integrity, not confidentiality. The query and the signed answer still travel in plaintext; anyone on the path sees exactly what you looked up. Hiding that is a transport problem, not a DNSSEC one.

5. 05

   DNS-over-TLS: The Confidentiality DNSSEC Never Provided

   DNS-over-TLS (RFC 7858, TCP port 853) wraps the stub-to-resolver conversation in TLS, so the network path can no longer observe or modify the names you resolve. It is orthogonal to DNSSEC: DoT gives you confidentiality on that first hop, DNSSEC gives you end-to-end authenticity of the data — you can run either, both, or neither, and they answer different threats (a coffee-shop network snooping your lookups vs. a poisoned upstream answer). DoT (and its sibling DoH over HTTPS) also changes the operational picture: DNS now rides a connection-oriented, encrypted channel with its own handshake cost and its own harder-to-inspect traffic, which is a feature for privacy and a headache for the network team that used to filter or monitor DNS at port 53.