RFC 953 HISTORIC NAMING · APPLICATIONS · HISTORIC

Hostname Server

A one-question-per-connection service for fetching the Internet host table over TCP.

On rfc-editor.org ↗
PUBLISHED
October 1985
AUTHORS
K. Harrenstien, M.K. Stahl, E.J. Feinler
STREAM
Legacy
BUILDS ON
RFC 811 — Hostnames Server
TCP PORT
101 (decimal)
SERVICE HOST
SRI-NIC.ARPA (26.0.0.73 or 10.0.0.51)
REQUESTS PER CONNECTION
One
ERROR CODE LENGTH
At most 8 characters
DOI
10.17487/RFC0953

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                               K. Harrenstien (SRI)
Request for Comments: 953                                 M. Stahl (SRI)
Obsoletes:  RFC 811                                     E. Feinler (SRI)
                                                            October 1985

                            HOSTNAME SERVER


STATUS OF THIS MEMO

   This RFC is the official specification of the Hostname Server
   Protocol.  This edition of the specification includes minor revisions
   to RFC 811 which brings it up to date.  Distribution of this memo is
   unlimited.

INTRODUCTION

   The NIC Internet Hostname Server is a TCP-based host information
   program and protocol running on the SRI-NIC machine.  It is one of a
   series of internet name services maintained by the DDN Network
   Information Center (NIC) at SRI International on behalf of the
   Defense Communications Agency (DCA).  The function of this particular
   server is to deliver machine-readable name/address information
   describing networks, gateways, hosts, and eventually domains, within
   the internet environment.  As currently implemented, the server
   provides the information outlined in the DoD Internet Host Table
   Specification [See RFC-952].  For a discussion of future developments
   see also RFC-921 concerning the Domain Name System.

PROTOCOL

   To access this server from a program, establish a TCP connection to
   port 101 (decimal) at the service host, SRI-NIC.ARPA (26.0.0.73 or
   10.0.0.51).  Send the information request (a single line), and read
   the resulting response.  The connection is closed by the server upon
   completion of the response, so only one request can be made for each
   connection.

QUERY/RESPONSE FORMAT

   The name server accepts simple text query requests of the form

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

   where square brackets ("[]") indicate an optional field.  The command
   key is a keyword indicating the nature of the request.  The defined
   keys are explained below.

   The response, on the other hand, is of the form

      <response key> : <rest of response>

Hostname Server


   where <response key> is a keyword indicating the nature of the
   response, and the rest of the response is interpreted in the context
   of the key.

   NOTE:  Care should be taken to interpret the nature of the reply
   (e.g, single record or multiple record), so that no confusion about
   the state of the reply results.  An "ALL" request will likely return
   several hundred or more records of all types, whereas "HNAME" or
   "HADDR" will usually return one HOST record.

COMMAND/RESPONSE KEYS

   The currently defined command keywords are listed below.  NOTE:
   Because the server and the features available will evolve with time,
   the HELP command should be used to obtain the most recent summary of
   implemented features, changes, or 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 that the server accepts only a single command line and
   returns only a single response before closing the connection.  HNAME
   and HADDR are useful for looking up a specific host by name or
   address; VERSION can be used by automated processes to see whether a
   "new" version of the host table exists without having to transfer the

Hostname Server


   whole table.  Note, however, that the returned version string is only
   guaranteed to be unique to each version, and nothing should currently
   be assumed about its format.

   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 be added as new needs are recognized.  A more
   detailed description of the allowed requests/responses follows.

QUERY/RESPONSE EXAMPLES

   1. HNAME Query - Given a name, find the entry or entries that match
   the name.  For example:

      HNAME SRI-NIC.ARPA <CRLF>

         where <CRLF> is a carriage return/ linefeed, 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 may stretch across more than one line.  Continuation
      lines always begin with at least one space.

   2. HADDR Query - Given an internet address (as specified in RFC 796)
   find the entry or entries that match that address. For example:

      HADDR 26.0.0.73 <CRLF>

         where <CRLF> is a carriage return/ linefeed, and '26.0.0.73' is
         a host address.

      The likely response is the same as for the previous HNAME request.

Hostname Server


   3. ALL Query - Deliver the entire internet host table in a
   machine-readable form.  For example:

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

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

ERROR HANDLING

   ERR Reply - may occur on any query, and should be permitted in any
   access program using the name server.  Errors are of the form

      ERR : <code> : <string> :
        as in
      ERR : NAMNFD : Name not found :

   The error code is a unique descriptor, limited to 8 characters in
   length for any given error.  It may be used by the access program to
   identify the error and, in some cases, to handle it automatically.
   The string is an accompanying message for a given error for that case
   where the access program simply logs the error message.  Current
   codes and their associated interpretations 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

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.

Hostname Server

AI ELI5

On this page
PROBLEMPrograms on the early Internet needed a machine-readable way to get name and address information about networks, gateways and hosts from the central Network Information Center.
MECHANISMA client opens a TCP connection to port 101 on SRI-NIC.ARPA, sends one line such as HNAME or ALL, reads the response, and the server closes the connection.
STATUS TODAYRFC 953 is marked Historic; it revised RFC 811 and pointed toward the Domain Name System as the future.

§1What the Hostname Server Does

The NIC Internet Hostname Server is a TCP-based host information program and protocol that ran on the SRI-NIC machine. It was one of a series of Internet name services kept by the DDN Network Information Center (NIC) at SRI International.

Its job is to deliver machine-readable name and address information describing networks, gateways, hosts and eventually domains. As implemented, it provides the information described in the DoD Internet Host Table Specification (RFC 952). This memo is the official specification of the protocol and includes minor revisions to RFC 811, which it obsoletes. It also points to RFC 921 for the future Domain Name System.

There was one computer that kept the official list of every computer's name and number. This service let other computers ask it for entries from that list.

§2Connecting and Asking

To use the server, a program opens a TCP connection to port 101 (decimal) at the service host, SRI-NIC.ARPA (26.0.0.73 or 10.0.0.51). It sends the information request as a single line and reads the response. The server closes the connection when the response is complete, so only one request can be made per connection.

A request has the form <command key> <argument(s)> [<options>]. A response has the form <response key> : <rest of response>. A response may run over several lines; continuation lines always begin with at least one space.

The RFC warns clients to check what kind of reply they got. An ALL request will likely return several hundred or more records, while HNAME or HADDR will usually return one HOST record.

You dial in, ask exactly one question on a single line, listen to the answer, and the line goes dead. If you have another question, you dial again.

§3Commands and Response Keys

The commands include HELP, VERSION, HNAME (look up by host name), HADDR (look up by host address), ALL (the entire host table), ALL-OLD, DOMAINS, ALL-DOM and ALL-INGWAY. Because the server and its features would evolve, the RFC says to use HELP for the most recent summary.

VERSION lets an automated process check whether a new version of the host table exists without transferring the whole table. The version string is only guaranteed to be unique to each version, and nothing should be assumed about its format.

Response keys are ERR, NET, GATEWAY, HOST, DOMAIN, BEGIN and END. For example, HNAME SRI-NIC.ARPA is likely answered by a HOST record listing the addresses, names, machine type, operating system and services. An ALL request gets BEGIN, then the table in the RFC 952 format, then END:.

There is a short menu of words you can say, like ask-by-name, ask-by-number, or give-me-everything. The answer starts with a word that says what kind of answer it is.

§4Error Replies

An ERR reply may occur on any query, and access programs should be prepared for it. It has the form ERR : <code> : <string> :, for example ERR : NAMNFD : Name not found :.

The error code is a unique descriptor of at most 8 characters, which a program can use to handle the error automatically. The string is a message for programs that just want to log it. The defined codes are NAMNFD (name not in table), ADRNFD (address not in table), ILLCOM (command key not recognized) and TMPSYS (temporary system failure, try again later).

If the librarian cannot find what you asked for, she says so with a short code and a sentence, so you know whether to try again later or give up.

ERROR CODES (RFC 953)
  • NAMNFDName not found — The name is not in the table.
  • ADRNFDAddress not found — The address is not in the table.
  • ILLCOMIllegal command — The command key was not recognized.
  • TMPSYSTemporary system failure — Try again later.

§5References