The gap between a name and a number
By now you have climbed a long way. You know that every interface on the Internet is reached by an IP address like 192.168.1.10, that packets are routed across the world toward that number, and that an application reaches the network by opening a socket to an address and a port. There is just one human-shaped problem left, and it is the one you bump into every single day: nobody wants to type 142.250.72.14 to visit a website. People think in names — jovana.education, my-bank.com, a friend's email host — and the network thinks in numbers. Something has to translate between the two.
That translator is the Domain Name System, almost always called DNS, and the everyday analogy for it is exactly right: DNS is the Internet's phone book. You know a person's name; you look it up; you get back the number you actually dial. A domain name like jovana.education is the name a person remembers; the IP address it maps to is the number the network dials. DNS is the service that, given the first, hands you the second. That sounds almost too simple to need a whole rung — until you ask who keeps the phone book, and how it stays correct for billions of names across the whole planet.
Why bother with names at all, if the machine only wants the number? Because names give us something numbers cannot: a layer of indirection that humans control. A name is memorable and meaningful, where an address is an arbitrary string of digits. A name is stable: a company can move its website to an entirely different machine with a new IP address, and as long as the name keeps pointing at the new number, every link, bookmark, and business card still works. The name is the promise you make to people; the address is the implementation detail underneath, free to change.
Why not just one giant list?
The obvious first idea is the one the early Internet actually used: keep one master file that lists every name and its number, and copy it to every computer. In the 1970s, when the network was a few hundred machines, that worked — there was literally one file, called HOSTS.TXT, maintained at a single place and downloaded by everyone. But picture that approach today. A single list of every name on Earth would be enormous, it would be out of date the instant it was published, and one central office would have to approve every new name in the world. Everyone fetching the same file would also hammer that one source relentlessly.
So DNS makes three design choices that together let one phone book serve the whole planet, and the rest of this rung is really an unfolding of these three. First, the namespace is hierarchical, like a tree, so it can be split into pieces. Second, authority over those pieces is delegated, so no single office has to know or approve everything — the owner of each branch manages their own names. Third, answers are cached close to where they are needed, so the same question rarely has to travel all the way to the source twice. Hierarchy, delegation, caching: keep those three words in your pocket.
Reading a name from right to left
Look closely at a domain name and you can already see the tree hiding in it. A name like mail.jovana.education is read right to left, from the general down to the specific, exactly like a postal address read from country down to street. The rightmost label, education, is a top-level domain — one of the big branches near the top of the tree, alongside familiar ones like com, org, net, and country codes like uk or tw. To its left, jovana names a particular registered domain inside that branch. And mail to the left of that names one specific host the owner of jovana.education has chosen to define. Each dot is a step down the tree.
mail . jovana . education [ . ]
| | | |
a host a domain a TLD the root
(specific) (registered) (big branch) (the trunk)
read direction: <----------- general --------
more specific <----------------------------- more generalThere is even a label you almost never type but is always there: the root, an empty label after the final dot, the trunk that every name in the world hangs from. So mail.jovana.education is, in full, a path: root, then education, then jovana, then mail. Because the structure is a tree, the job of answering 'what number is this name?' can be divided cleanly: whoever owns the education branch handles names ending in education, whoever runs jovana.education handles names inside it, and nobody needs to know about anybody else's branch. That clean division is exactly what lets authority be delegated — the second of our three words.
Who actually asks the question for you
When your browser needs the number behind a name, it does not march off to question the world's servers itself. It hands the whole job to a helper called the resolver (often the stub resolver in your operating system, which in turn leans on a nearby recursive resolver run by your network or your ISP). You can think of the resolver as a diligent research assistant. You say 'find me the address for jovana.education,' and it goes away, asks whatever servers it must, follows whatever pointers it gets, and comes back with a single clean answer — or a polite 'no such name.' Your program asked one question and got one answer; all the running around happened on your behalf.
Here is a first taste of the chase your resolver runs, just enough to see the shape; the next guide traces it server by server. Notice how it walks down the very tree you just learned to read.
- Your program asks the resolver: 'What is the address for jovana.education?' and then simply waits for one answer.
- The resolver asks a root server, which does not know the address but knows who handles education, and replies 'go ask the education servers.'
- The resolver asks an education server, which does not know the address either but knows who runs jovana.education, and replies 'go ask jovana.education's servers.'
- The resolver asks jovana.education's own server — the one with real authority over the name — and this time gets the actual IP address.
- The resolver hands that address back to your program, which can now open a socket to it. The whole chase took a fraction of a second.
Two honest notes about this chase. The downward walk you just saw — resolver does all the legwork and returns one final answer — is the resolver doing recursive work on your behalf; the step-by-step 'go ask them' replies it collects from each server are the iterative style. The difference between recursive and iterative resolution, and exactly which party plays which role, is important enough that it gets its own treatment in guide three. For now, just hold the picture: one assistant, several hops down a tree, one answer back.
Caching: why the phone book is fast
If every name lookup truly ran that whole chase from the root, the root servers would be drowning and the web would feel sluggish. The third design choice rescues this: caching. When your resolver learns that jovana.education is at some address, it remembers the answer for a while. The next time anyone on your network asks for the same name — and popular names get asked constantly — the resolver answers instantly from memory without troubling a single server up the tree. It is the same instinct as jotting a friend's number inside your own phone instead of opening the phone book every time you call.
But a remembered answer can go stale — what if the owner moves the name to a new machine? So every DNS answer comes stamped with a TTL, a time-to-live: a number of seconds the answer may be trusted before it must be looked up fresh. A long TTL (say a day) means fewer lookups and faster responses, but slower to react when something changes. A short TTL (say a minute) means changes propagate quickly, at the cost of more lookups. That single dial — set by whoever owns the name — is the quiet knob that balances speed against freshness across the entire system, and it is what truly lets DNS scale. Caching and TTL get a full guide of their own later in this rung.
What a name actually returns, and what comes next
One last reframing before the rest of the rung fills in the machinery. A name does not map to just one kind of thing. The phone book entry for a name is really a small set of typed records — each a resource record — and the type tells you what question is being answered. Ask for the IPv4 address and you read an A record; ask for the IPv6 address and you read an AAAA record; ask where email for the domain should go and you read an MX record; an NS record names the servers that are authoritative for a zone, a CNAME makes one name an alias for another, and a TXT record holds free-form text often used for verification. Same name, different questions, different record types.
And one honesty you must carry forward from the very start: by default, DNS is neither authenticated nor encrypted. When a plain DNS answer comes back, your resolver normally has no way to prove it really came from the rightful owner of the name and was not forged or tampered with on the way, and anyone watching the network can see which names you are looking up. DNS was designed in a friendlier era for correctness and scale, not for security. Fixing both gaps — proving answers are genuine with DNSSEC, and hiding the questions with DNS over HTTPS or TLS — is real, important work, and it is exactly where this rung ends.
So here is the map of the rung you have just entered. You now hold the why: humans need stable, memorable names while machines need numbers, and DNS is the distributed phone book that bridges them through hierarchy, delegation, and caching. The guides ahead fill in the how — the structure of the namespace and its zones, the step-by-step resolution from root to authoritative server, the record types and the TTL that make caching safe, and finally the security and privacy that plain DNS lacks. Behind every name you will ever type sits this quiet, planet-spanning lookup. From here on, you are learning how it really works.