dns starters, one record per page
Twenty-five steps for developers who set one A record and stopped: what a record actually is with its five fields, labels and their limits, the four-stop lookup chain, A and AAAA addresses, CNAME aliases and the apex trap, MX preferences, TXT as a noticeboard, NS and SOA holding the zone, delegation and glue, PTR in the reverse tree, the trailing dot, the zone file's old plain-text grammar, TTL as a countdown and the trap it sets, the cache, dig and its short forms, reading a reply's header, port 53's two transports, and case that never matters, one record per page.
A diagram, the classic trap, and one thing to go try this week. That's a page.
dns starters, one record per page
Twenty-five steps for developers who set one A record and stopped: what a record actually is with its five fields, labels and their limits, the four-stop lookup chain, A and AAAA addresses, CNAME aliases and the apex trap, MX preferences, TXT as a noticeboard, NS and SOA holding the zone, delegation and glue, PTR in the reverse tree, the trailing dot, the zone file's old plain-text grammar, TTL as a countdown and the trap it sets, the cache, dig and its short forms, reading a reply's header, port 53's two transports, and case that never matters, one record per page.
Set in Space Grotesk, Inter and JetBrains Mono (SIL Open Font License).
DNS behaviour checked against RFC 1035 (rfc-editor.org), the Cloudflare learning centre DNS guides (cloudflare.com/learning/dns) and the BIND 9 Administrator Reference Manual dig man page (bind9.readthedocs.io), all fetched and read during this build. Record syntax, field limits, defaults and edge cases are named as those documents name them. Teaching conventions (one record a page) are named as conventions. This book quotes no verbatim passages and is an independent guide not affiliated with or endorsed by the IETF, Cloudflare or ISC.
General information only. Not professional advice; verify against your own resolver and the current documentation.
Your purchase is for personal use only. You do not have redistribution rights: please do not share, resell, or republish this book or its pages.
© 2026 Steve Hodgkiss. All rights reserved. Personal use only; no redistribution rights.
Edition 1.0 · stevehodgkiss.net
Contents
The model
What DNS even is: records as five fixed fields, names as labels with hard limits, and the four server kinds that walk a lookup from resolver to the authoritative answer.
- 01What a record is
- 02The lookup chain
Every DNS resource record has the same five top level fields: NAME, TYPE, CLASS, TTL and RDATA, per RFC 1035 section 3.2.1. The owner name says who the record is about, the type says what the data means, and TTL is a count of seconds the record may be cached.
What a record is
Let's say DNS feels like a mystery. It's one filing rule, repeated forever.
Every record is five fields: an owner name, a type, a class, a TTL and the data. The name says who it's about, the type says what the data means, and the TTL is how many seconds a cache may keep it. That's the whole grammar.
A record is a name, a type, and a value with a shelf life.
Take any hostname you own and picture its records as rows: name, type, value, TTL. You'll draw the same five columns all week.
Per Cloudflare's DNS server types guide, an uncached lookup walks four server kinds: a recursive resolver (the first stop, which caches), root nameservers (13 types, over 600 instances via anycast), TLD nameservers per extension such as .com, and the authoritative nameserver holding the domain's records.
The lookup chain
Let's say one server knows everything. None does, so they pass the question along.
Your device asks a recursive resolver, the first stop. With nothing cached it asks a root server, which points at the TLD servers for the extension, which point at the authoritative server for the domain. That one holds the records, and the answer climbs back down the chain.
Every hop is a pointer to the next better-informed server.
Trace one of your own domains this week: find its TLD and its authoritative nameservers with a lookup tool.
Per RFC 1035 section 3.4.1, the A record holds a 32 bit Internet address, written in master files as four decimal numbers separated by dots, and hosts with multiple addresses have multiple A records. Cloudflare's learning centre calls A the most fundamental record type: it holds a domain's IPv4 address.
The A record
Let's say you want the load-bearing record. It's this one.
An A record holds one 32 bit IPv4 address, four decimal numbers separated by dots. It's what a browser needs before anything else can happen: no A, no connection. The RFC spells the format, four dotted decimals, nothing more.
Everything else in the zone points here eventually.
Look up the A record for a domain you care about this week and note how many addresses come back.
Per RFC 1035, the TTL is how long a record may be cached before the source is again consulted, and Cloudflare's NS guide notes nameserver changes can take hours to replicate through DNS. A TTL left long before a migration means caches keep serving the old record until it expires.
The TTL trap
Let's say you moved the site and some users see the old one for hours. That's not a bug, that's the TTL.
You updated the record in seconds, but every cache holds the old value until its copy of the TTL expires. A 14400 second TTL means up to four hours of yesterday's address. The fix is order of operations: lower the TTL first, wait out the old one, then move.
The TTL you set last month is the speed limit on today's change.
Before your next DNS change, drop the affected TTLs a day ahead, then move, then raise them back.