RFC 882 (rfc882) - Page 1 of 31
Domain names: Concepts and facilities
Alternative Format: Original Text Document
Network Working Group P. Mockapetris
Request for Comments: 882 ISI
November 1983
DOMAIN NAMES - CONCEPTS and FACILITIES
+-----------------------------------------------------+
| |
| This RFC introduces domain style names, their use |
| for ARPA Internet mail and host address support, |
| and the protocols and servers used to implement |
| domain name facilities. |
| |
| This memo describes the conceptual framework of the |
| domain system and some uses, but it omits many |
| uses, fields, and implementation details. A |
| complete specification of formats, timeouts, etc. |
| is presented in RFC 883, "Domain Names - |
| Implementation and Specification". That RFC |
| assumes that the reader is familiar with the |
| concepts discussed in this memo. |
| |
+-----------------------------------------------------+
INTRODUCTION
The need for domain names
As applications grow to span multiple hosts, then networks, and
finally internets, these applications must also span multiple
administrative boundaries and related methods of operation
(protocols, data formats, etc). The number of resources (for
example mailboxes), the number of locations for resources, and the
diversity of such an environment cause formidable problems when we
wish to create consistent methods for referencing particular
resources that are similar but scattered throughout the
environment.
The ARPA Internet illustrates the size-related problems; it is a
large system and is likely to grow much larger. The need to have
a mapping between host names (e.g., USC-ISIF) and ARPA Internet
addresses (e.g., 10.2.0.52) is beginning to stress the existing
mechanisms. Currently hosts in the ARPA Internet are registered
with the Network Information Center (NIC) and listed in a global
table (available as the file HOSTS.TXT on the SRI-NIC
host) [1]. The size of this table, and especially the frequency
of updates to the table are near the limit of manageability. What
is needed is a distributed database that performs the same
function, and hence avoids the problems caused by a centralized
database.
The problem for computer mail is more severe. While mail system
implementers long ago recognized the impossibility of centralizing
Mockapetris
