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
with the DNS and the application processes.
3.2 Databases for Name Resolution
There is a database associated with each resolution module. The
database associated with an endpoint domain contains name-to-address
5
RFC 830 October 1982
correspondences for the top-level domains, first-generation descendents
of the naming universe. It facilitates the endpoint DNS resolving the
right-most simple name of a fully-qualified domain specification.
The database associated with an intermediate domain contains name-
to-address correspondences for the first-generation subdomains of this
domain. Thus, the required database contents among the intermediate DNS
databases are disjoint, and updates are local.
It is also noticed that with the implementation of the SINS, there
is no need for database format standardization.
3.3 Caching
The component processes and resolution databases constitute the
basic System for Internet Name Service. The distributed components are
related according to the domain hierarchy. The databases associated
with the endpoint domains are all identical. Containing only name-to-
address correspondence for top-level domains, the endpoint database
should be rather small in size. The disjoint nature of intermediate DNS
databases allows easy local updates.
However, communications will be very inefficient if the Internet
name service is called for the establishment of every transaction. A
standard solution to aleviate such inefficiency is the use of caching.
Caching is a mechanism reusing previous resolution results. To
expedite establishment of communication, the resolution results are
stored for future reference. We do not incorporate caching as a
standard feature of the SINS. However, we assume the use of caching for
efficient operations at individual implementor's discretion.
4 INTER-COMPONENT COMMUNICATIONS (THE INTERNET NAME SERVICE PROTOCOLS)
In this section, we present a format specification for
correspondences between various component pairs. For co-located
components, communication becomes interprocess, and the exact format
less important. For inter-host communication, the format specification
here defines a name service protocol.
The communicating component pairs of concern here are application
process/AIP, AIP/DNS, and AIP/AIP. The communications employ
request/response commands. A single command structure is adopted for
all three pairs; while communications between a particular pair may
employ a subset of the commands. Such uniformity allows minimum
processing and maximum code sharing for implementation.
6
RFC 830 October 1982
4.1 Command Structure
The basic command structure begins with two octets indicating
command type and the number of items in the command. They are followed
by the indicated number of items. The type of an item is indicated in
its first octet, followed by a one-octet content length, and then the
item content. Required presence or absence and order of the items for
each component pair are specified in this section.
Command Type Number of Items
Item Indicator Content Length Item Content
.
.
Command Type
This type coded in binary number indicates whether this command is
a request, an affirmative response, or some other type of response (see
Appendix A for the command types and their corresponding code). This
type specification implies the presence or absence and order of the
following items.
Number of Items
This number is expressed in binary number. It specifies the number
of following items. Owing to the possibility of a multiple response,
this number may vary for a particular command.
Item Indicator
This indicator defines the item type. The possible types include:
service, name, address, and comment. The type of an item implies its
content structure.
Content Length
This length specification, in binary, indicates the length of the
following content in octets. The maximum can be specified is 255, thus
the maximum length of the content. However, this maximum may also be
constrained by the total length of the command (Section 4.3).
Item Content
The contents for different items are:
Service -- Transport protocol/service protocol/service type
(ASCII). (See Appendix A for standard identifiers for
service specifications.)
Name -- Whole or partial name string according to Internet Naming
Convention [1] (ASCII).
Address -- The address is presented in binary form. In this
writeup, double quotes, " ", are used around decimal
values separated by a space to represent octets of the
binary form.
7
RFC 830 October 1982
Parsing of the address is implied by the specified
transport protocol. In the case of TCP, the first
four octets gives the 32-bit IP address, the 5th octet
the IP-specific protocol number, and the 6th the TCP or
UDP port number for the application service.
Comment -- The item is mostly optional. Its presence may allow
an intermediate server passing comment to the end user.
Error comments explaining resolution failure is an
example of its use.
4.2 Command Specification
In this section, we define the name service commands for the
various communication pairs.
4.2.1 Application Process/AIP Communication
From the name service point of view, there is no need for
communication between the AIP and an application process at the
destination. Thus, here we discuss communications at the originating
domain.
An application process initiates a dialogue by making a request for
name service to its local AIP. It provides the requested application
service and a destination name for resolution.
REQUEST
Command Type Number of Items
Service Indicator Length Transport Protocol/Service/Service Type
Name Indicator Name Length Name String
Examples:
1 2
3 13 TCP/SMTP/mail
1 21 Postel@F.ISI.USC.ARPA
1 2
3 13 TCP/NIFTP/RFT
1 12 TSC.SRI.ARPA
The first example is a resolution request for the name
"Postel@F.ISI.USC.ARPA". It is 21 octets in length. The requested
application service is TCP/SMTP/mail. The second example is a
resolution request for application service NIFTP at TSC.SRI.ARPA.
8
RFC 830 October 1982
AFFIRMATIVE RESPONSE
Command Type Number of Items
Service Indicator Length Transport Protocol/Service/Service Type
Name Indicator Name Length Name String
Address Indicator Address Length Address
Examples:
2 3
3 13 TCP/SMTP/mail
1 21 Postel@F.ISI.USC.ARPA
2 6 "10 2 0 52 6 25"
2 4
3 13 TCP/NIFTP/RFT
1 12 TSC.SRI.ARPA
2 6 "10 3 0 2 6 47"
2 6 "39 0 0 5 6 47"
An affirmative response implies that the destination offers the
requested service. The parsing of an address is implied by the
indicated transport protocol. In the first example, the transport
protocol is TCP. Thus, the address is composed of three fields: the
internet address ("10 2 0 52"), the protocol number ("6" for TCP [3]),
and the port number ("25" for SMTP [3]). A multiple-address response in
the second example indicates that TSC is multi-homed via both ARPANET
(net 10), and SRINET (net 39). A multiple-resolution response is
preferred. It offers the source a choice.
NEGATIVE RESPONSE
Command Type Number of Items
Service Indicator Length Transport Protocol/Service/Service Type
Name Indicator Name Length Name String
Name Indicator Name Length Partial Name String
[Comment Indicator Comment Length Comment]
This indicates difficulty in resolution. Returned with this
command is the left-most portion of the specified name including the
difficulty encountered. An optional comment item may be included.
9
RFC 830 October 1982
Examples:
3 4
3 13 TCP/SMTP/mail
1 16 Postel@F.ISI.USC
1 16 Postel@F.ISI.USC
9 18 Resolution Failure
3 4
3 13 TCP/NIFTP/RFT
1 13 TSC..SRI.ARPA
1 5 TSC..
9 17 Syntactic Anomaly
In the first example, the resolution failed because USC is not top-level
domain. The syntactic error of adajacent dots in the second example is
obvious.
INCOMPATIBLE SERVICE
This response indicates no compatible application and/or transport
service is available at the destination. For example, the requested
application service may be SMTP, while only FTP-mail is available at the
destination. Return with this command is the available corresponding
available service, if any, and its address. If no service is available
for that service type, an empty string for service specification is
returned.
Command Type Number of Items
Service Indicator Length Transport Protocol/Service/Service Type
Name Indicator Name Length Name String
Service Indicator Length Transport Protocol/Service/Service Type
[Address Indicator Address Length Address]
Examples:
9 3
3 14 TCP/NIFTP/mail
1 21 Postel@F.ISI.USC.ARPA
3 0
9 5
3 13 TCP/NIFTP/RFT
1 12 TSC.SRI.ARPA
3 11 TCP/FTP/RFT
2 6 "10 3 0 2 6 21"
2 6 "39 0 0 5 6 21"
10
RFC 830 October 1982
4.2.2 AIP/AIP Communication
Communication between the AIPs accomplishes the "what-can-you-do-
for-me" negotiation. Examples in this section correspond to those of
Section 4.2.1.
REQUEST
Command Type Number of Items
Service Indicator Length Transport Protocol/Service/Service Type
Examples:
1 1
3 13 TCP/SMTP/mail
1 1
3 13 TCP/NIFTP/RFT
AFFIRMATIVE RESPONSE
Command Type Number of Items
Service Indicator Length Transport Protocol/Service/Service Type
Address Indicator Address Length Address
Examples:
2 2
3 13 TCP/SMTP/mail
2 6 "10 2 0 52 6 25"
2 3
3 14 TCP/NIFTP/RFT
2 6 "10 3 0 2 6 47"
2 6 "39 0 0 5 6 47"
An affirmative response implies that the destination offers the
same service as that of the originator. A multi-resolution response is
possible. The parsing of an address is implied by the indicated
transport protocol. In the second example, the transport protocol is
TCP. Thus, the address is composed of three fields: the internet
address (10 2 0 52), the protocol number (6 for TCP), and the port
number (25 for SMTP). The returned address(es) is to be relayed to the
originating application process.
11
RFC 830 October 1982
INCOMPATIBLE SERVICE
Command Type Number of Items
Service Indicator Length Transport Protocol/Service/Service Type
Service Indicator Length Transport Protocol/Service/Service Type
Address Indicator Address Length Address
This response indicates no compatible application and/or transport
service available serving the destination. For example, SMTP may be the
requested application service, while only NIFTP-mail is available
serving the destination. Return with this command is the available
service of that type. If no service available for that service type, a
empty text string is returned.
Examples:
9 2
3 14 TCP/NIFTP/mail
3 0
9 4
3 13 TCP/NIFTP/RFT
3 11 TCP/FTP/RFT
2 6 "10 3 0 2 6 21"
2 6 "39 0 0 5 6 21"
In the first example, the destination does not offer any kind of mail
service. The second example indicates that there is no NIFTP, but FTP
available for remote file transfer service at the destination.
4.2.3 AIP/DNS Communication
The source AIP presents its associated DNS with a fully qualified
domain specification for resolution. The expected resolution result is
the network address for the destination endpoint DNS. We assume no need
for communication between the DNS and AIP at the destination.
REQUEST
Command Type Number of Items
Name Indicator Name Length Name String
Examples:
1 1
1 14 F.ISI.USC.ARPA
1 1
1 12 TSC.SRI.ARPA
12
RFC 830 October 1982
AFFIRMATIVE RESPONSE
Command Type Number of Items
Name Indicator Name Length Name String
Service Indicator Service Length Transport Protocol
Address Indicator Address Length Address
Examples:
2 3
1 14 F.ISI.USC.ARPA
3 3 UDP
2 6 "10 2 0 52 17 42"
2 4
1 7 TSC.SRI.ARPA
3 3 UDP
2 6 "10 3 0 2 17 42"
2 6 "39 0 0 5 17 42"
An affirmative response returns an address of the destination endpoint
DNS. This returned address is that of the destination DNS. The
destination transport service needs to be indicated for guiding the
parsing of the destination address.
NEGATIVE RESPONSE
Command Type Number of Items
Name Indicator Name Length Name String
Name Indicator Name Length Partial Name String
[Comment Indicator Comment Length Comment]
This response indicates that the domain name service is unable to
resolve the given destination domain name. It could be caused by an
unknown simple name, which may result from, for example, misspelling.
Returned with this command is the left-most portion of the specified
name containing the cause of resolution failure.
Example:
1 3
1 9 F.ISI.USC
1 9 F.ISI.USC
9 18 Resolution Failure
13
RFC 830 October 1982
4.2.4 DNS/DNS Communication
The domain name service is an application independent network
service. It provides the resolution of domain names. For the
specification of this service the reader is referred to [2].
4.3 Transport Protocol
For generality, this specification is intentionally transport
protocol independent. Implications for the use of TCP and UDP are
specifically considered.
Typically, for distributed name service a server A makes a request
to a server B, server B may need to in turn contact other servers to
complete a resolution. TCP is a connection-oriented protocol. It
offers reliable transport, but also imposes certain amount of overhead
for connection establishment and maintenance. For most cases, the use
of TCP is not recommended.
UDP is a datagram service offering a transport capacity per
datagram in excess of 500 octets. Such capacity should suffice most
conceivable commands within this specification. However, it does impose
a limit on the total length of a command. In order to enhance
reliability, the request is incorporated as part of every response
command.
5 NCP TO TCP TRANSITION
The Internet Naming Convention, "<user>@<domain>. ... . <domain>"
[1], is a generalization of "<user>@<host>", the ARPANET Naming
Convention. It is a generalization in the sense that the ARPANET Naming
Convention can be considered as a partially qualified form of the subset
"<user>@<host>.ARPANET". (We assume here ARPANET is a top-level domain
name.)
For the transition from NCP to TCP, we may initially treat each
host name entry in the current host table as a subdomain of the top-
level domain ARPANET. Thus, initially there would be a very flat domain
structure. This structure can be gradually changed after the transition
toward a hierarchical structure when more and more domains and
subdomains are defined and name servers installed. In the process of
this change, the host table would be gradually converted into
distributed domain tables (databases). For the newly created domain
tables, no standard format would be required. Each individual domain
table may have its own format suitable to the design of its associated
domain name server.
14
RFC 830 October 1982
REFERENCES
[1] Su, Z. and J. Postel, "The Domain Naming Convention for Internet
User Applications," RFC 819, SRI International (August 1982).
[2] Postel, J., "Domains Name Server," RFC XXX, USC/Information
Sciences Institute (to appear).
[3] Postel, J., "Assigned Numbers," RFC 790, USC/Information Sciences
Institute (September 1981).
15
RFC 830 October 1982
Appendix A
CONVENTION ASSIGNMENTS
Command Types
Request 1
Affirmative Response 2
Negative Response 3
Imcompatible Service 9
INDICATORS
Name Indicator 1
Address Indicator 2
Service Indicator 3
Comment Indicator 9
TRANSPORT PROTOCOLS: TCP, UDP, NCP
SERVICES
Service Protocols Service Type
MTP mail
SMTP mail
FTP (FTP mail) mail
NIFTP (NIFTP mail) mail
MMDF mail
FTP RFT (remote file transfer)
Telnet RTA (remote terminal access)
16