DNS, how names resolve into IP addresses.

DNS predates the modern web. Paul Mockapetris drafted it in 1983. RFC 882, RFC 883 for an internet that ran on modems. To achieve extreme speed, DNS was engineered to operate over UDP on port 53. There is no handshake: the client fires a query packet, the server fires an answer packet, and that's the entire exchange.

Every web page you load triggers dozens of DNS lookups. If each one required a TCP three-way handshake, browsing would crawl. UDP's fire-and-forget model is why it doesn't. If a packet is lost, the client simply times out and tries again.

There is no single "DNS server" that knows every domain. The system is a distributed inverted tree, designed to delegate authority downwards. When you query www.example.com., the system reads it from right to left, starting with the hidden trailing dot. The root.

If every webpage load required walking root → TLD → authoritative, the core of the internet would collapse under petabytes of traffic per second. DNS survives strictly through aggressive, multi-layered caching.

Every record carries a Time-to-Live in seconds — a contractual promise: this answer is valid for exactly X seconds; don't ask again until then. Caches exist at every layer of the lookup:

• Browser cache — Chrome has its own internal resolver cache, visible at chrome://net-internals/#dns.
• OS cache. systemd-resolved on Linux, mDNSResponder on macOS, DNS Client on Windows.
• Recursive resolver. 1.1.1.1, 8.8.8.8, or your ISP. Pools caching across millions of users; one person's miss becomes everyone else's hit.

When migrating a site to a new server, administrators lower the TTL (say, from 24 hours to 5 minutes) days in advance of the cutover. If they skip that step, resolvers everywhere will blindly route traffic to the dead IP for an entire day, ignoring the authoritative change. Caching, unmanaged, becomes inertia.

How does 8.8.8.8 answer a Tokyo user in 2 ms and a London user in 2 ms? The answer isn't DNS — it's BGP, the Border Gateway Protocol, quietly manipulating IP routing via a technique called Anycast.

Normal unicast routing assumes one IP points to one physical server. Anycast breaks that assumption: hundreds of servers globally announce the same IP address simultaneously. When your router tries to reach 8.8.8.8, BGP's shortest-path math steers your packets to the nearest datacenter announcing that prefix.

This is how the thirteen logical root servers scale to thousands of physical instances; it's how Cloudflare and Google serve DNS with single-digit-millisecond latency everywhere; it's how DDoS resilience works — attack traffic is naturally distributed across every PoP announcing the prefix, instead of concentrating on one box.

DNS was designed in 1983 over unencrypted UDP. A passive observer on your Wi-Fi network or a state-level ISP. Can see every domain you look up. An active attacker can inject forged responses and redirect you to a phishing server (cache poisoning or spoofing). Three retrofits close these gaps, each at a different layer. They layer on top of — not instead of — the HTTPS handshake that follows.

A DNS message — query and response use the exact same layout. Begins with a fixed 12-byte header. After the header come four variable-length sections: the question, the answer, the authority, and the additional. Most queries fit in a single UDP datagram; the entire design was optimized for "fits in one packet."

Most of the fields have single-letter names that sit on top of the protocol like debugging leftovers. QR flips 0/1 for query/response. AA is the authoritative answer bit. Only the nameserver that owns the zone sets it. TC indicates the response was truncated and the client should retry over TCP. RD begs the server to recurse; RA answers whether it did. RCODE is the DNS status code. NXDOMAIN means "no such name", which any browser user has learned to dread.

The four counts that follow tell the parser how many records live in each of the four sections. The authority section carries referrals (which servers know about this zone); the additional section carries helpful glue records (their IPs) to save a round trip. That is how the root server tells a resolver where to go next, inside a single UDP response.

This is what an authoritative operator, or the export of any major DNS host. Actually writes and ships. The syntax dates to BIND in the late 1980s and has scarcely changed. Every record you resolve anywhere on the internet is a line in a file like this.

Read top to bottom. $ORIGIN declares which zone these records belong to; unqualified names like www automatically get .example.com. appended. $TTL provides the default cache lifetime in seconds for any record that doesn’t state one.

The SOA record is always first. One per zone, never more. The serial number is the version. Every edit bumps it; secondary nameservers compare serials to know whether to pull a new copy. The four timers govern replication between primary and secondary authoritative servers. Nothing about end-user caching, which is controlled by each record’s TTL.

Then come the NS records (who is authoritative. Echoed by the parent zone), the A and AAAA for the apex, named hosts, a CNAME alias, mail exchangers with preference values, SPF and DMARC TXT records for email authentication, an SRV record for SIP service discovery, and a CAA record authorizing exactly one certificate authority to issue certificates for this domain see the HTTPS guide for why that matters.

Every entry in DNS is a resource record: a tuple of (name, type, class, TTL, rdata). The class is almost always IN (internet); the type defines what the rdata means. There are dozens of record types in IANA's registry; eleven do almost all the work.

Plain DNS has no integrity protection. Anyone on path can forge an answer; cache-poisoning attacks (Kaminsky, 2008) made this concrete. DNSSEC is the modern fix: every zone signs its records, and every parent attests to its child's signing key. The result is a verifiable chain from the root all the way down to the answer in your hand.

DNSSEC defines four record types that exist only to make the chain work. DNSKEY holds a public signing key. Usually a Key-Signing Key (KSK) plus one or more Zone-Signing Keys (ZSK). RRSIG is a signature over a record set, made with the ZSK. DS is a hash of the child zone's KSK, published in the parent zone. This is what lets the parent attest to the child's keys. NSEC / NSEC3 proves negative answers ("this name does not exist") without revealing the entire zone.

The trust anchor is the root zone's KSK. Shipped with every modern resolver. From there, DS records walk the chain down. If any link fails to verify, the resolver returns SERVFAIL rather than a possibly-forged answer.

Adoption is steady: most TLDs are signed (.com, .org, .uk, country TLDs); a smaller fraction of zones beneath are. Modern resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9) validate by default. Every signed zone you publish is one fewer place a Kaminsky-style poisoning attack can land.

Classic DNS rides on UDP port 53, in the clear. Anyone on the network can read every name you look up: your ISP, the coffee-shop Wi-Fi, a snooping middlebox. Three modern transports encrypt the channel without changing the message format underneath. Same questions, same answers, private wire.

All three encrypt the message, but they differ on visibility to the network. DoT uses port 853, which makes it trivial to identify and trivial to block. Many corporate networks do. DoH rides over port 443 looking exactly like web traffic, which makes it nearly impossible to block without blocking the web. DoQ uses port 853 over UDP/QUIC, getting QUIC's handshake savings while keeping DoT's separation from web traffic.

The trade-off is centralization. With classic DNS, your queries went to whoever the local network told them to. Usually your ISP, sometimes a corporate filter. With DoH, the browser typically picks one of a handful of DoH providers (Cloudflare, Google, Quad9). The query is private from the network, but visible to that provider. Pick a provider whose privacy policy you actually read.

Most production DNS bugs trace to one of three causes: stale caches (you changed a record, but the world is still serving the old one), broken delegation (the parent zone points at nameservers that don't actually serve the zone), or accidentally-public records (a private subdomain that points at a private IP, leaked through DNS). Three commands solve almost all of them.

Two more browser-grade tools deserve mention. nslookup ships with every OS and predates dig. Same purpose, dated UI. dog (modern Rust replacement for dig) and doggo add colourised output and JSON mode, useful in scripts.

For end-to-end visibility. What does the rest of the world see?. DNSViz (dnsviz.net) walks every level of delegation, validates DNSSEC, and renders a graph. intoDNS (intodns.com) does parent-vs-child consistency checks (the most common silent failure: nameservers in your zone don't match what the TLD says about you). Both are free, both are bookmarked by every working DNS operator.

Pick an answer for each. The right one reveals a short explanation; the wrong ones do too. There is no scoring. These are here so you can confirm the mental model travels with you when you go back to the editor.