Distributed system for Internet name service
RFC 830
|
Document |
Type |
|
RFC - Unknown
(October 1982; No errata)
|
|
Authors |
|
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 830 (Unknown)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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
Show full document text