Load-Bearing Learning

Prefer to click through the interactive model?

DNS — study guide

The same fragments the interactive model serves, read in order. One source, two views.

Names for humans, addresses for machines

An IP address gets a packet to the right machine, but nobody wants to memorize one, and no machine wants to keep the same one forever. So the internet runs a lookup before almost everything else it does: DNS, the Domain Name System, turns the name you typed into the address the network actually needs. Visit a site, send an email, call an API — the first thing that happens is a DNS query.

What makes DNS interesting is that no single machine holds the directory. The answers are spread across a vast crowd of servers, each authoritative for its own little piece, and every answer gets copied into caches along the way so the same question rarely travels far twice. The design commitment is right there in the name: names are for humans, addresses are for machines, and DNS is the machinery that keeps the two honestly separated.

Understanding that machinery pays off quickly. It tells you what the records in a DNS dashboard actually do, why a change you just made is not visible everywhere yet, and how to point a domain you own at a host you rent — which is exactly the move that turns a personal site into something reachable at your own name.

Why names at all

the name — yours, stable example.com the address — infrastructure, churns 203.0.113.10 · first host 198.51.100.7 · new hosting 192.0.2.55 · current server old records, retired one record, re-pointed every move edits the record once — nobody who types the name notices
The name example.com stays the same for years while the address behind it changes; each move is one DNS record update, not a change to the name.

IP addresses already identify every reachable machine, so a naming layer on top has to earn its keep. It earns it with stability. An address belongs to infrastructure: move your site to a new server, switch hosting companies, or let a cloud platform shuffle its machines, and the address changes. A name belongs to you, and it can keep pointing at the right place through every one of those changes without anyone who types it noticing.

This is the same layering move that runs through all of networking: put a stable abstraction on top of a volatile detail, and let a translation mechanism absorb the churn. DNS is that mechanism for naming. The name example.com stays printed on business cards for a decade while the address behind it changes as often as the infrastructure needs to — and the only thing that has to be updated is one record in one place, not every bookmark, link, and configuration file that mentions the name.

The resolution walk

When a program needs an address, it does not go searching the internet itself. It asks the stub resolver — a small client built into the operating system — which checks the caches close to home first: the browser keeps its own, the operating system keeps another. On a miss, the stub resolver hands the question to its configured recursive resolver, often one run by your ISP or a public one like 1.1.1.1 or 8.8.8.8, and that resolver does the real legwork.

The legwork is a walk down a chain of referrals, like asking your way through a big organization: the front desk does not know the answer, but it always knows which department to send you to next, and each handoff gets you closer to the one person who actually does. The recursive resolver asks a root server, which does not know your answer but replies with a referral to the servers for the top-level domain, like com. The TLD servers do not know either; they refer the resolver to the nameservers responsible for the specific domain. Only that last stop — the authoritative nameserver — actually holds the record and answers the question. Each level knows one thing well: who to ask next.

The top of the chain is smaller and sturdier than it sounds. There are exactly thirteen named root server identities, A through M, run by twelve operator organizations — but each identity fronts many physical servers scattered worldwide through anycast routing, roughly two thousand instances in all as of mid-2026. The recursive resolver caches every answer it collects, so the full walk is the rare case, not the common one, and you can watch a real walk yourself with dig +trace.

Records — more than addresses

a query asks two things at once: which domain, and which record type example.com one name, six answers A 203.0.113.10 — the IPv4 address AAAA 2001:db8::10 — the IPv6 address CNAME an alias: go ask that name instead MX mail.example.com — where the email goes TXT free text — ownership, SPF/DKIM/DMARC NS ns1.dns-host.example — the nameservers
A domain owns typed records: a DNS query names both the domain and the record type, and each type answers a different question.

A domain does not map to a single value. It owns a small database of typed records, and every DNS query names both the domain and the type it wants. Asking for example.com is not a complete question until you say which record — the address? the mail server? the text notes?

The address records come in two flavors: A maps a name to an IPv4 address, and AAAA maps it to an IPv6 address; sites that speak both publish both. CNAME is different in kind — it maps a name not to an address but to another name, declaring this name is an alias, go ask about that one instead. Aliases are everywhere on subdomains like www, and they matter because the target can change its address without the alias needing to know.

The rest of the common set answers other questions entirely. MX names the mail servers that accept email for the domain — it is why mail to you@example.com knows where to go even though the website lives elsewhere. TXT holds free-form text, which in practice means ownership verification and the email-security policies called SPF, DKIM, and DMARC. And NS names the nameservers that are authoritative for the domain — the record that tells the rest of DNS who is allowed to answer for you. For a personal site you will mostly touch A, AAAA, and CNAME; the others are supporting cast, but you will meet every one of them in a real DNS dashboard.

Caching and the TTL

one record, TTL 300 seconds — three caches, three separate countdowns resolver cache fetched first — its 300s run out first 0 → re-ask OS cache same 300s, started later 0 → re-ask browser cache its own clock again 0 → re-ask time dot = when that layer fetched; bar = how long it may reuse the answer
Each cache layer — browser, operating system, recursive resolver — counts down its own TTL starting from the moment it fetched the record, and must re-ask when its own countdown reaches zero.

Every DNS record is published with a TTL — a time-to-live, in seconds, chosen by whoever owns the record. It is a promise with a deadline: any cache may reuse this answer without asking again, for at most this long, like a phone number jotted down with a use-by date: you can dial it instantly until the date passes, and after that you look it up again in case it changed. A cached record counts its TTL down, and when it hits zero the next query has to go fetch a fresh copy.

The counting happens in several places at once. The browser keeps its own cache, the operating system keeps a system-wide one, and the recursive resolver keeps a large cache shared by every client it serves — which is why a popular domain almost never triggers the full resolution walk: someone among the millions sharing your resolver asked recently, and the answer is still fresh. Each layer runs its own countdown, started at the moment it happened to fetch the record.

The TTL is the knob for a real tradeoff. A long TTL means fewer lookups and less traffic back to the authoritative servers; a short TTL means changes become visible quickly but every layer has to re-ask often. There is no correct value, only a choice about which side of that trade the record's owner wants — and knowing the knob exists is what makes DNS changes plannable instead of mysterious.

The propagation myth

you change the record no notification goes out — nothing is pushed resolver 1 old answer, cached expires → asks again → sees the new value resolver 2 expires later — this user waits longer resolver 3 worst case: cached seconds before time each dashed bar is one cache's old-TTL countdown; the wait is bounded by the TTL the record had when it was cached
Changing a record pushes nothing anywhere: each resolver keeps serving its cached old answer until its own TTL runs out, so different people see the change at different times, bounded by the old TTL.

Change a DNS record and someone will tell you to wait for it to propagate, as if the new value were spreading across the internet. It is not. Nothing is pushed anywhere: the authoritative nameserver never notifies anyone of a change — it simply answers with the current record whenever it happens to be asked. What you are actually waiting for is older cached copies, scattered across resolvers everywhere, to expire on their own schedules.

That is why a change appears at different times for different people. Each resolver cached the old answer at a different moment and is counting down its own TTL, so one user sees the new address minutes before another. The waiting time is bounded by the old record's TTL — the one that was on the record when caches last fetched it. If that TTL was 86400 seconds, a full day, a resolver that fetched just before your change may not ask again for a day, and shortening the TTL afterward does nothing for copies already cached.

The practical move follows directly: before a planned change, lower the TTL and wait out the old value, make the change while caches are expiring quickly, then raise the TTL again once the dust settles. One honest caveat — the TTL is an instruction, not an enforcement mechanism, and some resolvers ignore it and cache longer than asked. DNS changes reward patience precisely because no one is in charge of everyone's cache.

Who answers for a name

Owning a domain involves three distinct roles, usually sold as one bundle and worth prying apart. The registrar is where you buy and hold the rights to the name itself — it registers your domain with the registry and records your choice of nameservers. The DNS host runs the authoritative nameservers: the machines that actually hold your records and answer queries about them. The web host stores and serves the site. Three jobs, and they can be three different companies without anything breaking.

What stitches them together is NS delegation. At the registrar, you enter the nameservers for your domain, and that entry is what the TLD servers hand out as a referral — it is how the resolution walk knows where to end. Whoever those NS records point at speaks for your domain, full stop. Change the delegation and a different set of servers becomes the truth about your name, which is both the power move and the thing to double-check before touching it.

The practical payoff is knowing which hat a dashboard is wearing. Renewal and delegation live at the registrar; records live at the DNS host; files live at the web host. When a support article says change your DNS settings, the first question is which of the three you are actually logged into — most DNS confusion is just that question, unasked.

Pointing your domain at a host

subdomain — alias allowed www.example.com CNAME app.host.example A 203.0.113.7 the alias tracks every address change the host makes apex — alias forbidden example.com (apex) SOA NS the zone MUST hold these CNAME? a CNAME must be the ONLY record — it cannot coexist with SOA and NS apex answer: an A record — or the provider's ALIAS / CNAME-flattening, which serves a synthesized address record
A subdomain like www may be a CNAME alias, but the zone apex must carry SOA and NS records and a CNAME cannot coexist with any other record — so the bare domain takes an A record or a provider ALIAS instead.

The moment a personal site becomes real is the moment your own domain serves it, and that connection is just records. If your host gives you a fixed IP address, you point a name at it with an A record (and an AAAA for IPv6 if you have one). If your host gives you a hostname instead — common on cloud platforms whose addresses change without warning — you point a subdomain like www at it with a CNAME, and the alias quietly tracks every address change the host makes.

The bare domain is the one wrinkle. The apex — example.com with no subdomain — cannot hold a plain CNAME, because a CNAME is not allowed to coexist with any other records and the apex must carry the zone's own SOA and NS records. The standards-clean answer is an A record at the apex; the modern convenience is a provider feature — CNAME flattening, ALIAS, or ANAME, depending on who you ask — where the DNS host resolves the target itself and serves the result as a synthesized address record.

Do the switch like someone who has read about caching: lower the TTL on the records you are about to change, wait out the old value, flip the records to the new host, confirm it answers, then raise the TTL back. From there on, every resolver walking the chain ends at your records, your host, your site — reachable at a name you own.