A Growing Network Kept Its Addresses in One File
In 1969, ARPANET began with four nodes connected by 50-kilobit-per-second lines running across the United States, a network small enough for its participants to picture as a handful of machines and a few long-distance links. Yet the map filled quickly. By 1971, fifteen nodes and twenty-three hosts connected major universities; the following year brought nodes in England and Norway, lifting the total to twenty-nine. By 1975, ARPANET had sixty-one nodes, according to an account published through the USPTO. Each new machine created a simple human problem: people needed a memorable way to identify it, while the network itself relied on numerical addresses.
That job fell to HOSTS.TXT, a shared text file that served as ARPANET's directory for roughly its first decade. The file paired host names with the numerical addresses of computers, giving users familiar names in place of lengthy 12-digit numeric strings. The Network Information Center at the Stanford Research Institute managed host registration and distributed the information required to keep the file current, the National Academies recounts. A line in the file could carry a machine's network address along with details such as its manufacturer, model, operating system, and supported protocols. In a small network, this was a practical arrangement: one directory, one current list, one place to ask for an addition.
The arrangement placed every change in the path of a central staff. A new host needed an entry, and the NIC had to process the request before the name could appear in the shared file; getting listed often took several days. Meanwhile, the directory used a flat name space, so every host name had to be unique across the whole network. The strain showed up in a famous failure: the NIC released a version of HOSTS.TXT that omitted the entry for the very system where the file was stored, according to the National Academies' history. The directory had become essential enough that an error in its own address could interrupt access to the directory itself.
As ARPANET grew rapidly, updates threatened to overwhelm the people responsible for maintaining the file. The issue was larger than a delayed request or an unlucky release. A swelling network was asking one office to maintain a single, globally unique list of names, and every additional machine added work to the same queue. That pressure drove technologists toward a new, distributed way to manage the mapping between names and addresses, as the National Academies describes, because the network had outgrown the shape of its original directory.
Paul Mockapetris Turned One Directory Into a Distributed System
That pressure drove technologists toward a new, distributed way to manage that mapping of names to addresses. At the University of Southern California’s Information Sciences Institute, Paul Mockapetris had the right place to work on it: he had joined ISI in 1978 as a graduate student from UC Irvine, and he worked in a group of about 20 people supervised by Jon Postel. Postel’s team already sat close to the practical machinery of the network, including the administration of Internet numbers, so the strain on a central directory arrived as an immediate engineering problem rather than an abstract concern. The task was to create a naming system that could keep pace with a network whose list of machines no longer fit comfortably in one shared file.
Mockapetris’s answer was the Domain Name System, created at ISI in 1983. DNS gave the network a simple bargain: people could use readable domain names, while computers could receive the numerical IP addresses required to locate services and devices. ISI describes DNS as the Internet’s directory, and the comparison captures the essential move. A person could ask for a name; the system could supply the number that made the connection possible. That separation made names usable for humans while preserving the precise addressing computers needed.
The larger change lay in where the information lived and who could maintain it. DNS was designed as a distributed naming system, with responsibility for assigning names and mapping them to Internet resources placed with authoritative name servers for individual domains. The system’s design delegated that responsibility, replacing the pressure of one master directory with a structure that could spread the work across the network. The idea carried an operational promise: as the network expanded, responsibility could expand with it.
Mockapetris put the design into a form others could build from through RFC 882 and RFC 883, the original DNS specifications published in November 1983. Those documents set out the early framework, while Ruth Brungardt and Steve Hotz supported the server work, with Hotz handling supporting utilities and test suites. The design then became a running system in 1984, when the first DNS server launched on the 11th floor of ISI. ISI’s account places that first server in the building where the work was underway. A fragile administrative bottleneck had become an architecture, ready for the network to place names under shared responsibility.
Delegation Gave the Internet Room to Grow
That running system needed a structure that could keep expanding without sending every new name through one desk. DNS supplied it through a hierarchy, arranging names within a domain-name hierarchy while the Internet maintained IP address spaces alongside it. Together, those two principal namespaces gave the network an orderly way to connect a name people could use with the address a machine could reach, within what the DNS reference documentation describes as a hierarchical and distributed naming service.
The key was delegation. A domain could have authoritative name servers, and those servers held responsibility for assigning names within that domain and mapping them to Internet resources. Responsibility could therefore move outward through the hierarchy, from a broad part of the namespace to the people managing a particular domain, while each domain still had a clear place to obtain an answer. The system could spread work across many operators and retain a source of authority for every slice of the naming tree. As one history of DNS puts it, delegation and authority became two of the system's central concepts.
That hierarchy became easier to picture through the early plan for top-level domains. Jon Postel and Joyce Reynolds set out the initial group in RFC 920: .com.net.org.edu.gov.mil, and .arpa. The same plan laid out country-related top-level domains based on two-letter ISO codes. These labels provided recognizable branches at the top of the tree, each capable of leading toward more specific names and their own responsible authorities.
Authority made the arrangement useful in practice. Delegation could pass responsibility down the hierarchy, and authoritative name servers could answer for the domain entrusted to them. A request for a name therefore had a path through an organized system of responsibility instead of a search through one universal directory. The result was a naming system designed to distribute both the work of administration and the confidence that a given answer came from the right place, a design captured in DNS's role of designating authoritative servers for each domain.
Once names had places in that hierarchy and authorities had responsibility for them, DNS had the framework for its everyday task: finding the numerical destination associated with a name.
The Lookup That Happens Between a URL and a Website
That everyday task begins the moment a person enters a familiar host name such as www.example.com. DNS translates that readable name into the numerical Internet Protocol address a device uses to locate the relevant service, a conversion that sits quietly inside an ordinary visit to a website. For this example, www.example.com resolves to 93.184.216.34 for IPv4 and 2606:2800:220:1:248:1893:25c8:1946 for IPv6. The first address has the shape most people recognize: IPv4 uses 32 bits, commonly written as four integers from 0 to 255 separated by dots, according to the National Academies. Behind the friendly name, then, sits a precise destination that the network can use.
That translation gives DNS its most visible role, yet the same system holds several kinds of information that keep Internet services connected. A records carry IPv4 addresses, while AAAA records carry IPv6 addresses. MX records identify SMTP mail exchangers, allowing a domain to direct email toward the appropriate destination. NS records identify name servers, extending the chain of responsibility established by delegation, and CNAME records provide aliases for domain names. DNS also stores PTR records for reverse lookups, which move from an address toward a name, along with SOA records that establish core information for a domain’s zone. These record types form the common working vocabulary of the DNS database, so the same lookup system can support web addresses, mail delivery, aliases, and administration.
Each record answers a narrowly defined question, and together they turn a domain name into usable instructions for software. A browser can begin with a name and reach an address; a mail system can begin with a domain and find its mail exchanger; an administrator can publish the information that identifies the servers responsible for a domain. DNS originally used the User Datagram Protocol as its transport over IP, reflecting the system’s focus on fast, repeated requests across a network of participating servers. The individual exchange feels nearly invisible because it is designed to serve a simple need: connect a name to the information required to reach a resource.
That simple need arrives at enormous volume. DNS handles up to 20 billion address-translation, or lookup, requests per day. Every one starts from the same basic advantage: people use words they can remember, while computers receive the numerical addresses they require. The architecture of hierarchy and authority now becomes a routine part of opening a page, sending a message, or connecting to a service, repeated at a scale that makes the Internet feel immediate.
BIND Helped DNS Leave the Lab
That routine depended on software that could carry the new system from an ISI server into the machines joining the network, and Berkeley Internet Name Domain, better known as BIND, became one of the crucial paths forward. In 1984, four UC Berkeley students, Douglas Terry, Mark Painter, David Riggle, and Songnian Zhou, wrote the first Unix name-server implementation for BIND, giving computers a practical package for participating in DNS. The early account of DNS places that work in the same year that the first DNS server came online, when the design still needed code that other institutions could actually run.
That code quickly became a shared project with a larger task: making a young standard dependable enough for everyday use. Kevin Dunlap of DEC substantially revised the DNS implementation in 1985, and the software gained the maturity needed for wider deployment. The following year brought a decisive sign of adoption, as operating systems and machines were being built to rely solely on DNS rather than the old host tables. ISI’s history of the system records that shift in 1986, when DNS had moved from a promising network design into an assumption built into new machines.
As the implementation spread, the written rules settled around it. RFC 1034 and RFC 1035 superseded the original DNS specifications in November 1987, providing the specifications that followed the initial RFC 882 and RFC 883 documents. The DNS chronology marks that replacement as a key point in the system’s development. BIND’s own stewardship continued to evolve as well: the university’s Computer Systems Research Group maintained it through version 4.8.3, while later versions passed through Digital Equipment Corporation and the work of Paul Vixie. A history of BIND’s releases traces those changes through the software’s early generations.
By 1994, the work had a more durable institutional home. Rick Adams, Paul Vixie, and Carl Malamud founded the Internet Systems Consortium, which would develop and maintain BIND from version 4.9.3 onward. That continuity led to BIND 8, the first production-ready version, released by Bob Halley and Paul Vixie in May 1997. The project’s record captures the significance of that release: DNS had acquired software built for production networks, and the system could keep spreading through the organizations that ran them.
The System Scaled by Sharing Control
With that base in place, the system’s lasting achievement came into focus: DNS could grow because control of naming could be shared. Each domain could place responsibility with its own authoritative name servers, the designated sources for assigning names and mapping them to Internet resources. The result was a system with many accountable operators, each handling a defined part of the larger namespace, instead of one directory office carrying every request and every update. The DNS design made that distribution a practical operating model as well as a technical one.
Some responsibility still belonged at the center of the expanding network. Jon Postel and the Information Sciences Institute continued to operate one of the growing root-server constellations, while also administering allocations of domains and Internet numbers. That work gave the distributed system a shared point of coordination: authority could sit close to the organizations responsible for individual domains, while the overall naming system retained a common structure. ISI’s account places Postel and the institute at that junction of technical operation and ongoing administration.
The people doing this work carried experience from the earlier directory era. Elizabeth Feinler and her team developed the concept of domains and managed the Host Naming Registry from 1972 to 1989, a span that bridged the old host-table system and the arrival of DNS. At the same time, Postel at USC’s Information Sciences Institute maintained the Assigned Numbers List, handling the numerical addresses that let machines identify one another. Their respective roles reveal the human work beneath the protocols: names, numbers, records, and requests all required someone to keep them coherent.
That experience also preserved a sharp operational lesson. The centralized HOSTS.TXT system had placed registration and distribution work with the Network Information Center at the Stanford Research Institute, and rapid growth brought a volume of updates that threatened to overwhelm the staff. New hosts could wait several days for an entry, while the flat namespace required every host name to remain unique. One release even omitted the entry for the system that stored HOSTS.TXT itself, an outage that exposed how much depended on a single shared file. The National Academies’ history records those pressures as the conditions that drove a distributed approach.
DNS absorbed that lesson by turning administration into a set of responsibilities that could be delegated and maintained across the network. The architecture gave local operators a role in managing their own domains, and it gave the wider Internet a way to keep those separate decisions legible to everyone else. As the network grew, that balance between shared rules and distributed control became the system’s defining strength.
Why the 1980s Design Still Sits Under the Internet
That balance between shared rules and distributed control became the reason DNS could keep growing with the network it served. The system now reaches a scale that would have been hard to picture from its early academic setting: DNS is used by billions of people, runs across millions of servers, and contains tens of billions of names. Each name gives a person a stable, readable place to begin, while the system carries the request toward the numerical address a computer needs.
That simple handoff remains DNS’s central service. A domain name gives people a way to ask for a website or other Internet resource in words they can remember; DNS translates that name into the IP address used to locate and identify the relevant service or device. ISI describes the result as the Internet’s directory, a description that captures why the system still feels so immediate in ordinary use. Every visit begins with a name, and the network can turn that name into a destination.
The durability comes from the fit between that everyday act and the system underneath it. DNS has been an essential component of Internet functionality since 1985, even as the Internet has expanded far beyond the environment in which its original specifications took shape. Its structure still lets names be managed through authoritative sources, and its records still provide the information needed for computers and services to find one another. The design has stayed useful because it gives a vast network a common way to ask a basic question: where does this name lead?
Software has carried that design forward as well. BIND, the Berkeley Internet Name Domain implementation that helped make DNS widely usable, has drawn work from more than 43 different core developers since 2000. That continuing work matters because DNS lives through both its rules and the systems that put those rules into practice across the network.
For the person entering a web address, the experience remains almost invisible: a familiar name opens a path to a faraway machine. Yet that ease rests on the arrangement established decades ago, where names, authority, and address lookup work together across a global system. The web feels navigable because DNS made that arrangement dependable enough to become part of the Internet’s basic fabric.
Comments (0)