Summary
- RFC 920 did more than name possible top-level domains. It attached each category to an administrator, a registrar and conditions for admission.
- ARPA was explicitly temporary; GOV, EDU, COM, MIL and ORG formed the organizational categories, while country codes and multiorganizations remained possibilities without established entries.
- The memo treated a top-level size of more than 500 hosts as a general expectation, but called the second-level guideline of more than 50 hosts very soft and allowed major organizations below it.
The first list was a policy instrument
The Internet’s early domain tree did not begin with an open shelf of labels waiting for anyone to claim one. In October 1984, RFC 920, by Jon Postel and Joyce Reynolds, described itself as an official policy statement of the Internet Activities Board and DARPA for establishing domains in the ARPA-Internet and DARPA research community. Its opening distinction is easy to miss: the document did not merely define what a domain name looked like. It also set out which kinds of domains could be established, who would administer them and how a request reached authorization.
The change followed an earlier plan. RFC 881 had described the domain-name plan; RFC 882 and RFC 883 set out concepts and implementation. RFC 920 says it refined the requirements and added a limited set of top-level domains. That makes it a policy companion to the technical system, not a protocol specification and not a universal statement of Internet governance.
The initial categories can be read as a compact table of expected administrators:
| Place in the initial set | Names or class | What RFC 920 said in 1984 |
|---|---|---|
| Temporary | ARPA | The existing ARPA-Internet hosts; explicitly temporary |
| Organizational categories | GOV, EDU, COM, ORG | DARPA was administrator; the NIC acted as agent |
| Military category | MIL | DDN-PMO was administrator; the NIC acted as agent |
| Countries | English two-letter ISO alpha-2 codes | No country domains had yet been established |
| Multiorganizations | No assigned label yet | None had been established; a qualifying international group could be considered |
This list was not a claim that each branch was already populated. RFC 920 says directly that country and multiorganization domains had not yet been established. Nor did the labels carry interchangeable authority. DARPA administered the organizational categories listed above; the Defense Data Network Program Management Office administered MIL. The Network Information Center served as agent and registrar. For top-level domains, authorization and registration were explicit steps, not implications of having a plausible name.
The size figures were also more nuanced than a simple gate. A top-level domain had to be specially authorized; in general, authorization was expected only for a domain with more than 500 hosts. A second-level domain had a guideline of more than 50 hosts, but RFC 920 called that a “very soft” requirement and said that a major university or corporation might qualify with only a few hosts. It also said that no group had to form a domain merely because it crossed a size threshold. The test was not headcount alone: a domain needed responsible administration, a reliable name service and registration with the appropriate upper-level authority.
The exception for a multiorganization shows why the first list was a classification problem, not just an inventory. A large international consortium that crossed the categories—and could not readily be placed under one of them—might qualify at the top level. RFC 920 offered a hypothetical example involving a consortium called CSNET. It described a community connected through mail exchange and several protocols, with one responsible administration. The point for this article is narrow: the policy left room for a group whose members did not fit one institutional category.
The memo also says no such top-level domain had yet been established, so the example is not evidence that CSNET received that status.
Below the top level, the same authority chain continued. A second-level domain registered with its top-level administrator; lower levels registered with the immediately higher administrator or that administrator’s responsible person. An upper-level authority had to be satisfied that the applicable requirements were met before granting authorization. A local administrator could pass some duties to a subdomain administrator, but the person responsible for the top-level domain remained accountable for the larger tree. The hierarchy therefore organized both names and responsibility for keeping them usable.
That responsibility had operational content. A named person had to coordinate domain questions, have enough technical expertise and authority to fix problems, and respond when a host misbehaved outside the domain. The memo called for reliable domain servers. Two independent machines on separate power supplies were one way to avoid a shared point of failure, while cooperation with another domain or third-party service was also possible. Those details matter because eligibility depended on the ability to administer the name space and the service behind it, not simply on the category printed after a dot.
ARPA carried the clearest time limit. RFC 920 says the top-level name arose from the system’s development history and should eventually disappear. It advised current ARPA-domain hosts to arrange to join another domain. DDN hosts that did not participate in the new naming service could continue using the NIC-maintained HOSTS.TXT file, although the memo also expected their names to change later. Those are plans and instructions in a 1984 policy document. They do not establish that every host migrated or that ARPA disappeared on a particular date.
A later document shows how the filing side evolved without changing what RFC 920 had said. RFC 1032, published in 1987 as a guide for domain administrators, describes the NIC’s registration and root-zone roles. It also says CSNET and UUCP managements acted as “domain filters”: they processed applications for their organizations and passed relevant information to the NIC. Its TLD snapshot includes NET and country domains, a later state that should not be projected backward into the initial 1984 list. The guide is evidence of a later administrative path, not proof that every 1984 expectation became operational exactly as written.
RFC 920’s first top-level list was therefore more than a set of familiar labels. It allocated categories, assigned administrators, reserved a narrow exception for groups that crossed them, and specified who could authorize a new branch. The list was small, but the admission chain was already consequential: a name at the top depended on classification, an accountable operator and an authority willing to register it.
Sources
- RFC 920 — Domain Requirements
- RFC 881 — The Domain Names Plan and Schedule
- RFC 882 — Domain Names: Concepts and Facilities
- RFC 883 — Domain Names: Implementation and Specification
- RFC 1032 — Domain Administrators Guide
These adjacent records were checked to bound the subject; their later status is not projected back into 1984.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance

