NIC name server - a datagram-based information utility
RFC 756

Document Type RFC - Unknown (July 1979; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 756 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
RFC: 756                                                July 1979

    The NIC Name Server--A Datagram Based Information Utility


   John R. Pickens, Elizabeth J. Feinler, and James E. Mathis

                            July 1979

                        SRI International
               Telecommunications Sciences Center
                         333 Ravenswood
                  Menlo Park, California 94025

(Also published in Proceedings of the Fourth Berkeley Conference
on Distributed Data Management and Computer Networks)           

NIC Name Server                                         July 1979


  In this paper a new method for distributing and updating host
name/address information in large computer networks is described.
The technique uses datagrams to provide a simple
transaction-based query/response service.  A provisional service
is being provided by the Arpanet Network Information Center (NIC)
and is used by mobile packet radio terminals, as well as by
several Arpanet DEC-10 hosts.  Extensions to the service are
suggested that would expand the query functionality to allow more
flexible query formats as well as queries for service addresses.
Several architectural approaches with potential for expansion
into a distributed internet environment are proposed.  This
technique may be utilized in support of other distributed
applications such as user identification and group distribution
for computer based mail.


  In large computer networks, such as the Arpanet [1],
network-wide standard host-addressing information must be
maintained and distributed.  To fulfill that need, the Arpanet
Network Information Center (NIC) at SRI International has
maintained, administered, and distributed the host addressing
data base to Arpanet hosts since 1972 [2].

  The most common method for maintaining an up-to-date copy on
each host is to bulk-transfer the entire data base to each host
individually.  This technique satisfies most host addressing
needs on the Arpanet today.  However, some hosts maintain neither
a complete nor a current copy of the data base because of limited
memory capacity and infrequent processing of updates.  In
addition, with the expansion of the Arpanet into the internet
environment [3, 4], a strong need has arisen for new techniques
to augment the distribution of name/address information.

  One method currently being investigated is the dynamic
distribution of host-address information via a transaction-based,
inquiry-response process called the Name Server [5, 6].  To
support this investigation, the NIC has developed a provisional
Name Server that is compatible with a level of service specified
in the Defense Advanced Research Projects Agency (DARPA) Internet
experiment [5].  The basic Name Server is described in this paper
and a set of additional functions that such a service might be
expected to support is proposed.

  The discussion is structured as follows:  Section 1 describes
the NIC Name Server and how it is derived from the NIC data base
service.  Section 2 describes extensions of the name server which
allow a richer syntax and queries for service addresses.  Section

SRI International                                        [Page 1]

July 1979                                         NIC Name Server

3 discusses architectural issues, and presents some preliminary
thoughts on how to evolve from the current centralized,
hierarchic service to a distributed Name Server service.


  A Name Server service has been installed on SRI-KA, an Arpanet
DEC-10.  Inquiry-response access is via the Internet Name Server
protocol [5], which in turn employs the DARPA Internet Protocol,
IP4 [7].

  To demonstrate the service a simple interactive facility is
provided to format user input into name server requests--e.g. a
query of the form !ARPANET!FOO-TENEX returns an address such as
"10 2 0 9" (NET=10, HOST=2, LOGICALHOST=0, IMP=9; for details of
host address formats see [8]).

  User access to the name server has been implemented on several
Arpanet DEC-10 TENEX and Packet Radio Network LSI-11 Terminal
Interface Unit (TIU) hosts [9, 10].  While the TENEX program
serves primarily as a demonstration vehicle, the LSI-11 program
provides a valuable augmentation of the TIU's host table.  A
typical scenario is that when the packet radio TIU is initiated
or initialized, it contains only a minimal host table, with the
addresses of a few candidate name servers.  The user queries the
name server with a simple manual query process, and then uses the
address obtained to open a TELNET connection to the desired host.

  The information to support the name server originates from the
NIC's Arpanet host address data base.  An optimized version of
this data base is presented to the name server upon program
initiation as an input file.


  The basic name server provides a simple address-binding service
Show full document text