You type example.com — the browser asks the stub resolver built into the OS
Local caches miss, so the stub hands the question to its recursive resolver
The resolver's cache is cold too — it starts the walk at a root server
The root does not know the answer, only who to ask next: the com TLD servers
The resolver asks a com TLD server the same question
Another referral: the TLD hands out the NS delegation set at the registrar
The resolver asks the authoritative nameserver — the one that actually holds the record
The authoritative server answers with the A record; the resolver caches it for the TTL
The answer travels back up; the browser finally has an address to connect to
Ask again: the resolver answers straight from cache — no root, no TLD, no walk
The walk is the rare case; caches serve the rest — which is exactly why changes feel slow
The same ideas, as prose
These are the exact fragments the model serves — also available as an
ordered study guide.
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 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 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
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
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
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.