On-line hostnames service
Where to find a network computer's address by its name.
Kudlick, M.D. and E.J. Feinler, "On-line hostnames service", RFC 625, DOI 10.17487/RFC0625, March 1974, <https://www.rfc-editor.org/info/rfc625>.
@misc{rfc625,
series = {Request for Comments},
number = 625,
howpublished = {RFC 625},
publisher = {RFC Editor},
doi = {10.17487/RFC0625},
url = {https://www.rfc-editor.org/info/rfc625},
author = {M.D. Kudlick and E.J. Feinler},
title = {{On-line hostnames service}},
pagetotal = 1,
year = 1974,
month = mar,
} RFC text
Network Working Group Mike Kudlick (SRI-ARC)
RFC # 625 Jake Feinler (SRI-ARC)
NIC # 22152 March 7, 1974
ON LINE HOSTNAMES SERVICE
We agree with the suggestion in RFC 623 that more than one Host should
be responsible for maintaining a copy of the Hostnames data base. The
NIC is certainly willing to continue to maintain the master data base,
and make it available to any secondary Host that volunteers to maintain
a copy. We would be pleased to have UCSB serve as one of the secondary
Hosts.
However, we disagree with the suggestion in RFC 623 that a server
process should be implemented to give user processes access to the
official Hostnames file at the NIC. The file in question is a
sequential file and it seems to us that FTP is entirely appropriate for
this need. As far as setting up common login parameters among the
servers, this doesn't appear to be a major problem. Even with a
user/server process there would be a requirement for additional protocol
agreements, so it doesn't seem that much of an added burden to decide on
common login parameters when using FTP.
We are puzzled by the apparent distaste for FTP. In our opinion the
goal has been to set up a network file transfer mechanism that everyone
can use for a variety of needs without further programming required. If
FTP is that bad, shouldn't the criticism and work be directed towards
improving or replacing it, rather than making end runs around it? FTP
is surely more complex than is required for any particular application
including this one, but isn't that true by definition of a general
facility?
We also prefer to maintain the file in ASCII. It is easier, it seems to
us, to check out data or data transfer problems in that form rather than
in binary.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with ]
[ support from GTE, formerly BBN Corp. 10/99 ]
AI ELI5
On this page
§1Introduction
RFC 625 states that more than one computer should maintain a copy of the ARPANET's list of hostnames and their addresses. The Network Information Center (NIC) at Stanford Research Institute maintains the official list, and other sites like UCSB are encouraged to keep backup copies.
The main computer that lists everyone keeps the official copy, but other computers can make backups so you can find addresses from several places.
§2Accessing the Hostnames File
The RFC favors using FTP (File Transfer Protocol) to distribute the hostnames file rather than setting up a special server process. The hostnames file is a plain ASCII text file stored at the NIC with the path <NETINFO>HOSTS.TXT. Each site sets up the same login parameters to FTP and gets the latest copy whenever needed.
Instead of a fancy system, just let people copy the file with a simple file transfer tool that already works.
§3File Format and Updates
The hostnames file holds the computer's name, its numeric address, and status information. The NIC plans to add more details over time. The file stays as plain ASCII text for simplicity and easier troubleshooting. Sites are responsible for fetching updates from the NIC regularly, and changes will be added weekly.
The list is a simple text file with everyone's computer name and address. It changes every week, and sites copy the new version when they need it.