RFC 811

INTRODUCTION ✨

Okay bestie, title block tea ☕ This is RFC-811, called HOSTNAMES SERVER, dated 1 March 1982 🎀 It was written by Ken Harrenstien, Vic White and Elizabeth Feinler from the Network Information Center at SRI International. The header doesn't list a category, and it doesn't say what it obsoletes or updates, so nothing else to flag 💅

Anyway, the NIC Internet Hostnames Server is an NCP/TCP-based host information program and protocol running on the SRI-NIC machine 🖥️✨ It's one of a bunch of ARPANET/Internet name services that the Network Information Center (NIC) at SRI International keeps running for the Defense Communications Agency (DCA) 🧚 Its whole job is serving up machine-readable name and address info about networks, gateways, hosts and, eventually, domains inside the internet environment. As it's set up right now, the server gives you the info laid out in the DoD Internet Host Table Specification (RFC 810) 💜

QUERY/RESPONSE FORMAT 🦋

So the name server takes simple text queries that look like this, bestie:

<command key> <argument(s)> [<options>]

Square brackets ([]) just mean the field is optional 🌸 The command key is a keyword that tells the server what kind of request you're making, and the defined keys are explained below.

Responses look different, btw:

<response key> : <rest of response>

The response key is a keyword that tells you what kind of response it is, and the rest of the response gets read based on that key 👑

COMMAND/RESPONSE KEYS 🔑

Here's the full keyword lineup right now:

   Command Keys:

      HNAME   (find entry with given name)
      HADDR   (find entry with given address)
      ALL     (return entire host table)

   Response Keys:

      ERR     (entry not found, nature of error follows)
      NET     (entry found, rest of entry follows)
      GATEWAY (entry found, rest of entry follows)
      HOST    (entry found, rest of entry follows)
      BEGIN   (followed by multiple entries)
      END     (done with BEGIN block of entries)

More keywords will get added as new needs show up, so keep your eyes open 👀 A more detailed description of the allowed requests and responses comes later on too 🙈

PROTOCOL 💅

To access this server from a program, you connect to the service host (SRI-NIC) on:

   TCP: port 101 decimal
   NCP: socket 101 decimal for ICP

Then you send your information query and wait for the response 🫶

Note: You gotta be careful about figuring out what kind of reply you got (like a single record or multiple records) so you don't end up confused about the state of the reply 😭 An "ALL" request will likely return several hundred or more records of all types (see RFC 810). Meanwhile "HNAME" or "HADDR" will usually return one HOST record, or a "BEGIN:" list of host records followed by "END:" if there's more than one match. Main character energy when you read these correctly 💖

QUERY/RESPONSE EXAMPLES 🍓

1. HNAME Query. Give it a name and it finds the entry or entries that match. Here's how it looks:

   HNAME SRI-NIC <CRLF>   ;where <CRLF> is a carriage
return/
                           linefeed, and 'SRI-NIC' is a
host name

The likely response is:

   HOST : 10.0.0.73 : SRI-NIC,NIC : FOONLY-F3 : TENEX : NCP :

A response can stretch across more than one line, and continuation lines always begin with at least one space. For example:

HOST : 10.0.0.73 : SRI-NIC,NIC : FOONLY-F3 : TENEX : NCP :

2. HADDR Query. Give it an internet address (as specified in RFC 796) and it finds the entry or entries that match that address. Here's the vibe:

   HADDR 10.0.0.73 <CRLF>   ;where <CRLF> is a carriage
return/
                             linefeed, and '10.0.0.73' is a
host
                             address

The likely response is the same as the HNAME one:

   HOST : 10.0.0.73 : SRI-NIC,NIC : FOONLY-F3 : TENEX : NCP :

3. ALL Query. This one delivers the entire internet host table in a machine-readable form, and it's giving everything 🌈

   ALL <CRLF>   ;where <CRLF> is a carriage return/linefeed

The likely response is the keyword 'BEGIN' followed by a colon ':', then the entire internet host table in the format specified in RFC 810, then 'END:'. For example:

   BEGIN:
   NET : 10.0.0.0 : ARPANET :
   NET : 18.0.0.0 : LCSNET :
   GATEWAY : 10.0.0.77, 18.8.0.4 : MIT-GW :: MOS : IP/GW :
   HOST : 10.0.0.73 : SRI-NIC,NIC : TENEX : FOONLY-F3
      NCP/TELNET, NCP/FTP, TCP :
   HOST : 10.2.0.11 : SU-TIP, FELT-TIP ::
   END:

ERROR HANDLING 🚨

1. ERR Reply. This can happen on any query, and any access program using the name server should be able to handle it. Errors look like this:

   ERR : <code> : <string> :

as in:

   ERR : NAMNFD : Name not found :

The error code is a unique descriptor, limited to 8 characters for any given error. The access program can use it to identify the error and, in some cases, handle it automatically 🤖 The string is an accompanying message for when the access program just logs the error message. The current codes and what they mean are:

   NAMNFD        --     Name not found; name not in table
   ADRNFD        --     Address not found; address not in
   table
   ILLCOM        --     Illegal command; command key not
   recognized
   TMPSYS        --     Temporary system failure, try again
   later

REMARKS 🌸

The host name server described above runs over a single global internet host name/address database. This database is an extension of the old ARPANET Hosts.txt file, and the NIC keeps maintaining it so things stay continuous during the transition and expansion to the internet environment 🦋 The NIC sees central administration of a global host name database, along with this simple name server, as an interim solution on the way to a decentralized, distributed name/address translation service. Honestly that's such a visionary move 😭 The NIC welcomes your comments and suggestions for an expanded service. Send them to NIC@SRI-NIC 💌

REFERENCES 📚

1. Feinler, E., Harrenstien, K., Su, Z. and White, V. Official DoD Internet Host Table Specification, RFC 810, Network Information Center, SRI International, March 1, 1982.
2. Postel, J. Address Mappings, RFC 796, Information Sciences Inst., Univ. of Southern Calif., Marina Del Rey, Sept. 1981.
3. Pickens, J., Feinler, E., and Mathis, J. The NIC Name Server, A Datagram-based Information Utility, Network Information Center, SRI International, July 1979.