The Internet's Phone Book — The Understory

You type readunderstory.ink into your browser. You press enter. Half a second later, a page appears.

But hold on. The server you just talked to has no idea what “readunderstory.ink” means. No server does. Servers only understand numbers — IP addresses. Somewhere between your keyboard and that server, someone had to translate a human-friendly name into a machine-friendly number.

That translation is DNS. And until you understand it, every “the domain is down” or “the site isn’t loading” moment will feel like magic going wrong. Once you understand it, you’ll know exactly which layer to look at when things break — and you’ll be able to set up a domain without googling every step.

Why names exist at all

Imagine if every website required you to remember an IP address. Facebook would be 157.240.253.35. Google would be 142.250.190.78. YouTube would be another number, Instagram another, and by the time you memorised ten of them you’d have no brain space left for anything else.

Names exist because humans are bad at numbers. Computers are bad at names. DNS is the bridge.

DNS — Domain Name System: the distributed, hierarchical naming system that resolves human-readable domain names into IP addresses, with caches at every level to keep repeat lookups fast.

In plain terms: the phone book of the internet. You give it a name, it gives you back an address.

Computers need numeric addresses to route packets, but humans remember words. DNS sits between the two, making the web usable without memorising IP addresses.

You want to call Mama Nkechi, but you only know her name — not her number. You check your contacts, and there it is. DNS is the contacts app for every website on Earth.

Except a phone contact list is one app on one device. DNS is a distributed system — no single server holds every domain name. It’s a hierarchy of thousands of servers, each responsible for a slice of the whole.

The hierarchy of who knows what

DNS isn’t one giant list. It’s a tree. At the top sits the root, and beneath it branches out everything else.

When you type a domain name like readunderstory.ink, the name is read right to left:

readunderstory.ink
       ↑       ↑
       │       └── TLD (top-level domain)
       └────────── second-level domain

Every domain name is read backwards by DNS. The last piece is the most important — it tells the system which branch of the tree to look in first.

The tree has four layers worth knowing:

The root — the invisible . at the end of every domain. There are 13 root server clusters in the world, distributed globally.
TLD nameservers — one per top-level domain: .com, .org, .ink, .ng, .io. These are managed by different organisations (Verisign for .com, the Nigerian Internet Registration Association for .ng, etc.).
Authoritative nameservers — the ones that actually know the answer for a specific domain. If you own readunderstory.ink, you designate nameservers that hold its records.
Recursive resolvers — the helpers in the middle that do the asking for you.

Recursive resolver — A DNS server that receives a client’s query and performs the full sequence of lookups needed to return an answer, either from its cache or by querying other servers on the client’s behalf.

In plain terms: your designated asker. You ask it one question; it asks the whole chain on your behalf and comes back with one answer.

Clients don’t want to talk to five different servers to resolve one name. A recursive resolver does all the walking so the client only makes one request.

You need to know the price of tomatoes at four different markets. Instead of walking to each one, you call your cousin who already knows the answer. That’s a recursive resolver.

Except a cousin would get tired. A recursive resolver is designed to be asked the same question thousands of times per second — and it caches the answers so it doesn’t have to re-ask for every query.

The full journey of a lookup

Here’s what happens when you type readunderstory.ink and hit enter. If nothing is cached anywhere, this is the full path:

1. Browser cache. Your browser checks if it has recently resolved this name. If yes, done. If no, moves on.

2. Operating system cache. Your computer’s OS keeps its own cache. Also checks the hosts file on your machine — a leftover from the days before DNS (more on that in the backstory). If found, done. If not, moves on.

3. Router cache. Your home router has a DNS cache. Same deal.

4. ISP recursive resolver. Now the real work begins. Your ISP runs a recursive resolver, and this is where the walk through the hierarchy happens:

Step A: The resolver asks a root nameserver: “Where can I find .ink?”
Step B: The root replies: “I don’t know, but here’s the address of the .ink TLD nameserver. Ask them.”
Step C: The resolver asks the .ink TLD nameserver: “Where can I find readunderstory.ink?”
Step D: The TLD replies: “I don’t know, but here’s the address of the authoritative nameserver for that domain. Ask them.”
Step E: The resolver asks the authoritative nameserver: “What’s the IP for readunderstory.ink?”
Step F: The authoritative nameserver replies with the actual answer — something like 76.76.21.21.

5. The resolver returns the answer. Your browser gets the IP, and now it can open a TCP connection and send the HTTP request.

That’s the whole journey. Four asks, three cache misses, and the answer is finally there. All in under 200ms, usually under 50ms if things are cached.

Authoritative nameserver — A DNS server that holds the actual records for a domain and provides definitive answers about it. The final authority in a DNS lookup.

In plain terms: the one that actually knows. Not a helper, not a cache — the source of truth.

Every other DNS server in the chain is either asking on your behalf or caching. Only the authoritative server owns the record. When you change your DNS settings, you’re changing what the authoritative server reports.

The land registry office that holds the deed to a plot of land. Lawyers and agents can tell you about the land, but only the registry has the record that actually matters.

Except the land registry is one building. Most domains have multiple authoritative nameservers, often in different countries, serving the same records for redundancy. If one goes down, the others answer.

Records: what nameservers actually store

A DNS server doesn’t just hold “a name → an IP” pairs. It holds records — different kinds of data attached to a domain. There are dozens of record types, but you’ll meet the same six again and again.

DNS record — A single entry in a DNS server that maps a name to a value. Each record has a type that defines what kind of data it holds.

In plain terms: one line of information about a domain. Every domain has a small set of these.

DNS was designed before anyone knew what the web would become. Records let the same name carry mail routing info, service discovery data, domain ownership proofs, and more — all without a new protocol for each.

A contact card in your phone: name, phone, email, address, birthday. Each field is a different kind of data. A DNS record is one field on a domain’s contact card.

Except a phone contact is private. DNS records are public — anyone can look up any domain’s records. This is by design (the system couldn’t work otherwise), but it means you should never put secrets in DNS.

A record — the main one

The A record maps a domain name to an IPv4 address. This is the “here’s the IP” record. Most domains have at least one.

readunderstory.ink.  A  76.76.21.21

AAAA record — the IPv6 version

The AAAA record (pronounced “quad-A”) does the same thing but for IPv6 addresses. If a domain supports both IPv4 and IPv6, it has both an A and an AAAA record.

readunderstory.ink.  AAAA  2606:4700:3033::ac43:8c9b

CNAME record — the alias

A CNAME record says: “This name is an alias for that other name.” The system resolves the target name first, then returns whatever that resolves to.

www.readunderstory.ink.  CNAME  readunderstory.ink

This is how you make www.yourdomain.com and yourdomain.com point to the same place without duplicating IP addresses.

MX record — for email

MX records tell the internet where to deliver email for a domain. You can have several, each with a priority number.

readunderstory.ink.  MX  10  mail.example.com.
readunderstory.ink.  MX  20  backup.example.com.

The lower number wins. So mail.example.com gets tried first; if it fails, backup.example.com is tried.

TXT record — for verification and rules

TXT records hold arbitrary text. They’re used for:

Domain verification — Google, Stripe, and others ask you to add a TXT record to prove you own the domain.
Email security — SPF, DKIM, and DMARC all use TXT records to prevent spoofing.
Custom data — anything you want to expose.

readunderstory.ink.  TXT  "v=spf1 include:_spf.google.com ~all"

NS record — who’s in charge

NS records declare which nameservers are authoritative for the domain. When you buy a domain and configure it to use Cloudflare or Namecheap’s DNS, you’re setting NS records.

readunderstory.ink.  NS  ns1.cloudflare.com.
readunderstory.ink.  NS  ns2.cloudflare.com.

Change the NS records, and you’ve changed who answers for your domain. This is the highest-stakes DNS change you can make — get it wrong, and your whole site disappears until you fix it.

TTL: how long answers live

Every DNS record has a TTL — Time To Live. It says how many seconds a resolver is allowed to cache the answer before asking again.

readunderstory.ink.  3600  A  76.76.21.21
                     ↑
                     TTL in seconds (1 hour)

Short TTLs (like 60 seconds) mean changes propagate fast — but every lookup re-asks the authoritative server, adding latency.

Long TTLs (like 86400 seconds = 24 hours) mean every lookup is fast — but changes take a long time to reach everyone.

TTL — Time To Live: a value in a DNS record that specifies how many seconds the record may be cached by resolvers before they must re-query for a fresh copy.

In plain terms: an expiry date, in seconds, on every cached DNS answer.

Without TTLs, every resolver would either cache forever (and never see updates) or never cache at all (and hammer the authoritative servers with every request). TTLs make caching possible without making updates impossible.

Milk in your fridge. It’s good for a few days, then you throw it out and buy fresh.

Except you don’t control the fridge. You set the TTL on your record, but every resolver in the world decides how strictly to respect it. Some caches hold answers longer than the TTL says. This is why DNS changes never propagate perfectly — they propagate eventually.

DNS propagation — the phrase that shouldn’t exist

You’ll hear developers say “DNS is propagating.” Here’s what it means and why it’s a bit of a misnomer.

DNS propagation — The informal term for the period during which cached DNS answers expire and updated answers gradually reach all resolvers.

In plain terms: the waiting game after a DNS change. The change itself is instant; the world’s caches just haven’t caught up yet.

When you change a DNS record — say, pointing yourdomain.com to a new server — the change happens instantly on your authoritative nameserver. But every resolver in the world that previously cached the old answer will keep using it until its TTL expires.

So the change doesn’t “propagate” outward from your server. Resolvers just gradually forget the old answer and pick up the new one at different times, depending on when their caches were last refreshed.

Practical consequence: if you need a DNS change to take effect quickly, lower the TTL before making the change, wait for the old TTL to expire everywhere, then change the record. This is standard practice before migrations and launches.

The technical term for the “spreading” period isn’t propagation — it’s cache expiry. But you’ll hear “propagation” everywhere, so know both.

Backstory: from one file to a global system

Before DNS, there was a single text file. Literally.

HOSTS.TXT — The original pre-DNS hostname file: a single central text file, maintained by the Stanford Research Institute, that mapped every ARPANET hostname to its address. Its failure to scale is why DNS exists.

In plain terms: the internet’s one-and-only contact list, back when the internet was small enough for that to work.

Early 1970s. Every computer on the ARPANET had a file called HOSTS.TXT, maintained by the Stanford Research Institute. It listed every hostname and its IP address. Whenever a new computer joined the network, SRI updated the file, and sysadmins everywhere downloaded the new version.

You can see where this is going.

1982. The ARPANET had grown to a few hundred hosts, and HOSTS.TXT was becoming impossible to maintain. Additions happened constantly. Every change meant every computer had to download a new copy. Collisions between edits were common. The system was on the verge of collapsing under its own success.

1983. A researcher named Paul Mockapetris at USC’s Information Sciences Institute is asked to design a replacement. He invents DNS — a distributed system with no central file. Each domain would be managed by its own nameservers. The hierarchy would scale indefinitely.

Mockapetris publishes two RFCs — RFC 882 and RFC 883 — that define the entire system. They’re later replaced by RFC 1034 and RFC 1035 (still the foundational documents today). DNS goes live on the ARPANET in 1984.

1985. The first domain name is registered — symbolics.com. It still exists today. It’s the oldest registered domain on the internet.

1993. Network Solutions gets the contract to manage all .com, .net, and .org registrations. For a few years, they’re basically the only registrar. Domain registration is expensive and slow.

1998. ICANN is founded to take over DNS governance. The US Department of Commerce transfers oversight of the root to this new organisation. This is still one of the biggest political arguments in tech — who controls the root of DNS?

1999. The first major DNS attack hits. “DNS cache poisoning” becomes a real concern. DNSSEC is proposed as a solution — a way of cryptographically signing DNS records — but adoption is slow.

2008. A critical DNS flaw is discovered by Dan Kaminsky. He coordinates with major vendors for months before disclosing it, avoiding catastrophe. This is when DNS security starts being taken seriously across the industry.

2016. The Mirai botnet takes down Dyn, a major DNS provider. Twitter, Netflix, Reddit, Spotify, GitHub — all offline for hours. It’s the largest DDoS attack the internet has seen at that point. And it happened not by attacking the sites themselves, but by attacking the DNS provider they all relied on.

2020s. DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) become common, encrypting DNS queries so ISPs and networks can’t snoop on what domains you visit. Google, Cloudflare, and others offer public DNS resolvers with these protections.

The takeaway: DNS is one of the oldest parts of the internet, and one of the most quietly important. It’s held together by decades of patches and re-engineering. Almost nobody thinks about it — until it breaks, and then everything breaks.

Why you should care as a developer

DNS feels like “someone else’s problem” when you’re just building websites. But you’ll touch it constantly in real work:

Buying a domain — you’ll set up A records to point at your host.
Using Vercel, Netlify, or Render — they’ll ask you to add a CNAME or A record to connect your domain.
Verifying emails — Google Workspace, Resend, Mailgun all ask for TXT records.
Setting up email authentication — SPF, DKIM, DMARC all live in DNS.
Debugging “the site won’t load” — the first thing you check is DNS.
Migrating servers — you’ll lower TTLs ahead of time and switch records carefully.
Configuring subdomains — api.yourdomain.com, blog.yourdomain.com, admin.yourdomain.com — all DNS.
Deploying to multiple environments — staging.yourdomain.com, dev.yourdomain.com — all DNS.

You don’t need to be a DNS expert. But you need to not be afraid of it. And after today, you’re not.

What you’d say in the room

If an interviewer asks “what happens when a DNS lookup happens?” — here’s the answer:

The browser checks its own cache, then the OS cache and hosts file, then the router’s. On a miss, the query reaches a recursive resolver — usually the ISP’s — which walks the DNS hierarchy on the client’s behalf: root nameserver to find the TLD server, TLD server to find the domain’s authoritative nameserver, authoritative nameserver for the actual record. The answer comes back with a TTL, and every layer caches it for that long. The whole walk is usually under 200 milliseconds uncached, and repeated lookups are served from cache without touching the hierarchy at all.

If an interviewer asks “what’s the difference between an A record and a CNAME?” — here’s the answer:

An A record maps a name directly to an IPv4 address — the terminal answer. A CNAME maps a name to another name, deferring resolution to that target. You can’t put a CNAME at the zone apex where other records must coexist, and a CNAME adds one extra lookup — so use A records where the address is stable and known, CNAMEs where many names should follow one target.

Say it like a professional

The definitions from today, in one block. Say each out loud. If you stumble, go back.

DNS — Domain Name System: the distributed, hierarchical naming system that resolves human-readable domain names into IP addresses, with caches at every level to keep repeat lookups fast.
Domain name — A human-readable identifier for a location on the internet, structured as a hierarchy of labels separated by dots, registered through an accredited registrar.
Nameserver — A server that stores DNS records and answers queries about them.
Root nameserver — The top-level DNS servers that direct resolvers to the appropriate TLD nameservers.
TLD nameserver — DNS servers responsible for a top-level domain such as .com, .org, or .ng.
Authoritative nameserver — A DNS server that holds the actual records for a domain and provides definitive answers about it. The final authority in a DNS lookup.
Recursive resolver — A DNS server that receives a client’s query and performs the full sequence of lookups needed to return an answer, either from its cache or by querying other servers on the client’s behalf.
DNS record — A single entry in a DNS server that maps a name to a value. Each record has a type that defines what kind of data it holds.
A record — A DNS record that maps a domain name to an IPv4 address.
AAAA record — A DNS record that maps a domain name to an IPv6 address.
CNAME record — A DNS record that aliases one domain name to another.
MX record — A DNS record that specifies the mail servers responsible for accepting email on behalf of a domain.
TXT record — A DNS record that holds arbitrary text, commonly used for domain verification and email security policies.
NS record — A DNS record that declares which nameservers are authoritative for a domain.
TTL — Time To Live: a value in a DNS record that specifies how many seconds the record may be cached by resolvers before they must re-query for a fresh copy.
DNS propagation — The informal term for the period during which cached DNS answers expire and updated answers gradually reach all resolvers.
HOSTS.TXT — The original pre-DNS hostname file: a single central text file, maintained by the Stanford Research Institute, that mapped every ARPANET hostname to its address. Its failure to scale is why DNS exists.

Close the tab

Reproduce these from memory. Then reopen and check.

What does DNS do, and why does it exist?
Walk through the full journey of a DNS lookup from browser cache to authoritative nameserver.
What’s the difference between a recursive resolver and an authoritative nameserver?
Name six DNS record types and give the formal definition of each.
What does TTL mean, and how does it affect DNS changes?
Why do developers say “DNS is propagating” when they change a record? What’s actually happening?
What is HOSTS.TXT, and why was it replaced?
Who invented DNS, and when?
Why was the 2016 Dyn attack significant?
What is DNSSEC, and what problem does it solve?

If you can answer all ten without peeking, Day 7 is done.

If not, read those sections again. DNS is one of those topics that rewards a second pass — the first time you learn the pieces, the second time you see how they fit.

Tomorrow

You now know how readunderstory.ink becomes 76.76.21.21. But that’s only half the story. Once DNS hands back an IP, someone has to host the server that lives at that address. Someone has to run the machine, keep it cool, keep it online, pay the electricity bill.

That “someone” is your host. And the way hosting works — from shared hosting to VPS to PaaS to serverless — changes everything about how you build, deploy, and pay for websites.

Tomorrow, we meet domains, hosting, and what “the cloud” actually means. You’ll finally understand why Vercel is different from DigitalOcean, why some hosts charge ₦2,000 a month and others ₦2,000,000, and what “the cloud” really is once you strip away the marketing.