Section 1.1.2 📖 ~6 min read

ARPANET Naming Conventions

How ARPANET's early internet pioneers chose host names, the informal naming conventions that emerged, and why these ad-hoc systems couldn't scale.

Before formal naming systems, ARPANET hosts got their names through an informal, almost whimsical process. Understanding these early conventions helps explain why DNS evolved the way it did.

The Wild West of Host Names

In the early days, there were no rules. Host names were chosen by system administrators with minimal coordination. This led to some interesting patterns.

Institutional Prefixes

Most hosts used a prefix identifying their organization:

  • MIT- for Massachusetts Institute of Technology (MIT-AI, MIT-MC, MIT-ML)
  • SRI- for Stanford Research Institute (SRI-NIC, SRI-KL, SRI-UNIX)
  • BBN- for Bolt Beranek and Newman (BBN-A, BBN-B, BBN-UNIX)
  • USC- for University of Southern California (USC-ISI, USC-ISIC)

This informal hierarchy foreshadowed the domain structure that would come with DNS.

Function-Based Names

Some hosts were named for their function:

  • NIC — Network Information Center
  • MAIL — Mail servers
  • TIME — Time servers
  • TELNET — Remote access points

Machine Type Suffixes

Hardware mattered in these days. Hosts often indicated their machine type:

SRI-KL      # A DEC KL-10 at SRI
UCLA-S      # A Sigma-7 at UCLA  
MIT-MC      # A "MacHack" PDP-10 at MIT
MIT-AI      # An AI Lab machine at MIT

The Emergence of Problems

These informal conventions seemed fine at first, but they created real issues as the network grew.

The “Who Gets What” Problem

Multiple organizations might want the same name:

  • Both UCLA and UCSD wanted UC-prefixed names
  • Multiple sites had mail servers — who gets MAIL?
  • Research projects spanning multiple institutions had no clear naming convention

The Nickname Explosion

HOSTS.TXT allowed multiple names (nicknames) for the same host:

HOST : 10.0.0.73 : SRI-NIC,NIC,OFFICE-1 : DEC-2060

Here, SRI-NIC, NIC, and OFFICE-1 all referred to the same machine. This flexibility was convenient but made the file larger and created confusion about canonical names.

Case and Character Chaos

There was no standard for:

  • Case sensitivity (Is SRI-NIC the same as sri-nic?)
  • Allowed characters (Can names include underscores? Numbers? Dots?)
  • Maximum length (How long can a name be?)

Different implementations handled these differently, causing interoperability problems.

Attempts at Order

As problems mounted, the community tried to establish conventions:

RFC 608 (1974): Host Names On-Line

This RFC proposed using “network name” prefixes:

“It would be nice to have an automated procedure for getting on-line host name information… The ARPANET Network Information Center will maintain a table of site-specific information including the official host name.”

RFC 810 (1982): DoD Internet Host Table Specification

By 1982, the Defense Department tried to formalize the format:

NET : 10.0.0.0 : ARPANET
GATEWAY : 10.3.0.72 : BBN-VAX,BBN-ARPANET-VAX : VAX-11/780 : BBN
HOST : 10.0.0.73 : SRI-NIC,NIC : DEC-2060

This standardized the file format but didn’t solve the fundamental scaling problems.

RFC 819 (1982): The Domain Naming Convention for Internet User Applications

This RFC, authored by Zaw-Sing Su and Jon Postel, was a pivotal document. It proposed the hierarchical naming structure that would become DNS:

“The internet community has grown to the point where the flat name space supported by HOSTS.TXT is a considerable burden… We propose a naming structure where names are sequences of domains separated by dots.”

This was the conceptual breakthrough. Instead of flat names like SRI-NIC, we would have hierarchical names like nic.sri.arpa.

The Last Days of HOSTS.TXT

By late 1983, the situation was critical:

  • The HOSTS.TXT file was being updated multiple times per week
  • Download traffic to SRI-NIC was consuming significant network bandwidth
  • Changes could take days to propagate fully
  • Name collision disputes were common
  • The network was about to grow dramatically with the TCP/IP transition

Something had to change. And it did.

Key Takeaways

  • Early ARPANET naming was informal and uncoordinated
  • Organizational prefixes (MIT-, SRI-) foreshadowed DNS domains
  • Problems included name collisions, nickname proliferation, and format inconsistencies
  • RFC 819 proposed hierarchical naming — the conceptual foundation of DNS
  • By 1983, the HOSTS.TXT system was clearly unsustainable

Next

In the next section, we’ll look at the political and technical factors that came together to create DNS, and meet the people who made it happen.