Why DNS Replaced the Shared Hosts File
DNS was created because a single shared hosts file could not keep pace with a growing, geographically distributed network: every computer needed an up-to-date copy, and distributing changes reliably became impractical. The Domain Name System replaced that arrangement with a hierarchical, distributed service that lets computers look up names such as example.com without requiring one centrally maintained file on every machine.
How host files worked before DNS
Early computer networks needed a way to translate human-readable host names into network addresses. The Internet’s predecessor, ARPANET, initially used a centrally maintained file called HOSTS.TXT. It paired names with addresses, and network administrators could obtain the file and install a copy on their computers. This was a reasonable approach when the network had relatively few hosts and changes were manageable.
The file served the same basic purpose as a modern hosts file: a computer could consult a local list and find the address associated with a name. If an entry said that a particular host name corresponded to a particular address, a user or program could use the name instead of remembering the numeric address.
A hosts file still exists on many operating systems and can be useful for local overrides or testing. The problem was not that a text file could never resolve a name; it was that one shared, manually distributed file could not serve a rapidly expanding network well.
Why one shared file stopped scaling
As more computers joined the network, HOSTS.TXT grew and changed more often. Each participating machine needed a current copy, but the central file had to be updated and redistributed. That created a growing coordination burden and made it harder to ensure that different computers were using the same information.
- Distribution lag: After an address or host name changed, some computers could continue using older copies until they downloaded an updated file.
- Central bottleneck: A central source had to handle the publication and distribution of an increasingly large, frequently changing list.
- Name conflicts: Coordinating unique names across a growing network became harder when updates depended on centralized administration.
- Limited delegation: A single file did not offer a scalable way to let separate organizations manage their own portions of the name space independently.
These were related problems: growth made the file harder to maintain, and the maintenance process made growth harder to support. Simply making the file larger would not solve the need for timely updates, distributed responsibility, and reliable lookups.
DNS’s central idea: a distributed hierarchy
The Domain Name System was designed by Paul Mockapetris and introduced in 1983 through Internet standards documents. Rather than publish every name in one master file for every computer, DNS divides naming information into a hierarchy. The familiar name www.example.com, for instance, is read from right to left in terms of its hierarchy: the root, the top-level domain .com, then example, and finally the host label www.
Responsibility can be delegated at different levels. The operators responsible for a domain can maintain its records without editing a universal list of every Internet host. A DNS resolver can follow the hierarchy to find the server responsible for the requested information. This division allows the system to grow without asking every network operator to maintain every name.
DNS is distributed in both its administration and its data. There is no single server that must hold and answer for the complete set of names. The root and top-level domain infrastructure help direct queries, while authoritative name servers provide records for particular domains.
How a DNS lookup works
When a device needs the address for a domain, it usually asks a DNS resolver, often provided by a network operator or configured by the user. The resolver may already have a recent answer in its cache. If not, it queries the DNS hierarchy and obtains the relevant record from an authoritative server, then returns the answer to the device.
- A browser or other application requests the address for a name such as www.example.com.
- The device sends the lookup to a configured recursive resolver.
- If the resolver has no usable cached answer, it follows referrals through DNS servers toward the domain’s authoritative servers.
- The authoritative server returns the requested record, such as an IPv4 address record (A) or IPv6 address record (AAAA).
- The resolver returns the answer and may cache it for the period specified by the record’s time to live, or TTL.
Caching reduces repeated work and makes common lookups faster, but it also explains why a change may not appear everywhere immediately. Resolvers can retain an older answer until its TTL expires. DNS is primarily a system for naming and retrieving records; it does not itself carry the web page or guarantee that the destination server is available.
What DNS improved—and what it did not
DNS made it practical to distribute naming data and delegate its management. It also supports more than a simple name-to-address list. Records can identify mail servers, provide aliases, publish text information, and support other services. The result is a flexible naming database rather than a global replacement text file.
DNS did not eliminate all central coordination. The hierarchy still relies on coordinated root and top-level domain systems, and domain names must be unique within the relevant namespace. Nor does DNS mean every answer is instantly consistent everywhere. Caches, update practices, and network conditions affect when changes become visible.
A common misconception is that DNS was invented because computers could not read host files. Computers can read them; the issue was distributing and maintaining a complete, current file at Internet scale. Another misconception is that DNS always maps a name to one fixed address. A name may have multiple records or answers, and the answer can vary with configuration and network conditions.
Hosts files and DNS today
Modern computers generally use DNS for ordinary Internet names, while retaining a local hosts file that can take precedence for specific entries. This can be useful for development, testing, or deliberately mapping a name on one computer. It is not a practical way to publish a change for everyone: each relevant device would need its own edit, and an incorrect entry can prevent that device from reaching the intended host.
For a public domain, DNS records are managed through the domain’s DNS hosting service and authoritative name servers. A local hosts-file entry affects only the machine where it is configured; changing an authoritative DNS record can affect resolvers and users across the Internet, subject to caching and propagation timing.
Frequently Asked Questions
Why was DNS created?
It was created to replace the increasingly difficult process of maintaining and distributing one shared host-name file. DNS distributes responsibility through a hierarchy and lets resolvers retrieve information as needed.
What was HOSTS.TXT?
HOSTS.TXT was a centrally maintained list that associated host names with network addresses. Computers on the early network used local copies to look up names.
Does DNS store every website address in one place?
No. DNS data is distributed among authoritative servers, with responsibility delegated across the hierarchy. Resolvers query the relevant parts rather than downloading one complete global list.
Why can a DNS change take time to appear?
Resolvers may have cached the previous answer. The record’s TTL influences how long that answer can remain cached, and different resolvers may refresh at different times.
Is a hosts file still useful?
Yes, for a one-computer override or controlled testing. It is not a scalable substitute for DNS when a name must work consistently across many devices and networks.
Related
Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.