The early internet's host list was a text file you downloaded from SRI

The internet’s host directory once came with download instructions simple enough to put on a single page. Connect to SRI-NIC, log in anonymously, and fetch <NETINFO>HOSTS.TXT.

That procedure appears in RFC 810, dated March 1, 1982. The document names the file’s location and explains its text format. Hosts and gateways shared the table with information about operating systems and protocols.

Adding a name also involved an actual coordinating office. The specification says names and addresses had to be registered with the Network Information Center before use, and gives both an email address and a phone number. Your next hostname could require someone else’s attention before your traffic started flowing.

By November 1983’s RFC 882, Paul Mockapetris identified the scaling problem. The table’s size, and especially its update frequency, were “near the limit of manageability.”

The proposed domain system distributed the database and its upkeep, with caching to help lookups. Requiring everyone to collect a consistent copy of the whole directory would become increasingly expensive. Imagine mailing every contact in your address book a new address book whenever one person moved.

The contact information in the old specification makes the administrative cost visible. A new name had an owner, and somebody had to coordinate its place in the common directory. Copying the file solved distribution for a reader at a moment in time; it did not remove the next change from the coordinator’s desk.

That is the useful distinction for today’s supposedly simple shared files. A small inventory maintained by one person may work perfectly until enough independent teams need to change it. The file format can remain easy to parse while the human update queue becomes the limiting resource. Counting rows alone would miss the interruption rate.

Delegation changes who can maintain a part of the information. Caching changes how often a reader has to ask for it. Those are different decisions, and the original proposal puts both in view. A current troubleshooting session can ask the same two questions separately: who owns this answer, and who is serving the copy currently in use?

The next organizational equivalent of HOSTS.TXT may be hiding in a spreadsheet whose update requests keep arriving faster than its owner can process them. The useful measurement would be the age of those requests and the number of independent owners waiting to change their own entries.

The DNS Museum collects things people later persuaded this naming system to carry. Its original proposal already anticipated information beyond host addresses. The next clever use still has to decide who maintains the record, and how long everybody else keeps an old answer.