# The Pre-DNS Era

Canonical: https://learndns.org/learn/1-1-pre-dns-era/

> Before DNS existed, ARPANET relied on a single HOSTS.TXT file maintained by SRI-NIC — learn how this scaling crisis led to the Domain Name System.

In the beginning, there was no DNS. There was only **HOSTS.TXT**.

Every computer on the early internet — then called ARPANET — needed to know the network address of every other computer it wanted to communicate with. The solution was elegantly simple: a single text file containing every host name and its corresponding network address.

## The HOSTS.TXT File

The HOSTS.TXT file looked something like this:

```
# ARPANET Host Table
HOST : 10.0.0.73 : SRI-NIC,NIC,OFFICE-1 : DEC-2060 : NIC : TCP/FTP,TCP/SMTP,TCP/TELNET,TCP/FINGER,TCP/TIME ::
HOST : 10.0.0.51 : SRI-KL,KLNI : DEC-1090T : NIC : TCP/FTP,TCP/SMTP ::
HOST : 10.3.0.52 : MIT-MC,MC : DEC-KS10 : MIT : TCP/FTP,TCP/SMTP,TCP/TELNET ::
```

Each line mapped a host name (like `SRI-NIC`) to a network address (like `10.0.0.73`). Simple and effective — at least at first.

### How It Worked

1. The Stanford Research Institute's Network Information Center (**SRI-NIC**) maintained the master HOSTS.TXT file
2. System administrators would email changes to SRI-NIC
3. SRI-NIC staff would manually update the file (typically once or twice a week)
4. Every computer on the network would periodically download the updated file via FTP

This worked fine when ARPANET had dozens of hosts. But networks grow.

## The Scaling Crisis

By the early 1980s, the limitations of HOSTS.TXT were becoming critical:

### 1. Traffic Explosion

Every time HOSTS.TXT was updated, every host on the network would download the entire file. As the file grew from a few kilobytes to hundreds of kilobytes, this became a significant burden. The SRI-NIC server was struggling under the load.

### 2. Name Collisions

With more organizations joining the network, name collisions became a problem. Who gets to be `MAILHOST`? What happens when two companies both want `SERVER1`? There was no hierarchical structure — just a flat namespace where every name had to be globally unique.

### 3. Consistency Problems

Because the file was updated weekly and propagated via FTP, different hosts often had different versions of HOSTS.TXT. This meant a host might try to connect to an address that was out of date, or not know about a newly added host at all.

### 4. Manual Maintenance

Every change required human intervention at SRI-NIC. This created bottlenecks and delays. If you needed to add a new host or change an address, you might wait days or weeks for the change to propagate.

### 5. No Authority Delegation

SRI-NIC was a single point of control (and failure). There was no way to delegate naming authority to individual organizations. This made the system inherently unscalable.

## The Numbers Tell the Story

| Year | Hosts on ARPANET | HOSTS.TXT Size |
|------|------------------|----------------|
| 1973 | ~35 | ~1 KB |
| 1977 | ~111 | ~5 KB |
| 1981 | ~213 | ~15 KB |
| 1983 | ~562 | ~50 KB |

The growth was accelerating. And when TCP/IP was adopted as the standard protocol in 1983, connecting even more networks together, the situation became untenable.

## Voices of Concern

By 1982, the research community was actively discussing solutions. In RFC 799, David Mills wrote:

> "The current scheme of distributing the host table as a single file... is becoming increasingly unwieldy as the table grows. Furthermore, the delay between a change in host addresses and the update of the table throughout the network is a continuing source of problems."

The need for a new system was clear. What wasn't clear was what that system should look like.

## Key Takeaways

- **HOSTS.TXT** was the original naming system for ARPANET — a simple text file mapping names to addresses
- **SRI-NIC** maintained the master file and distributed updates via FTP
- The system had fundamental scaling problems: traffic, name collisions, consistency, and manual maintenance
- By 1983, with hundreds of hosts and growing, a new solution was desperately needed

## What Came Next

The solution would come from a researcher named Paul Mockapetris, working with Jon Postel at USC's Information Sciences Institute. Their creation — the Domain Name System — would solve the immediate scaling crisis while establishing a foundation that's still in use today.

In the next section, we'll explore how DNS was invented and the key design decisions that made it work.