RFC 953

Hostname Server

πŸ“… published October 1985, from ietf

Hostname Server πŸŽ€

Okay bestie, look at this title block first! ✨ This is RFC 953, called Hostname Server, written by K. Harrenstien, M. Stahl, and E. Feinler, all from SRI. It's dated October 1985 πŸ“ and it obsoletes RFC 811. There's no Updates line on this one, so it doesn't list anything it updates.


STATUS OF THIS MEMO πŸ’…

Okay so this RFC is the official spec for the Hostname Server Protocol πŸ‘‘ This edition has minor revisions to RFC 811 that bring it up to date. Distribution of this memo is unlimited, so everyone can read it 🌈

INTRODUCTION πŸ¦‹

The NIC Internet Hostname Server is a TCP-based host information program and protocol, and it runs on the SRI-NIC machine ✨ It's one of a bunch of internet name services run by the DDN Network Information Center (NIC) at SRI International, on behalf of the Defense Communications Agency (DCA) 🫢

Its whole job is to hand out machine-readable name and address info about networks, gateways, hosts, and eventually domains, all within the internet environment πŸ’œ Right now it gives you the info described in the DoD Internet Host Table Specification [See RFC-952]. If you want the future plans, check out RFC-921 about the Domain Name System 🌸

PROTOCOL 🧚

To talk to this server from a program, open a TCP connection to port 101 (decimal) on the service host, SRI-NIC.ARPA (26.0.0.73 or 10.0.0.51) πŸŽ€ Send your information request as a single line, then read the response ✨ The server closes the connection once the response is done, so you only get one request per connection πŸ’€ Plan accordingly, bestie!

QUERY/RESPONSE FORMAT πŸ’–

Requests are simple text queries that look like this:

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

The square brackets ([]) 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:

<response key> : <rest of response>

The response key is a keyword that tells you what kind of response you got, and the rest of the response gets read in the context of that key πŸ¦‹

NOTE: Be careful figuring out what kind of reply you got (single record or multiple records), so you don't get confused about the state of the reply 😭 An "ALL" request will probably return several hundred or more records of every type, while "HNAME" or "HADDR" will usually give you one HOST record. Main character energy: know what you asked for! πŸ‘‘

COMMAND/RESPONSE KEYS 🌈

These are the command keywords defined right now ✨ NOTE: the server and its features will keep evolving, so use the HELP command to get the latest summary of implemented features, changes, and new commands πŸ’…

Keyword   Response

HELP      This information.

VERSION   "VERSION: <string>" where <string> will be different for
          each version of the host table.

HNAME <hostname>
          One or more matching host table entries.

HADDR <hostaddr>
          One or more matching host table entries.

ALL       The entire host table.

ALL-OLD   The entire host table without domain style names.

DOMAINS   The entire top-level domain table (domains only).

ALL-DOM   Both the entire domain table and the host table.

ALL-INGWAY
          All known gateways in TENEX/TOPS-20 INTERNET.GATEWAYS
          format.

Remember, the server only takes a single command line and returns a single response before it closes the connection πŸ™ˆ HNAME and HADDR are great for looking up one specific host by name or address πŸ“ VERSION is the move for automated processes: they can check whether a "new" version of the host table exists without downloading the whole thing 🧚 Heads up though, the version string is only guaranteed to be unique to each version, and nothing should currently be assumed about its format 🫠

Here are the 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
DOMAIN    entry found, rest of entry follows
BEGIN     followed by multiple entries
END       done with BEGIN block of entries

More keywords will show up as new needs get recognized ✨ Next up is a more detailed look at the allowed requests and responses πŸ’œ

QUERY/RESPONSE EXAMPLES πŸŽ€

Example 1: HNAME Query. Give it a name, and it finds the entry or entries that match. Like this:

HNAME SRI-NIC.ARPA <CRLF>

Here <CRLF> is a carriage return/line feed, and SRI-NIC.ARPA is a host name πŸ’– The likely response is:

HOST : 26.0.0.73, 10.0.0.51 : SRI-NIC.ARPA,SRI-NIC,NIC :
       DEC-2060 : TOPS20 : TCP/TELNET,TCP/SMTP,TCP/TIME,TCP/FTP,
       TCP/ECHO,ICMP :

A response can stretch across more than one line 🌸 Continuation lines always start with at least one space, so you'll know they belong to the same reply ✨

Example 2: HADDR Query. Give it an internet address (as specified in RFC 796), and it finds the entry or entries that match that address πŸ¦‹ For example:

HADDR 26.0.0.73 <CRLF>

Here <CRLF> is a carriage return/line feed, and 26.0.0.73 is a host address 🫢 The likely response is the same as the one for the HNAME request above πŸ’…

Example 3: ALL Query. This one delivers the entire internet host table in a machine-readable form 🌈

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-952, and then END: 🧚

ERROR HANDLING 😭

ERR Reply can show up on any query, and it should be permitted in any access program that uses the name server πŸ”₯ Errors look like this:

ERR : <code> : <string> :

For example:

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 that error, for the case where the program just logs the message πŸ’œ

Here are the current codes and what they mean:

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

REFERENCES πŸ¦‹

  1. Harrenstien, K., Stahl, M., and Feinler, E., "Official DoD Internet Host Table Specification," RFC-952, DDN Network Information Center, SRI International, October 1985.
  2. Pickens, J., Feinler, E., and Mathis, J., "The NIC Name Server," A Datagram-based Information Utility, RFC-756, Network Information Center, SRI International, July 1979.
  3. Postel, J., "Address Mappings," RFC-796, Information Sciences Institute, University of Southern California, Marina del Rey, September 1981.
  4. Postel, J., "Domain Name System Implementation Schedule", RFC-921, Information Sciences Institute, University of Southern California, Marina del Rey, October 1984.

That's the whole RFC, bestie! πŸŒˆπŸ’–βœ¨

πŸ“¦ where this page comes from