1. Why One Shared Sheet of Names Became a Problem
Imagine writing every student’s address on a single sheet of paper and handing it to the whole class. Every time someone moves, you must rewrite the paper and give it to everyone again. Before DNS, internet names were managed in a very similar way. The Network Information Center (NIC) kept a single file called HOSTS.TXT that listed the correspondence between hostnames (names given to computers) and their numbers [1].
This format was officially defined in October 1985 by RFC 952. The document states that this file was published on a NIC computer located at SRI International [2]. However, the "sheet of paper" is just a metaphor for comparison. The actual file was a simple list where each line contained a computer name and its number.
2. How More Computers Created Much More Traffic
If a class grows from 10 students to 100, how much work does it take to distribute the address sheet? The number of recipients increases by 10 times. So, the total effort becomes roughly 10 × 10, or 100 times greater. On a real network, this "effort" translates to the amount of data traffic used to distribute the file.
RFC 1034 lists three problems with this method. First, the traffic needed to distribute a new version to all hosts is proportional to the square of the number of hosts [1]. If the number of hosts increases 10 times, the traffic increases about 100 times. This is an estimate based on the distribution method, not a measured value. Second, adding a new name is not visible to the entire internet until the NIC updates the file. Third, the number of hosts was increasing rapidly [1].
Keeping everything in one place becomes difficult for both the holder and the distributors as the scale grows. So, what kind of design avoids using a single table?
3. How DNS Arranges Names in a Tree of Domains
The rightmost part of a site name, like ".com" or ".jp", is called a top-level domain. DNS uses these domains like branches on a tree. The name space is structured as a tree, with a nameless "root" at the top and top-level domains below it [1].
In March 1994, RFC 1591 listed the top-level domains as COM, EDU, NET, ORG, and INT. It also included GOV and MIL, which were limited to the United States. For country-specific domains, it specified using the two-letter country codes from ISO 3166 [4]. This was the list as of 1994; there are many more now.
The most important change is that the management of each domain is delegated to its own administrator [4]. Names for Japan or within a company can be left to their respective administrators. This means everyone no longer needs to wait for one central table to be updated. Even though names and management are separated, a question remains: how does a computer find the right number when you type a name?
4. How DNS Looks Up a Name from the Root Down
Imagine looking for a house in an unknown town. You first ask at the station for the direction of the town, then at the town office for the street, and finally ask a person on the street for the house. DNS name lookup works similarly.
A program called a full resolver, which looks up names on behalf of your computer, first asks a root server. The root server manages information about authoritative DNS servers for all top-level domains. It tells the resolver, "The person in charge of the right end of this name is here" [5].
Next, the resolver asks the authoritative server for that top-level domain. That server tells it about the authoritative server responsible for the specific domain. Finally, that server answers with the target IP address. This method of following the chain by asking for the next contact is called iterative query [5].
It is important to note that the root does not give the final number; it only points to the next contact. However, this is a basic description. In reality, you do not trace the full path every time because of a "remembering" system mentioned later.
5. Why the 13 Root Server Names Are Not 13 Machines
You may have heard that there are only 13 root servers in the world. However, 13 is the number of names, not the number of machines. There are 13 names for root servers, from "A" to "M", operated by 12 independent organizations. Behind each name, there are many locations (instances) around the world. According to root-servers.org, there were 2,045 operational locations (instances) as of September 30, 2026 [6]. This number changes daily.
Why 13? A common explanation is that when sending DNS messages via UDP, the size is limited to 512 bytes [3], and 13 is said to be the maximum number that fits in that response. However, RFC 1035 does not state this reason. It is a secondary explanation, so we do not state it as fact here.
By keeping the names to 13 but increasing the physical locations worldwide, users can get responses from nearby locations, and if one location stops, another can answer. But isn't it hard to trace the path from the root every time? Is there a way to avoid this?
6. How DNS Resolvers Save Answers for a Limited Time
If you visit the same house often, you might write down the directions once. Then, next time, you can go without asking anyone. DNS resolvers also save answers they have looked up once to avoid repeating the same query [1].
However, these notes need an expiration date, like a "best before" label. If a shop moves but you keep using an old note, you will go to the wrong place. So, DNS data includes a TTL (Time To Live), which shows how long the data can be cached. RFC 1035 defines TTL as a 32-bit signed integer. After this interval, the information should be checked with the source again [3].
In 1987, RFC 1034 recommended a TTL of about one day for ordinary hosts [1]. Current values vary by site, so this number is not a current standard. The weakness of the single-table method ("updates are slow") and the weakness of the distributed method ("asking every time is heavy") are balanced by this time-limited memory. This brings us back to the original question: sites open when you type names because trees, delegation, and caching support the system.
7. Activity: Find the Domain Parts of an Address Yourself
Today, you can look at the address of a favorite website and find the rightmost part, such as ".jp" or ".com". Next, write out your home address from the largest unit to the smallest. Addresses generally go from larger areas to smaller ones. But site names are small on the left and large on the right, which is the reverse of addresses. Reading from right to left as higher levels, with a nameless root beyond, helps you feel the tree shape.
If you want to learn more, JPRS has explanatory materials with diagrams in Japanese. You can look at their diagrams and write site names with ".jp" or ".com" on paper. Draw arrows to show which side is the larger division. This helps you understand the path from the root.