Domain names: Concepts and facilities
RFC 882

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

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 <NETINFO>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                                                     [Page 1]



RFC 882                                                    November 1983
                                  Domain Names - Concepts and Facilities

      mailbox names, they have also created an increasingly large and
      irregular set of methods for identifying the location of a
      mailbox.  Some of these methods involve the use of routes and
      forwarding hosts as part of the mail destination address, and
      consequently force the mail user to know multiple address formats,
      the capabilities of various forwarders, and ad hoc tricks for
      passing address specifications through intermediaries.

      These problems have common characteristics that suggest the nature
      of any solution:

         The basic need is for a consistent name space which will be
         used for referring to resources.  In order to avoid the
         problems caused by ad hoc encodings, names should not contain
         addresses, routes, or similar information as part of the name.

         The sheer size of the database and frequency of updates suggest
         that it must be maintained in a distributed manner, with local
         caching to improve performance.  Approaches that attempt to
         collect a consistent copy of the entire database will become
         more and more expensive and difficult, and hence should be
         avoided.  The same principle holds for the structure of the
         name space, and in particular mechanisms for creating and
         deleting names; these should also be distributed.

         The costs of implementing such a facility dictate that it be
         generally useful, and not restricted to a single application.
         We should be able to use names to retrieve host addresses,
         mailbox data, and other as yet undetermined information.

         Because we want the name space to be useful in dissimilar
         networks, it is unlikely that all users of domain names will be
         able to agree on the set of resources or resource information