summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc953.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc953.txt')
-rw-r--r--doc/rfc/rfc953.txt283
1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc953.txt b/doc/rfc/rfc953.txt
new file mode 100644
index 0000000..a083409
--- /dev/null
+++ b/doc/rfc/rfc953.txt
@@ -0,0 +1,283 @@
+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>
+
+
+Harrenstien & Stahl & Feinler [Page 1]
+
+
+
+RFC 953 October 1985
+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
+
+
+Harrenstien & Stahl & Feinler [Page 2]
+
+
+
+RFC 953 October 1985
+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.
+
+
+
+
+Harrenstien & Stahl & Feinler [Page 3]
+
+
+
+RFC 953 October 1985
+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.
+
+
+Harrenstien & Stahl & Feinler [Page 4]
+
+
+
+RFC 953 October 1985
+Hostname Server
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrenstien & Stahl & Feinler [Page 5]
+