rfc830.txt

RFC 相关的技术文档

Network Working Group
Request for Comments: 830







             A Distributed System for Internet Name Service


                                  by
                              Zaw-Sing Su










      +-------------------------------------------------------------+     
      |                                                             |
      |   This RFC proposes a distributed name service for DARPA    |
      |   Internet.  Its purpose is to focus discussion on the      |
      |   subject.  It is hoped that a general consensus will       |
      |   emerge leading eventually to the adoption of standards.   |
      |                                                             | 
      +-------------------------------------------------------------+






                             October 1982



                           SRI International
                         333 Ravenswood Avenue
                     Menlo Park, California  94025

			    (415)  859-4576


RFC 830                                                       October 1982







             A Distributed System for Internet Name Service



                            1   INTRODUCTION

     For many years, the ARPANET Naming Convention "<user>@<host>" has
served its user community for its mail system.  The substring "<host>"
has been used for other user applications such as file transfer (FTP)
and terminal access (Telnet).  With the advent of network
interconnection, this naming convention needs to be generalized to
accommodate internetworking.  The Internet Naming Convention [1]
describes a hierarchical naming structure for serving Internet user
applications such as SMTP for electronic mail, FTP and Telnet for file
transfer and terminal access.  It is an integral part of the network
facility generalization to accommodate internetworking.

     Realization of Internet Naming Convention requires the
establishment of both naming authority and name service.  In this
document, we propose an architecture for a distributed System for
Internet Name Service (SINS).  We assume the reader's familiarity with
[1], which describes the Internet Naming Convention.

     Internet Name Service provides a network service for name
resolution and resource negotiation for the establishment of direct
communication between a pair of source and destination application
processes.  The source application process is assumed to be in
possession of the destination name.  In order to establish
communication, the source application process requests for name service.
The SINS resolves the destination name for its network address, and
provides negotiation for network resources.  Upon completion of
successful name service, the source application process provides the
destination address to the transport service for establishing direct
communication with the destination application process.



                              2   OVERVIEW

2.1  System Organization

     SINS is a distributed system for name service.  It logically
consists of two parts: the domain name service and the application
interface (Figure 1).  The domain name service is an application
independent network service for the resolution of domain names.  This
resolution is provided through the cooperation among a set of domain


                                   1

RFC 830                                                       October 1982



name servers (DNSs).  With each domain is associated a DNS.*  The reader
is referred to [2] for the specification of a domain name server.  As
noted in [1], a domain is an administrative but not necessarily a
topological entity.  It is represented in the networks by its associated
DNS.  The resolution of a domain name results in the address of its
associated DNS.


     Application                                   Application
       Process                                       Process
          |                                             |
   SINS   |                                             |
   -------|---------------------------------------------|-----  Application
   |     AIP                                           AIP   |   Interface
   |      |                                             |    |  . . . . . . .
   |     DNS  - - -  DNS  - - -  DNS  - -  . . .  - -  DNS   |  Domain Name
   -----------------------------------------------------------    Service

           Figure 1   Separation of Application Interface

     The application interface provides mechanisms for resolution beyond
that of destination domain and negotiation to ensure resource
availability and compatibility.  Such negotiation is sometimes referred
to as the "what-can-you-do-for-me" negotiation.  The application
interface isolates domain name service from application dependence.  It
thus allows sharing of domain name service among various user
applications.

     The application interface consists of a set of application
interface processes (AIPs) one for each endpoint domain.  For operation
efficiency, the AIP is assumed to be combined with its associated DNS
forming an endpoint DNS (Figure 2).


       Application                                   Application
         Process                                       Process
            |                                             |
     SINS   |                                             |
     -------|---------------------------------------------|-------
     |   Endpoint                                      Endpoint  |
     |     DNS  - - -  DNS  - - -  DNS  - -  . . .  - -  DNS     |
     |                                                           |
     -------------------------------------------------------------

    Figure 2  Distribution of Name Service Components Among Domains

--------------------
* For reasons such as reliability, more than one DNS per domain may be
required.  They may be cooperating DNSs or identical for redundancy.  In
either case, without loss of generality we may logically view the
association as one DNS per domain.


				   2

RFC 830                                                       October 1982

2.2  Domain Resolution

     For name service, the source application process presents to its
local AIP the destination name, and the application service it requests.
For most applications, the application service the source application
process requests would be the service it offers.  The destination name
is assumed to be fully qualified of the form:

	   <local name>@<domain>.<domain>. ... .<domain>

The domains named in the concatenation are hierarchically related [1].
The left-to-right string of simple names in the concatenation proceeds
from the most specific domain to the most general.  The concatenation of
two domains,

		... .<domain A>.<domain B>. ...

implies the one on the left, domain A, to be an immediate member (i.e.,
the first-generation descendent) of the one on the right, domain B.  The
right-most simple name designates a top-level domain, a first-generation
descendent of the naming universe.

     For domain resolution, the AIP consults the domain name service.  It
presents the co-located DNS with the fully qualified domain
specification:

		<domain>.<domain>. ... .<domain>

The DNSs participating in a resolution resolve the concatenation from
the right.  The source endpoint DNS resolves the right-most simple name
and acts as a hub polling the other DNSs.  It resolves the right-most
simple name into an address for the DNS of the specified top-level
domain, then polls that DNS with a request for further resolution.  When
polled, a DNS resolves the next right-most simple domain name.  Upon
successful resolution, an intermediate DNS may have a choice of either
returning the resulting address or forwarding the request to the next
DNS for continuing resolution.
When a intermediate DNS receives a reply from the next DNS, it must
respond to the request it has received.  To simplify the domain name
service protocol, an intermediate DNS is not allowed to act as a hub for
further polling.


2.3  Application Interface

     Addressing for destination endpoint domain is in general not
sufficient for the source application process to establish direct
communication with the destination application process.  In order to
establish direct communication, further addressing may be necessary.
Addressing beyond destination endpoin domain may be necessary when the
addressing of application process cannot be derived from the address of
the endpoint domain.  To provide such derivation capability permanent
binding and universal binding convention, such as TCP port number
assignment, may be necessary.

                                   3

RFC 830                                                       October 1982

     Beyond addressing, negotiation for resource availability and
compatibility is often found necessary.  The application interface
provides a "what-can-you-do-for-me" negotiation capability between the
source and destination endpoint domains.  Such negotiation mechanisms
provided in this design include those for the availability and
compatibility of transport service, e.g., TCP or UDP, and application
service, e.g., SMTP for mail transport.  The availability of such
negotiation service may allow dynamic binding and variations in system
design.

     The application interface offers an integrated service for various
"what-can-you-do-for-me" negotiation capabilities.

2.4  Example

     Let us assume that a request is made at ISID for remote file
transfer using NIFTP to SRI-TSC.  The domain name for ISID is
D.ISI.USC.ARPA,* and TSC.SRI.ARPA for SRI-TSC.  The hierarchical
relationship between these two domains is as depicted in Figure 3 below.
The NIFTP process (an application process) at ISID forwards the domain
name TSC.SRI.ARPA" to the local AIP in domain D for name service.  The
AIP forwards the fully qualified domain name, "TSC.SRI.ARPA", to its co-
located DNS for domain resolution.

     ARPA, the right-most simple name, is assumed to designate a top-
level domain.  The DNS of D recognizes this simple name, resolves it
into the address of the ARPA domain DNS, and forwards the request to
that DNS with a pointer pointing to the next domain "SRI".  The ARPA DNS
recognizes "SRI" as one of its subdomains, resolves the address of the
subdomain's DNS.  It has a choice at this point whether to return this
address to the source endpoint DNS or to forward the request to the DNS
of SRI.

                                         naming
                                        universe
                                      /          \
                               --- ARPA (DNS)
                             /       |
                           /        SRI (DNS)
                         /           |  \
                       USC (DNS)        TSC (DNS/AIP)
                        |                |
                        |          [TCP/FTP/RFT]
                       ISI (DNS)
                        |
                        D (DNS/AIP)
                      /   \
        [TCP/NIFTP/RFT]   [TCP/FTP/RFT]
                    |
                  user

--------------------
* Domain names used in the examples are for illustration purposes only.
The assignment of domain names is beyond the scope of this writeup.

                                   4

RFC 830                                                       October 1982


If it returns the address, the source endpoint DNS at D, would continue
polling by forwarding the request to the SRI DNS.  When the DNS of SRI
detects TSC as the last domain in the concatenation, it resolves the
address for the DNS at TSC, and returns it to the source DNS at domain
D.  Upon receiving a successful domain resolution, the source DNS returns
the obtained address to its associated AIP.

     Since the destination AIP is co-located at this address, the source
AIP is able to forward a request with the service designation
"TCP/NIFTP/RFT" for "what-can-you-do-for-me" negotiation.  Realizing
that within TSC there is no NIFTP but FTP provided for remote file
transfer, the destination AIP would respond accordingly.  Since ISID
also offers FTP service, the "what-can-you-do-for-me" negotiation may
conclude successfully.  The user request for file transfer may thus be
satisfied.



                         3   SYSTEM COMPONENTS

3.1  Component Processes

     The two basic distributed components of SINS are the endpoint DNS
and the intermediate DNS.  An endpoint DNS is associated with each
endpoint domain.  An intermediate DNS is associated with a domain
without any associated application process.

     The intermediate DNS is rather simple.  It has the resolution
capability for translating simple names of first-generation subdomains
to addresses of their associated DNS.  It also communicates with other
DNS for domain resolution.

     An endpoint DNS consists of an AIP and a source DNS.  The source
DNS implements the polling mechanism which communicates with other DNSs
as a hub for polling.  It also has capability for the resolution of top-
level domains.  It responds to requests from the local AIP for domain
resolution (Section 4.2.3).

     The major function of an AIP implements the intellegence of "what-
can-you-do-for-me" negotiations.  A communication module realizes
negotiation exchanges between the source and destination AIPs (Section
4.2.2).  As an interface between the application processes and the local
DNS, it must also implement communication capabilities for exchanges