Return to rfc882.lpr CVS log

Up to [CSRG BSD Unix] / 43BSD / etc / named / doc

Annotation of 43BSD/etc/named/doc/rfc882.lpr, revision 1.1

1.1     ! root        1: 
        !             2: Network Working Group                                     P. Mockapetris
        !             3: Request for Comments:  882                                           ISI
        !             4:                                                            November 1983
        !             5: 
        !             6:                  DOMAIN NAMES - CONCEPTS and FACILITIES
        !             7: 
        !             8:         +-----------------------------------------------------+
        !             9:         |                                                     |
        !            10:         | This RFC introduces domain style names, their use   |
        !            11:         | for ARPA Internet mail and host address support,    |
        !            12:         | and the protocols and servers used to implement     |
        !            13:         | domain name facilities.                             |
        !            14:         |                                                     |
        !            15:         | This memo describes the conceptual framework of the |
        !            16:         | domain system and some uses, but it omits many      |
        !            17:         | uses, fields, and implementation details.  A        |
        !            18:         | complete specification of formats, timeouts, etc.   |
        !            19:         | is presented in RFC 883, "Domain Names -            |
        !            20:         | Implementation and Specification".  That RFC        |
        !            21:         | assumes that the reader is familiar with the        |
        !            22:         | concepts discussed in this memo.                    |
        !            23:         |                                                     |
        !            24:         +-----------------------------------------------------+
        !            25: 
        !            26: INTRODUCTION
        !            27: 
        !            28:    The need for domain names
        !            29: 
        !            30:       As applications grow to span multiple hosts, then networks, and
        !            31:       finally internets, these applications must also span multiple
        !            32:       administrative boundaries and related methods of operation
        !            33:       (protocols, data formats, etc).  The number of resources (for
        !            34:       example mailboxes), the number of locations for resources, and the
        !            35:       diversity of such an environment cause formidable problems when we
        !            36:       wish to create consistent methods for referencing particular
        !            37:       resources that are similar but scattered throughout the
        !            38:       environment.
        !            39: 
        !            40:       The ARPA Internet illustrates the size-related problems; it is a
        !            41:       large system and is likely to grow much larger.  The need to have
        !            42:       a mapping between host names (e.g., USC-ISIF) and ARPA Internet
        !            43:       addresses (e.g., 10.2.0.52) is beginning to stress the existing
        !            44:       mechanisms.  Currently hosts in the ARPA Internet are registered
        !            45:       with the Network Information Center (NIC) and listed in a global
        !            46:       table (available as the file <NETINFO>HOSTS.TXT on the SRI-NIC
        !            47:       host) [1].  The size of this table, and especially the frequency
        !            48:       of updates to the table are near the limit of manageability.  What
        !            49:       is needed is a distributed database that performs the same
        !            50:       function, and hence avoids the problems caused by a centralized
        !            51:       database.
        !            52: 
        !            53:       The problem for computer mail is more severe.  While mail system
        !            54:       implementers long ago recognized the impossibility of centralizing
        !            55: 
        !            56: 
        !            57: Mockapetris                                                     [Page 1]
        !            58: 
        !            59: 
        !            60: RFC 882                                                    November 1983
        !            61:                                   Domain Names - Concepts and Facilities
        !            62: 
        !            63: 
        !            64:       mailbox names, they have also created an increasingly large and
        !            65:       irregular set of methods for identifying the location of a
        !            66:       mailbox.  Some of these methods involve the use of routes and
        !            67:       forwarding hosts as part of the mail destination address, and
        !            68:       consequently force the mail user to know multiple address formats,
        !            69:       the capabilities of various forwarders, and ad hoc tricks for
        !            70:       passing address specifications through intermediaries.
        !            71: 
        !            72:       These problems have common characteristics that suggest the nature
        !            73:       of any solution:
        !            74: 
        !            75:          The basic need is for a consistent name space which will be
        !            76:          used for referring to resources.  In order to avoid the
        !            77:          problems caused by ad hoc encodings, names should not contain
        !            78:          addresses, routes, or similar information as part of the name.
        !            79: 
        !            80:          The sheer size of the database and frequency of updates suggest
        !            81:          that it must be maintained in a distributed manner, with local
        !            82:          caching to improve performance.  Approaches that attempt to
        !            83:          collect a consistent copy of the entire database will become
        !            84:          more and more expensive and difficult, and hence should be
        !            85:          avoided.  The same principle holds for the structure of the
        !            86:          name space, and in particular mechanisms for creating and
        !            87:          deleting names; these should also be distributed.
        !            88: 
        !            89:          The costs of implementing such a facility dictate that it be
        !            90:          generally useful, and not restricted to a single application.
        !            91:          We should be able to use names to retrieve host addresses,
        !            92:          mailbox data, and other as yet undetermined information.
        !            93: 
        !            94:          Because we want the name space to be useful in dissimilar
        !            95:          networks, it is unlikely that all users of domain names will be
        !            96:          able to agree on the set of resources or resource information
        !            97:          that names will be used to retrieve.  Hence names refer to a
        !            98:          set of resources, and queries contain resource identifiers.
        !            99:          The only standard types of information that we expect to see
        !           100:          throughout the name space is structuring information for the
        !           101:          name space itself, and resources that are described using
        !           102:          domain names and no nonstandard data.
        !           103: 
        !           104:          We also want the name server transactions to be independent of
        !           105:          the communications system that carries them. Some systems may
        !           106:          wish to use datagrams for simple queries and responses, and
        !           107:          only establish virtual circuits for transactions that need the
        !           108:          reliability (e.g. database updates, long transactions); other
        !           109:          systems will use virtual circuits exclusively.
        !           110: 
        !           111: 
        !           112: 
        !           113: 
        !           114: 
        !           115: Mockapetris                                                     [Page 2]
        !           116: 
        !           117: 
        !           118: RFC 882                                                    November 1983
        !           119:                                   Domain Names - Concepts and Facilities
        !           120: 
        !           121: 
        !           122:    Elements of the solution
        !           123: 
        !           124:       The proposed solution has three major components:
        !           125: 
        !           126:          The DOMAIN NAME SPACE, which is a specification for a tree
        !           127:          structured name space.  Conceptually, each node and leaf of the
        !           128:          domain name space tree names a set of information, and query
        !           129:          operations are attempts to extract specific types of
        !           130:          information from a particular set.  A query names the domain
        !           131:          name of interest and describes the type of resource information
        !           132:          that is desired.  For example, the ARPA Internet uses some of
        !           133:          its domain names to identify hosts; queries for address
        !           134:          resources return ARPA Internet host addresses.  However, to
        !           135:          preserve the generality of the domain mechanism, domain names
        !           136:          are not required to have a one-to-one correspondence with host
        !           137:          names, host addresses, or any other type of information.
        !           138: 
        !           139:          NAME SERVERS are server programs which hold information about
        !           140:          the domain tree's structure and set information.  A name server
        !           141:          may cache structure or set information about any part of the
        !           142:          domain tree, but in general a particular name server has
        !           143:          complete information about a subset of the domain space, and
        !           144:          pointers to other name servers that can be used to lead to
        !           145:          information from any part of the domain tree.  Name servers
        !           146:          know the parts of the domain tree for which they have complete
        !           147:          information; these parts are called ZONEs; a name server is an
        !           148:          AUTHORITY for these parts of the name space.
        !           149: 
        !           150:          RESOLVERS are programs that extract information from name
        !           151:          servers in response to user requests.  Resolvers must be able
        !           152:          to access at least one name server and use that name server's
        !           153:          information to answer a query directly, or pursue the query
        !           154:          using referrals to other name servers.  A resolver will
        !           155:          typically be a system routine that is directly accessible to
        !           156:          user programs; hence no protocol is necessary between the
        !           157:          resolver and the user program.
        !           158: 
        !           159:       These three components roughly correspond to the three layers or
        !           160:       views of the domain system:
        !           161: 
        !           162:          From the user's point of view, the domain system is accessed
        !           163:          through simple procedure or OS calls to resolvers.  The domain
        !           164:          space consists of a single tree and the user can request
        !           165:          information from any section of the tree.
        !           166: 
        !           167:          From the resolver's point of view, the domain system is
        !           168:          composed of an unknown number of name servers.  Each name
        !           169:          server has one or more pieces of the whole domain tree's data,
        !           170: 
        !           171: 
        !           172: 
        !           173: Mockapetris                                                     [Page 3]
        !           174: 
        !           175: 
        !           176: RFC 882                                                    November 1983
        !           177:                                   Domain Names - Concepts and Facilities
        !           178: 
        !           179: 
        !           180:          but the resolver views each of these databases as essentially
        !           181:          static.
        !           182: 
        !           183:          From a name server's point of view, the domain system consists
        !           184:          of separate sets of local information called zones.  The name
        !           185:          server has local copies of some of the zones.  The name server
        !           186:          must periodically refresh its zones from master copies in local
        !           187:          files or foreign name servers.  The name server must
        !           188:          concurrently process queries that arrive from resolvers using
        !           189:          the local zones.
        !           190: 
        !           191:       In the interests of performance, these layers blur a bit.  For
        !           192:       example, resolvers on the same machine as a name server may share
        !           193:       a database and may also introduce foreign information for use in
        !           194:       later queries.  This cached information is treated differently
        !           195:       from the authoritative data in zones.
        !           196: 
        !           197:    Database model
        !           198: 
        !           199:       The organization of the domain system derives from some
        !           200:       assumptions about the needs and usage patterns of its user
        !           201:       community and is designed to avoid many of the the complicated
        !           202:       problems found in general purpose database systems.
        !           203: 
        !           204:       The assumptions are:
        !           205: 
        !           206:          The size of the total database will initially be proportional
        !           207:          to the number of hosts using the system, but will eventually
        !           208:          grow to be proportional to the number of users on those hosts
        !           209:          as mailboxes and other information are added to the domain
        !           210:          system.
        !           211: 
        !           212:          Most of the data in the system will change very slowly (e.g.,
        !           213:          mailbox bindings, host addresses), but that the system should
        !           214:          be able to deal with subsets that change more rapidly (on the
        !           215:          order of minutes).
        !           216: 
        !           217:          The administrative boundaries used to distribute responsibility
        !           218:          for the database will usually correspond to organizations that
        !           219:          have one or more hosts.  Each organization that has
        !           220:          responsibility for a particular set of domains will provide
        !           221:          redundant name servers, either on the organization's own hosts
        !           222:          or other hosts that the organization arranges to use.
        !           223: 
        !           224:          Clients of the domain system should be able to identify trusted
        !           225:          name servers they prefer to use before accepting referrals to
        !           226:          name servers outside of this "trusted" set.
        !           227: 
        !           228:          Access to information is more critical than instantaneous
        !           229: 
        !           230: 
        !           231: Mockapetris                                                     [Page 4]
        !           232: 
        !           233: 
        !           234: RFC 882                                                    November 1983
        !           235:                                   Domain Names - Concepts and Facilities
        !           236: 
        !           237: 
        !           238:          updates or guarantees of consistency.  Hence the update process
        !           239:          allows updates to percolate out though the users of the domain
        !           240:          system rather than guaranteeing that all copies are
        !           241:          simultaneously updated.  When updates are unavailable due to
        !           242:          network or host failure, the usual course is to believe old
        !           243:          information while continuing efforts to update it.  The general
        !           244:          model is that copies are distributed with timeouts for
        !           245:          refreshing.  The distributor sets the timeout value and the
        !           246:          recipient of the distribution is responsible for performing the
        !           247:          refresh.  In special situations, very short intervals can be
        !           248:          specified, or the owner can prohibit copies.
        !           249: 
        !           250:          Some users will wish to access the database via datagrams;
        !           251:          others will prefer virtual circuits.  The domain system is
        !           252:          designed so that simple queries and responses can use either
        !           253:          style, although refreshing operations need the reliability of
        !           254:          virtual circuits.  The same overall message format is used for
        !           255:          all communication.  The domain system does not assume any
        !           256:          special properties of the communications system, and hence
        !           257:          could be used with any datagram or virtual circuit protocol.
        !           258: 
        !           259:          In any system that has a distributed database, a particular
        !           260:          name server may be presented with a query that can only be
        !           261:          answered by some other server.  The two general approaches to
        !           262:          dealing with this problem are "recursive", in which the first
        !           263:          server pursues the query for the client at another server, and
        !           264:          "iterative", in which the server refers the client to another
        !           265:          server and lets the client pursue the query.  Both approaches
        !           266:          have advantages and disadvantages, but the iterative approach
        !           267:          is preferred for the datagram style of access.  The domain
        !           268:          system requires implementation of the iterative approach, but
        !           269:          allows the recursive approach as an option.  The optional
        !           270:          recursive style is discussed in [14], and omitted from further
        !           271:          discussion in this memo.
        !           272: 
        !           273:       The domain system assumes that all data originates in master files
        !           274:       scattered through the hosts that use the domain system.  These
        !           275:       master files are updated by local system administrators.  Master
        !           276:       files are text files that are read by a local name server, and
        !           277:       hence become available to users of the domain system.  A standard
        !           278:       format for these files is given in [14].
        !           279: 
        !           280:       The standard format allows these files to be exchanged between
        !           281:       hosts (via FTP, mail, or some other mechanism); this facility is
        !           282:       useful when an organization wants a domain, but doesn't want to
        !           283:       support a name server.  The organization can maintain the master
        !           284:       files locally using a text editor, transfer them to a foreign host
        !           285:       which runs a name server, and then arrange with the system
        !           286:       administrator of the name server to get the files loaded.
        !           287: 
        !           288: 
        !           289: Mockapetris                                                     [Page 5]
        !           290: 
        !           291: 
        !           292: RFC 882                                                    November 1983
        !           293:                                   Domain Names - Concepts and Facilities
        !           294: 
        !           295: 
        !           296:       Each host's name servers and resolvers are configured by a local
        !           297:       system administrator.  For a name server, this configuration data
        !           298:       includes the identity of local master files and instructions on
        !           299:       which non-local master files are to be loaded from foreign
        !           300:       servers.  The name server uses the master files or copies to load
        !           301:       its zones.  For resolvers, the configuration data identifies the
        !           302:       name servers which should be the primary sources of information.
        !           303: 
        !           304:       The domain system defines procedures for accessing the data and
        !           305:       for referrals to other name servers.  The domain system also
        !           306:       defines procedures for caching retrieved data and for periodic
        !           307:       refreshing of data defined by the system administrator.
        !           308: 
        !           309:       The system administrators provide:
        !           310: 
        !           311:          The definition of zone boundaries
        !           312: 
        !           313:          Master files of data
        !           314: 
        !           315:          Updates to master files
        !           316: 
        !           317:          Statements of the refresh policies desired
        !           318: 
        !           319:       The domain system provides:
        !           320: 
        !           321:          Standard formats for resource data
        !           322: 
        !           323:          Standard methods for querying the database
        !           324: 
        !           325:          Standard methods for name servers to refresh local data from
        !           326:          foreign name servers
        !           327: 
        !           328: DOMAIN NAME SPACE
        !           329: 
        !           330:    Name space specifications and terminology
        !           331: 
        !           332:       The domain name space is a tree structure.  Each node and leaf on
        !           333:       the tree corresponds to a resource set (which may be empty).  Each
        !           334:       node and leaf has an associated label.  Labels are NOT guaranteed
        !           335:       to be unique, with the exception of the root node, which has a
        !           336:       null label.  The domain name of a node or leaf is the path from
        !           337:       the root of the tree to the node or leaf.  By convention, the
        !           338:       labels that compose a domain name are read left to right, from the
        !           339:       most specific (lowest) to the least specific (highest).
        !           340: 
        !           341:       Internally, programs that manipulate domain names represent them
        !           342:       as sequences of labels, where each label is a length octet
        !           343:       followed by an octet string.  Because all domain names end at the
        !           344:       root, which has a null string for a label, these internal
        !           345: 
        !           346: 
        !           347: Mockapetris                                                     [Page 6]
        !           348: 
        !           349: 
        !           350: RFC 882                                                    November 1983
        !           351:                                   Domain Names - Concepts and Facilities
        !           352: 
        !           353: 
        !           354:       representations can use a length byte of zero to terminate a
        !           355:       domain name.  When domain names are printed, labels in a path are
        !           356:       separated by dots (".").  The root label and its associated dot
        !           357:       are omitted from printed domain names, but the root can be named
        !           358:       by a null domain name (" " in this memo).
        !           359: 
        !           360:       To simplify implementations, the total number of octets that
        !           361:       represent label octets and label lengths is limited to 255.  Thus
        !           362:       a printed domain name can be up to 254 characters.
        !           363: 
        !           364:       A special label is defined that matches any other label.  This
        !           365:       label is the asterisk or "*".  An asterisk matches a single label.
        !           366:       Thus *.ARPA matches FOO.ARPA, but does not match FOO.BAR.ARPA.
        !           367:       The asterisk is mainly used to create default resource records at
        !           368:       the boundary between protocol families, and requires prudence in
        !           369:       its use.
        !           370: 
        !           371:       A domain is identified by a domain name, and consists of that part
        !           372:       of the domain name space that is at or below the domain name which
        !           373:       specifies the domain.  A domain is a subdomain of another domain
        !           374:       if it is contained within that domain.  This relationship can be
        !           375:       tested by seeing if the subdomain's name has the containing
        !           376:       domain's name as the right part of its name.  For example, A.B.C.D
        !           377:       is a subdomain of B.C.D, C.D, D, and " ".
        !           378: 
        !           379:       This tree structure is intended to parallel the administrative
        !           380:       organization and delegation of authority.  Potentially, each node
        !           381:       or leaf on the tree can create new subdomains ad infinitum.  In
        !           382:       practice, this delegation can be limited by the administrator of
        !           383:       the name servers that manage the domain space and resource data.
        !           384: 
        !           385:       The following figure shows an example of a domain name space.
        !           386: 
        !           387:                                    |                            
        !           388:                 +------------------+------------------+         
        !           389:                 |                  |                  |         
        !           390:               COLORS            FLAVORS             TRUTH       
        !           391:                 |                  |                            
        !           392:           +-----+-----+            |                            
        !           393:           |     |     |         NATURAL                         
        !           394:          RED  BLUE  GREEN          |                            
        !           395:                                    |                            
        !           396:                    +---------------+---------------+            
        !           397:                    |               |               |            
        !           398:                CHOCOLATE        VANILLA        STRAWBERRY       
        !           399: 
        !           400:       In this example, the root domain has three immediate subdomains:
        !           401:       COLORS, FLAVORS, and TRUTH.  The FLAVORS domain has one immediate
        !           402:       subdomain named NATURAL.FLAVORS.  All of the leaves are also
        !           403: 
        !           404: 
        !           405: Mockapetris                                                     [Page 7]
        !           406: 
        !           407: 
        !           408: RFC 882                                                    November 1983
        !           409:                                   Domain Names - Concepts and Facilities
        !           410: 
        !           411: 
        !           412:       domains.  This domain tree has the names " "(the root), COLORS,
        !           413:       RED.COLORS, BLUE.COLORS, GREEN.COLORS, FLAVORS, NATURAL.FLAVORS,
        !           414:       CHOCOLATE.NATURAL.FLAVORS, VANILLA.NATURAL.FLAVORS,
        !           415:       STRAWBERRY.NATURAL.FLAVORS, and TRUTH.  If we wished to add a new
        !           416:       domain of ARTIFICIAL under FLAVORS, FLAVORS would typically be the
        !           417:       administrative entity that would decide; if we wished to create
        !           418:       CHIP and MOCHA names under CHOCOLATE, CHOCOLATE.NATURAL.FLAVORS
        !           419:       would typically be the appropriate administrative entity.
        !           420: 
        !           421:    Resource set information
        !           422: 
        !           423:       A domain name identifies a set of resource information.  The set
        !           424:       of resource information associated with a particular name is
        !           425:       composed of separate resource records (RRs).
        !           426: 
        !           427:       Each resource record has the following major components:
        !           428: 
        !           429:          The domain name which identifies resource set that holds this
        !           430:          record, and hence the "owner" of the information.  For example,
        !           431:          a RR that specifies a host address has a domain name the
        !           432:          specifies the host having that address.  Thus F.ISI.ARPA might
        !           433:          be the owner of a RR which specified an address field of
        !           434:          10.2.0.52.  Since name servers typically store their resource
        !           435:          information in tree structures paralleling the organization of
        !           436:          the domain space, this information can usually be stored
        !           437:          implicitly in the database; however it is always included in
        !           438:          each resource record carried in a message.
        !           439: 
        !           440:          Other information used to manage the RR, such as length fields,
        !           441:          timeouts, etc.  This information is omitted in much of this
        !           442:          memo, but is discussed in [14].
        !           443: 
        !           444:          A resource type field that specifies the type of the resource
        !           445:          in this resource record.  Types refer to abstract resources
        !           446:          such as host addresses or mail delivery agents.  The type field
        !           447:          is two octets long and uses an encoding that is standard
        !           448:          throughout the domain name system.
        !           449: 
        !           450:          A class field identifies the format of the resource data, such
        !           451:          as the ARPA Internet format (IN) or the Computer Science
        !           452:          Network format (CSNET), for certain RR types (such as address
        !           453:          data).  Note that while the class may separate different
        !           454:          protocol families, networks, etc. it does not do so in all
        !           455:          cases.  For example, the IN class uses 32 bit IP addresses
        !           456:          exclusively, but the CSNET class uses 32 bit IP addresses, X.25
        !           457:          addresses, and phone numbers.  Thus the class field should be
        !           458:          used as a guide for interpreting the resource data.  The class
        !           459:          field is two octets long and uses an encoding that is standard
        !           460:          throughout the domain name system.
        !           461: 
        !           462: 
        !           463: Mockapetris                                                     [Page 8]
        !           464: 
        !           465: 
        !           466: RFC 882                                                    November 1983
        !           467:                                   Domain Names - Concepts and Facilities
        !           468: 
        !           469: 
        !           470:          Resource data that describes the resource.  The format of this
        !           471:          data can be determined given the type and class fields, but
        !           472:          always starts with a two octet length field that allows a name
        !           473:          server or resolver to determine the boundaries of the resource
        !           474:          data in any transaction, even if it cannot "understand" the
        !           475:          resource data itself.  Thus name servers and resolvers can hold
        !           476:          and pass on records which they cannot interpret.  The format of
        !           477:          the internal data is restricted only by the maximum length of
        !           478:          65535 octets; for example the host address record might specify
        !           479:          a fixed 32 bit number for one class, and a variable length list
        !           480:          of addresses in another class.
        !           481: 
        !           482:       While the class field in effect partitions the resource data in
        !           483:       the domain name system into separate parallel sections according
        !           484:       to class, services can span class boundaries if they use
        !           485:       compatible resource data formats.  For example, the domain name
        !           486:       system uses compatible formats for structure information, and the
        !           487:       mail data decouples mail agent identification from details of how
        !           488:       to contact the agent (e.g. host addresses).
        !           489: 
        !           490:       This memo uses the following types in its examples:
        !           491: 
        !           492:          A     - the host address associated with the domain name
        !           493: 
        !           494:          MF    - identifies a mail forwarder for the domain
        !           495: 
        !           496:          MD    - identifies a mail destination for the domain
        !           497: 
        !           498:          NS    - the authoritative name server for the domain
        !           499: 
        !           500:          SOA   - identifies the start of a zone of authority
        !           501: 
        !           502:          CNAME - identifies the canonical name of an alias
        !           503: 
        !           504:       This memo uses the following classes in its examples:
        !           505: 
        !           506:          IN - the ARPA Internet system
        !           507: 
        !           508:          CS - the CSNET system
        !           509: 
        !           510:       The first type of resource record holds a host name to host
        !           511:       address binding.  Its fields are:
        !           512: 
        !           513:   +--------+--------+--------+--------------//----------------------+
        !           514:   |<owner> |   A    | <class>| <class specific address>information  |
        !           515:   +--------+--------+--------+--------------//----------------------+
        !           516: 
        !           517: 
        !           518: 
        !           519: 
        !           520: 
        !           521: Mockapetris                                                     [Page 9]
        !           522: 
        !           523: 
        !           524: RFC 882                                                    November 1983
        !           525:                                   Domain Names - Concepts and Facilities
        !           526: 
        !           527: 
        !           528:       The content of the class specific information varies according to
        !           529:       the value in the CLASS field; for the ARPA Internet, it is the 32
        !           530:       bit ARPA Internet address of the host, for the CSNET it might be
        !           531:       the phone number of the host.  For example, F.ISI.ARPA might have
        !           532:       two A records of the form:
        !           533: 
        !           534:        +----------+--------+--------+----------------------------+
        !           535:        |F.ISI.ARPA|   A    |   IN   |          10.2.0.52         |
        !           536:        +----------+--------+--------+----------------------------+
        !           537:                                   and
        !           538:        +----------+--------+--------+----------------------------+
        !           539:        |F.ISI.ARPA|   A    |   CS   |         213-822-2112       |
        !           540:        +----------+--------+--------+----------------------------+
        !           541: 
        !           542:       Note that the data formats for the A type are class dependent, and
        !           543:       the Internet address and phone number formats shown above are for
        !           544:       purposes of illustration only.  The actual data formats are
        !           545:       specified in [14].  For example, CS class data for type A records
        !           546:       might actually be a list of Internet addresses, phone numbers and
        !           547:       TELENET addresses.
        !           548: 
        !           549:       The mail forwarder (MF) and mail delivery (MD) records have the
        !           550:       following format:
        !           551: 
        !           552:         +--------+--------+--------+----------------------------+
        !           553:         |<owner> | MD/MF  | <class>|       <domain name>        |
        !           554:         +--------+--------+--------+----------------------------+
        !           555: 
        !           556:       The <domain name> field is a domain name of the host that will
        !           557:       handle mail; note that this domain name may be completely
        !           558:       different from the domain name which names the resource record.
        !           559:       For example, F.ISI.ARPA might have two records of the form:
        !           560: 
        !           561:        +----------+--------+--------+----------------------------+
        !           562:        |F.ISI.ARPA|  MD    |   IN   |         F.ISI.ARPA         |
        !           563:        +----------+--------+--------+----------------------------+
        !           564:                                   and
        !           565:        +----------+--------+--------+----------------------------+
        !           566:        |F.ISI.ARPA|  MF    |   IN   |         B.ISI.ARPA         |
        !           567:        +----------+--------+--------+----------------------------+
        !           568: 
        !           569:       These records mean that mail for F.ISI.ARPA can either be
        !           570:       delivered to the host F.ISI.ARPA or forwarded to B.ISI.ARPA, which
        !           571:       will accept responsibility for its eventual delivery.  In
        !           572:       principle, an additional name lookup is required to map the domain
        !           573:       name of the host to the appropriate address, in practice this
        !           574:       information is usually returned in the response to the mail query.
        !           575: 
        !           576:       The SOA and NS types of resource records are used to define limits
        !           577: 
        !           578: 
        !           579: Mockapetris                                                    [Page 10]
        !           580: 
        !           581: 
        !           582: RFC 882                                                    November 1983
        !           583:                                   Domain Names - Concepts and Facilities
        !           584: 
        !           585: 
        !           586:       of authority.  The domain name given by the owner field of a SOA
        !           587:       record is the start of a zone; the domain name given by the owner
        !           588:       field of a NS record identifies a point in the name space where
        !           589:       authority has been delegated, and hence marks the zone boundary.
        !           590:       Except in the case where a name server delegates authority to
        !           591:       itself, the SOA identifies the top limit of authority, and NS
        !           592:       records define the first name outside of a zone.  These resource
        !           593:       records have a standard format for all of the name space:
        !           594: 
        !           595:       +----------+--------+--------+-----------------------------+
        !           596:       | <owner>  |   SOA  | <class>|       <domain name, etc>    |
        !           597:       +----------+--------+--------+-----------------------------+
        !           598:                                     
        !           599:       +----------+--------+--------+-----------------------------+
        !           600:       | <owner>  |   NS   | <class>|       <domain name>         |
        !           601:       +----------+--------+--------+-----------------------------+
        !           602: 
        !           603:       The SOA record marks the start of a zone when it is present in a
        !           604:       database; the NS record both marks the end of a zone started by an
        !           605:       SOA (if a higher SOA is present) and also points to a name server
        !           606:       that has a copy of the zone specified by the <owner. field of the
        !           607:       NS record.
        !           608: 
        !           609:       The <domain name, etc> in the SOA record specifies the original
        !           610:       source of the information in the zone and other information used
        !           611:       by name servers to organize their activities.  SOA records are
        !           612:       never cached (otherwise they would create false zones); they can
        !           613:       only be created in special name server maintenance operations.
        !           614: 
        !           615:       The NS record says that a name server which is authoritative for
        !           616:       records of the given CLASS can be found at <domain name>.
        !           617: 
        !           618:    Queries
        !           619: 
        !           620:       Queries to a name server must include a domain name which
        !           621:       identifies the target resource set (QNAME), and the type and class
        !           622:       of desired resource records.  The type and class fields in a query
        !           623:       can include any of the corresponding type and class fields that
        !           624:       are defined for resource records; in addition, the query type
        !           625:       (QTYPE) and query class (QCLASS) fields may contain special values
        !           626:       that match more than one of the corresponding fields in RRs.
        !           627: 
        !           628:       For example, the QTYPE field may contain:
        !           629: 
        !           630:          MAILA - matches all mail agent RRs (e.g. MD and MF).
        !           631: 
        !           632:          *     - matches any RR type.
        !           633: 
        !           634: 
        !           635: 
        !           636: 
        !           637: Mockapetris                                                    [Page 11]
        !           638: 
        !           639: 
        !           640: RFC 882                                                    November 1983
        !           641:                                   Domain Names - Concepts and Facilities
        !           642: 
        !           643: 
        !           644:       The QCLASS field may contain:
        !           645: 
        !           646:          *    - matches any RR class.
        !           647: 
        !           648:       Using the query domain name, QTYPE, and QCLASS, the name server
        !           649:       looks for matching RRs.  In addition to relevant records, the name
        !           650:       server may return RRs that point toward a name server that has the
        !           651:       desired information or RRs that are expected to be useful in
        !           652:       interpreting the relevant RRs.  For example a name server that
        !           653:       doesn't have the requested information may know a name server that
        !           654:       does; a name server that returns a domain name in a relevant RR
        !           655:       may also return the RR that binds that domain name to an address.
        !           656: 
        !           657:       Note that the QCLASS=* construct requires special interpretation
        !           658:       regarding authority.  Since a name server may not know all of the
        !           659:       classes available in the domain system, it can never know if it is
        !           660:       authoritative for all classes.  Hence responses to QCLASS=*
        !           661:       queries can never be authoritative.
        !           662: 
        !           663:    Example space
        !           664: 
        !           665:       For purposes of exposition, the following name space is used for
        !           666:       the remainder of this memo:
        !           667: 
        !           668:                                     |                            
        !           669:                  +------------------+------------------+         
        !           670:                  |                  |                  |         
        !           671:                 DDN               ARPA               CSNET       
        !           672:                  |                  |                  |         
        !           673:            +-----+-----+            |            +-----+-----+   
        !           674:            |     |     |            |            |           |   
        !           675:           JCS  ARMY  NAVY           |           UDEL        UCI  
        !           676:                                     |                            
        !           677:            +--------+---------------+---------------+--------+   
        !           678:            |        |               |               |        |   
        !           679:           DTI      MIT             ISI             UDEL     NBS  
        !           680:                     |               |                            
        !           681:                 +---+---+       +---+---+                        
        !           682:                 |       |       |   |   |                        
        !           683:                DMS     AI       A   B   F                        
        !           684: 
        !           685: 
        !           686: 
        !           687: 
        !           688: 
        !           689: 
        !           690: 
        !           691: 
        !           692: 
        !           693: 
        !           694: 
        !           695: Mockapetris                                                    [Page 12]
        !           696: 
        !           697: 
        !           698: RFC 882                                                    November 1983
        !           699:                                   Domain Names - Concepts and Facilities
        !           700: 
        !           701: 
        !           702: NAME SERVERS
        !           703: 
        !           704:    Introduction
        !           705: 
        !           706:       Name servers store a distributed database consisting of the
        !           707:       structure of the domain name space, the resource sets associated
        !           708:       with domain names, and other information used to coordinate
        !           709:       actions between name servers.
        !           710: 
        !           711:       In general, a name server will be an authority for all or part of
        !           712:       a particular domain.  The region covered by this authority is
        !           713:       called a zone.  Name servers may be responsible for no
        !           714:       authoritative data, and hence have no zones, or may have several
        !           715:       zones.  When a name server has multiple zones, the zones may have
        !           716:       no common borders or zones may be contiguous.
        !           717: 
        !           718:       While administrators should not construct overlapping zones, and
        !           719:       name servers must defend against overlapping zones, overlapping is
        !           720:       regarded as a non-fatal flaw in the database.  Hence the measures
        !           721:       taken to protect against it are omitted for the remainder of this
        !           722:       memo.  A detailed discussion can be found in [14].
        !           723: 
        !           724:       When presented with a query for a domain name over which it has
        !           725:       authority, a name server returns the desired resource information
        !           726:       or an indication that the query refers to a domain name or
        !           727:       resource that does not exist.  If a name server is presented with
        !           728:       a query for a domain name that is not within its authority, it may
        !           729:       have the desired information, but it will also return a response
        !           730:       that points toward an authoritative name server.  If a name server
        !           731:       is not an authority for a query, it can never return a negative
        !           732:       response.
        !           733: 
        !           734:       There is no requirement that a name server for a domain reside in
        !           735:       a host which has a name in the same domain, although this will
        !           736:       usually be the case.  There is also no restriction on the number
        !           737:       of name servers that can have authority over a particular domain;
        !           738:       most domains will have redundant authoritative name servers.  The
        !           739:       assumption is that different authoritative copies are identical,
        !           740:       even though inconsistencies are possible as updates are made.
        !           741: 
        !           742:       Name server functions are designed to allow for very simple
        !           743:       implementations of name servers.  The simplest name server has a
        !           744:       static set of information and uses datagrams to receive queries
        !           745:       and return responses.
        !           746: 
        !           747:       More sophisticated name server implementations can improve the
        !           748:       performance of their clients by caching information from other
        !           749:       domains.  Although this information can be acquired in a number of
        !           750:       ways, the normal method is to store the information acquired by a
        !           751: 
        !           752: 
        !           753: Mockapetris                                                    [Page 13]
        !           754: 
        !           755: 
        !           756: RFC 882                                                    November 1983
        !           757:                                   Domain Names - Concepts and Facilities
        !           758: 
        !           759: 
        !           760:       resolver when the resolver consults other name servers.  In a
        !           761:       sophisticated host, the resolver and name server will coordinate
        !           762:       their actions and use a shared database.  This cooperation
        !           763:       requires the incorporation of a time-to-live (TTL) field in all
        !           764:       cached resource records.  Caching is discussed in the resolver
        !           765:       section of this memo; this section is devoted to the actions of a
        !           766:       name servers that don't cache.
        !           767: 
        !           768:       In order to free simple name servers of the requirement of
        !           769:       managing these timeouts, simple name servers should only contain
        !           770:       resource records that are expected to remain constant over very
        !           771:       long periods or resource records for which the name server is an
        !           772:       authority.  In the following discussion, the TTL field is assumed
        !           773:       to be stored in the resource record but is omitted in descriptions
        !           774:       of databases and responses in the interest of clarity.
        !           775: 
        !           776:    Authority and administrative control of domains
        !           777: 
        !           778:       Although we want to have the potential of delegating the
        !           779:       privileges of name space management at every node, we don't want
        !           780:       such delegation to be required.
        !           781: 
        !           782:       Hence we introduce the concept of authority.  Authority is vested
        !           783:       in name servers.  A name server has authority over all of its
        !           784:       domain until it delegates authority for a subdomain to some other
        !           785:       name server.
        !           786: 
        !           787:       Any administrative entity that wishes to establish its own domain
        !           788:       must provide a name server, and have that server accepted by the
        !           789:       parent name server (i.e. the name server that has authority over
        !           790:       the place in the domain name space that will hold the new domain).
        !           791:       While the principles of authority allow acceptance to be at the
        !           792:       discretion of parent name servers, the following criteria are used
        !           793:       by the root, and are recommended to all name servers because they
        !           794:       are responsible for their children's actions:
        !           795: 
        !           796:          1.  It must register with the parent administrator of domains.
        !           797: 
        !           798:          2.  It must identify a responsible person.
        !           799: 
        !           800:          3.  In must provide redundant name servers.
        !           801: 
        !           802:       The domain name must be registered with the administrator to avoid
        !           803:       name conflicts and to make the domain related information
        !           804:       available to other domains.  The central administrator may have
        !           805:       further requirements, and a domain is not registered until the
        !           806:       central administrator agrees that all requirements are met.
        !           807: 
        !           808:       There must be a responsible person associated with each domain to
        !           809: 
        !           810: 
        !           811: Mockapetris                                                    [Page 14]
        !           812: 
        !           813: 
        !           814: RFC 882                                                    November 1983
        !           815:                                   Domain Names - Concepts and Facilities
        !           816: 
        !           817: 
        !           818:       be a contact point for questions about the domain, to verify and
        !           819:       update the domain related information, and to resolve any problems
        !           820:       (e.g., protocol violations) with hosts in the domain.
        !           821: 
        !           822:       The domain must provide redundant (i.e., two or more) name servers
        !           823:       to provide the name to address resolution service.  These name
        !           824:       servers must be accessible from outside the domain (as well as
        !           825:       inside) and must resolve names for at least all the hosts in the
        !           826:       domain.
        !           827: 
        !           828:       Once the central administrator is satisfied, he will communicate
        !           829:       the existence to the appropriate administrators of other domains
        !           830:       so that they can incorporate NS records for the new name server
        !           831:       into their databases.
        !           832: 
        !           833:    Name server logic
        !           834: 
        !           835:       The processing steps that a name server performs in responding to
        !           836:       a query are conceptually simple, although implementations may have
        !           837:       internal databases that are quite complex.
        !           838: 
        !           839:       For purposes of explanation, we assume that the query consists of
        !           840:       a type QTYPE, a class QCLASS, and a domain name QNAME; we assume
        !           841:       that the name server stores its RRs in sets where each set has all
        !           842:       of the RRs for a particular domain.  Note that this database
        !           843:       structure and the following algorithms are meant to illustrate one
        !           844:       possible implementation, rather than a specification of how all
        !           845:       servers must be implemented.
        !           846: 
        !           847:       The following notation is used:
        !           848: 
        !           849:       ord(DOMAIN-NAME)     returns the number of labels in DOMAIN-NAME.
        !           850: 
        !           851:       findset(DOMAIN-NAME) returns a pointer to the set of stored RRs
        !           852:                            for DOMAIN-NAME, or NULL if there is no such
        !           853:                            information.
        !           854: 
        !           855:       set(POINTER)         refers to a set located previously by
        !           856:                            findset, where POINTER is the value returned
        !           857:                            by findset.
        !           858: 
        !           859:       relevant(QTYPE,TYPE) returns true if a RR of the specified TYPE is
        !           860:                            relevant to the specified QTYPE.  For
        !           861:                            example, relevant(MAILA,MF) is true and
        !           862:                            relevant(MAILA,NS) is false.
        !           863: 
        !           864:       right(NAME,NUMBER)   returns a domain name that is the rightmost
        !           865:                            NUMBER labels in the string NAME.
        !           866: 
        !           867: 
        !           868: 
        !           869: Mockapetris                                                    [Page 15]
        !           870: 
        !           871: 
        !           872: RFC 882                                                    November 1983
        !           873:                                   Domain Names - Concepts and Facilities
        !           874: 
        !           875: 
        !           876:       copy(RR)             copies the resource record specified by RR
        !           877:                            into the response.
        !           878: 
        !           879:       The name server code could be represented as the following
        !           880:       sequence of steps:
        !           881: 
        !           882:      {    find out whether the database makes this server          
        !           883:           authoritative for the domain name specified by QNAME   } 
        !           884: 
        !           885:      for i:=0 to ord(QNAME) { sequence through all nodes in QNAME }
        !           886:      do   begin                                                    
        !           887:           ptr:=findset(right(QNAME,i));                            
        !           888:           if ptr<>NULL                                             
        !           889:           then { there is domain data for this domain name }       
        !           890:                begin                                               
        !           891:                for all RRs in set(ptr)                             
        !           892:                do   if type(RR)=NS and class(RR)=QCLASS            
        !           893:                     then begin                                     
        !           894:                          auth=false;                               
        !           895:                          NSptr:=ptr                                
        !           896:                          end;                                      
        !           897:                for all RRs in set(ptr)                             
        !           898:                do   if type(RR)=SOA and class(RR)=QCLASS           
        !           899:                     then auth:=true                                
        !           900:                     end                                            
        !           901:                end;                                                
        !           902:            end;                                                    
        !           903: 
        !           904:       {    copy out authority search results }                     
        !           905: 
        !           906:       if auth                                                      
        !           907:       then { if authority check for domain found }                 
        !           908:            if ptr=null                                             
        !           909:            then return(Name error)                                 
        !           910:            else                                                    
        !           911:       else { if not authority, copy NS RRs }                       
        !           912:            for all RRs in set(nsptr)                               
        !           913:            do   if (type(RR)=NS and class(RR)=QCLASS)              
        !           914:                                  or                                
        !           915:                               (QCLASS=*)                           
        !           916:                 then copy(RR);                                     
        !           917: 
        !           918:       {    Copy all RRs that answer the question }                 
        !           919: 
        !           920:       for all RRs in set(ptr)                                      
        !           921:       do   if class(RR)=QCLASS and relevant(QTYPE,type(RR))        
        !           922:            then copy(RR);                                          
        !           923: 
        !           924:       The first section of the code (delimited by the for loop over all
        !           925: 
        !           926: 
        !           927: Mockapetris                                                    [Page 16]
        !           928: 
        !           929: 
        !           930: RFC 882                                                    November 1983
        !           931:                                   Domain Names - Concepts and Facilities
        !           932: 
        !           933: 
        !           934:       of the subnodes of QNAME) discovers whether the name server is
        !           935:       authoritative for the domain specified by QNAME.  It sequences
        !           936:       through all containing domains of QNAME, starting at the root.  If
        !           937:       it encounters a SOA it knows that the name server is authoritative
        !           938:       unless it finds a lower NS RR which delegates authority.  If the
        !           939:       name server is authoritative, it sets auth=true; if the name
        !           940:       server is not authoritative, it sets NSptr to point to the set
        !           941:       which contains the NS RR closest to the domain specified by QNAME.
        !           942: 
        !           943:       The second section of the code reflects the result of the
        !           944:       authority search into the response.  If the name server is
        !           945:       authoritative, the code checks to see that the domain specified by
        !           946:       QNAME exists; if not, a name error is returned.  If the name
        !           947:       server is not authoritative, the code copies the RRs for a closer
        !           948:       name server into the response.
        !           949: 
        !           950:       The last section of the code copies all relevant RRs into the
        !           951:       response.
        !           952: 
        !           953:       Note that this code is not meant as an actual implementation and
        !           954:       is incomplete in several aspects.  For example, it doesn't deal
        !           955:       with providing additional information, wildcards, QCLASS=*, or
        !           956:       with overlapping zones.  The first two of these issues are dealt
        !           957:       with in the following discussions, the remaining issues are
        !           958:       discussed in [14].
        !           959: 
        !           960:    Additional information
        !           961: 
        !           962:       When a resolver returns information to a user program, the
        !           963:       returned information will often lead to a second query.  For
        !           964:       example, if a mailer asks a resolver for the appropriate mail
        !           965:       agent for a particular domain name, the name server queried by the
        !           966:       resolver returns a domain name that identifies the agent.  In
        !           967:       general, we would expect that the mailer would then request the
        !           968:       domain name to address binding for the mail agent, and a new name
        !           969:       server query would result.
        !           970: 
        !           971:       To avoid this duplication of effort, name servers return
        !           972:       additional information with a response which satisfies the
        !           973:       anticipated query.  This information is kept in a separate section
        !           974:       of the response.  Name servers are required to complete the
        !           975:       appropriate additional information if such information is
        !           976:       available, but the requestor should not depend on the presence of
        !           977:       the information since the name server may not have it.  If the
        !           978:       resolver caches the additional information, it can respond to the
        !           979:       second query without an additional network transaction.
        !           980: 
        !           981:       The appropriate information is defined in [14], but generally
        !           982: 
        !           983: 
        !           984: 
        !           985: Mockapetris                                                    [Page 17]
        !           986: 
        !           987: 
        !           988: RFC 882                                                    November 1983
        !           989:                                   Domain Names - Concepts and Facilities
        !           990: 
        !           991: 
        !           992:       consists of host to address bindings for domain names in returned
        !           993:       RRs.
        !           994: 
        !           995:    Aliases and canonical names
        !           996: 
        !           997:       In existing systems, hosts and other resources often have several
        !           998:       names that identify the same resource.  For example, under current
        !           999:       ARPA Internet naming support, USC-ISIF and ISIF both identify the
        !          1000:       same host.  Similarly, in the case of mailboxes, many
        !          1001:       organizations provide many names that actually go to the same
        !          1002:       mailbox; for example Mockapetris@ISIF, Mockapetris@ISIB, etc., all
        !          1003:       go to the same mailbox (although the mechanism behind this is
        !          1004:       somewhat complicated).
        !          1005: 
        !          1006:       Most of these systems have a notion that one of the equivalent set
        !          1007:       of names is the canonical name and all others are aliases.
        !          1008: 
        !          1009:       The domain system provides a similar feature using the canonical
        !          1010:       name (CNAME) RR.  When a name server fails to find a desired RR in
        !          1011:       a set associated with some domain name, it checks to see if the
        !          1012:       resource set contains a CNAME record with a matching class.  If
        !          1013:       so, the name server includes the CNAME record in the response, and
        !          1014:       continues the query at the domain name specified in the data field
        !          1015:       of the CNAME record.
        !          1016: 
        !          1017:       Suppose a name server was processing a query with QNAME=ISIF.ARPA,
        !          1018:       QTYPE=A, and QCLASS=IN, and had the following resource records:
        !          1019: 
        !          1020:             ISIF.ARPA     CNAME   IN     F.ISI.ARPA         
        !          1021:             F.ISI.ARPA    A       IN     10.2.0.52          
        !          1022: 
        !          1023:       Both of these RRs would be returned in the response.
        !          1024: 
        !          1025:       In the above example, because ISIF.ARPA has no RRs other than the
        !          1026:       CNAME RR, the resources associated with ISIF.ARPA will appear to
        !          1027:       be exactly those associated with F.ISI.ARPA for the IN CLASS.
        !          1028:       Since the CNAME is effective only when the search fails, a CNAME
        !          1029:       can also be used to construct defaults.  For example, suppose the
        !          1030:       name server had the following set of RRs:
        !          1031: 
        !          1032:             F.ISI.ARPA    A       IN     10.2.0.52          
        !          1033:             F.ISI.ARPA    MD      IN     F.ISI.ARPA         
        !          1034:             XXXX.ARPA     CNAME   IN     F.ISI.ARPA         
        !          1035:             XXXX.ARPA     MF      IN     A.ISI.ARPA         
        !          1036: 
        !          1037:       Using this database, type A queries for XXXX.ARPA would return the
        !          1038:       XXXX.ARPA CNAME RR and the F.ISI.ARPA A RR, but MAILA or MF
        !          1039:       queries to XXXX.ARPA would return the XXXX.ARPA MF RR without any
        !          1040:       information from F.ISI.ARPA.  This structure might be used to send
        !          1041: 
        !          1042: 
        !          1043: Mockapetris                                                    [Page 18]
        !          1044: 
        !          1045: 
        !          1046: RFC 882                                                    November 1983
        !          1047:                                   Domain Names - Concepts and Facilities
        !          1048: 
        !          1049: 
        !          1050:       mail addressed to XXXX.ARPA to A.ISI.ARPA and to direct TELNET for
        !          1051:       XXXX.ARPA to F.ISI.ARPA.
        !          1052: 
        !          1053:    Wildcards
        !          1054: 
        !          1055:       In certain cases, an administrator may wish to associate default
        !          1056:       resource information for all or part of a domain.  For example,
        !          1057:       the CSNET domain administrator may wish to establish IN class mail
        !          1058:       forwarding for all hosts in the CSNET domain without IN
        !          1059:       capability.  In such a case, the domain system provides a special
        !          1060:       label "*" that matches any other label.  Note that "*" matches
        !          1061:       only a single label, and not zero or more than one label.  Note
        !          1062:       also that the "*" is distinct from the "*" values for QCLASS and
        !          1063:       QTYPE.
        !          1064: 
        !          1065:       The semantics of "*" depend upon whether it appears in a query
        !          1066:       domain name (QNAME) or in a RR in a database.
        !          1067: 
        !          1068:          When an "*" is used in a QNAME, it can only match a "*" in a
        !          1069:          resource record.
        !          1070: 
        !          1071:          When "*" appears in a RR in a database, it can never override
        !          1072:          an existing exact match.  For example, if a name server
        !          1073:          received a query for the domain UDEL.CSNET, and had appropriate
        !          1074:          RRs for both UDEL.CSNET and *.CSNET, the UDEL.CSNET RRs would
        !          1075:          be used and the *.CSNET RRs would be ignored.  If a query to
        !          1076:          the same database specified FOO.CSNET, the *.CSNET RR would be
        !          1077:          used, but the corresponding labels from the QNAME would replace
        !          1078:          the "*".  Thus the FOO.CSNET query would match the *.CSNET RR
        !          1079:          and return a RR for FOO.CSNET rather than *.CSNET.
        !          1080: 
        !          1081:          RRs containing "*" labels are copied exactly when zones are
        !          1082:          transfered via name server maintenance operations.
        !          1083: 
        !          1084:       These semantics are easily implemented by having the name server
        !          1085:       first search for an exact match for a query, and then replacing
        !          1086:       the leftmost label with a "*" and trying again, repeating the
        !          1087:       process until all labels became "*" or the search succeeded.
        !          1088: 
        !          1089:       TYPE=* in RRs is prohibited.  If it were to be allowed, the
        !          1090:       requestor would have no way of interpreting the data in the RR
        !          1091:       because this data is type dependent.
        !          1092: 
        !          1093:       CLASS=* is also prohibited.  Similar effects can be achieved using
        !          1094:       QCLASS=*, and allowing both QCLASS=* and CLASS=* leads to
        !          1095:       complexities without apparent benefit.
        !          1096: 
        !          1097: 
        !          1098: 
        !          1099: 
        !          1100: 
        !          1101: Mockapetris                                                    [Page 19]
        !          1102: 
        !          1103: 
        !          1104: RFC 882                                                    November 1983
        !          1105:                                   Domain Names - Concepts and Facilities
        !          1106: 
        !          1107: 
        !          1108:    A scenario
        !          1109: 
        !          1110:       In our sample domain space, suppose we wanted separate
        !          1111:       administrative control for the root, DDN, ARPA, CSNET, MIT and ISI
        !          1112:       domains.  We might allocate name servers as follows:
        !          1113: 
        !          1114:                                    |(B.ISI.ARPA)                  
        !          1115:                                    |(UDEL.CSNET)                  
        !          1116:                 +------------------+------------------+           
        !          1117:                 |                  |                  |           
        !          1118:                DDN               ARPA               CSNET         
        !          1119:                 |(JCS.DDN)         |(F.ISI.ARPA)      |(UDEL.ARPA)
        !          1120:           +-----+-----+            |(A.ISI.ARPA)+-----+-----+     
        !          1121:           |     |     |            |            |           |     
        !          1122:          JCS  ARMY  NAVY           |           UDEL        UCI    
        !          1123:                                    |                              
        !          1124:           +--------+---------------+---------------+--------+     
        !          1125:           |        |               |               |        |     
        !          1126:          DTI      MIT             ISI             UDEL     NBS    
        !          1127:                    |(AI.MIT.ARPA)  |(F.ISI.ARPA)                  
        !          1128:                +---+---+       +---+---+                          
        !          1129:                |       |       |   |   |                          
        !          1130:               DMS     AI       A   B   F                          
        !          1131: 
        !          1132:       In this example the authoritative name server is shown in
        !          1133:       parentheses at the point in the domain tree at which is assumes
        !          1134:       control.
        !          1135: 
        !          1136:       Thus the root name servers are on B.ISI.ARPA and UDEL.CSNET, the
        !          1137:       DDN name server is on JCS.DDN, the CSNET domain server is on
        !          1138:       UDEL.ARPA, etc.
        !          1139: 
        !          1140:       In an actual system, all domains should have redundant name
        !          1141:       servers, but in this example only the ARPA domain has redundant
        !          1142:       servers A.ISI.ARPA and F.ISI.ARPA.  (The B.ISI.ARPA and UDEL.CSNET
        !          1143:       name servers happen to be not redundant because they handle
        !          1144:       different classes.)  The F.ISI.ARPA name server has authority over
        !          1145:       the ARPA domain, but delegates authority over the MIT.ARPA domain
        !          1146:       to the name server on AI.MIT.ARPA.  The A.ISI.ARPA name server
        !          1147:       also has authority over the ARPA domain, but delegates both the
        !          1148:       ISI.ARPA and MIT.ARPA domains to other name servers.
        !          1149: 
        !          1150: 
        !          1151: 
        !          1152: 
        !          1153: 
        !          1154: 
        !          1155: 
        !          1156: 
        !          1157: 
        !          1158: 
        !          1159: Mockapetris                                                    [Page 20]
        !          1160: 
        !          1161: 
        !          1162: RFC 882                                                    November 1983
        !          1163:                                   Domain Names - Concepts and Facilities
        !          1164: 
        !          1165: 
        !          1166:    B.ISI.ARPA Name server for " "
        !          1167: 
        !          1168:       B.ISI.ARPA has the root name server for the IN class.  Its
        !          1169:       database might contain:
        !          1170: 
        !          1171:             Domain        Resource Record                   
        !          1172: 
        !          1173:             " "           SOA     IN     A.ISI.ARPA         
        !          1174:             DDN           NS      IN     JCS.DDN            
        !          1175:             ARPA          NS      IN     F.ISI.ARPA         
        !          1176:             CSNET         NS      IN     UDEL.ARPA          
        !          1177:             " "           NS      IN     B.ISI.ARPA         
        !          1178:             " "           NS      CS     UDEL.CSNET         
        !          1179:                                     
        !          1180:             JCS.DDN       A       IN     9.0.0.1            
        !          1181:             F.ISI.ARPA    A       IN     10.2.0.52          
        !          1182:             UDEL.CSNET    A       CS     302-555-0000       
        !          1183:             UDEL.ARPA     A       IN     10.0.0.96          
        !          1184: 
        !          1185:       The SOA record for the root is necessary so that the name server
        !          1186:       knows that it is authoritative for the root domain for class IN.
        !          1187:       The contents of the SOA resource record point back to A.ISI.ARPA
        !          1188:       and denote that the master data for the zone of authority is
        !          1189:       originally from this host.  The first three NS records denote
        !          1190:       delegation of authority.  The NS root entry for the B.ISI.ARPA
        !          1191:       name server is necessary so that this name server knows about
        !          1192:       itself, and can respond correctly to a query for NS information
        !          1193:       about the root (for which it is an authority).  The root entry for
        !          1194:       class CS denotes that UDEL.CSNET is the authoritative name server
        !          1195:       for the CS class root.  UDEL.CSNET and UDEL.ARPA may or may not
        !          1196:       refer to the same name server; from this information it is
        !          1197:       impossible to tell.
        !          1198: 
        !          1199:       If this name server was sent a query specifying QTYPE=MAILA,
        !          1200:       QCLASS=IN, QNAME=F.ISI.ARPA, it would begin processing (using the
        !          1201:       previous algorithm) by determining that it was not an authority
        !          1202:       for F.ISI.ARPA.  The test would note that it had authority at " ",
        !          1203:       but would also note that the authority was delegated at ARPA and
        !          1204:       never reestablished via another SOA.  Thus the response would
        !          1205:       return the NS record for the domain ARPA.
        !          1206: 
        !          1207:       Any queries presented to this server with QCLASS=CS would result
        !          1208:       in the UDEL.CSNET NS record being returned in the response.
        !          1209: 
        !          1210: 
        !          1211: 
        !          1212: 
        !          1213: 
        !          1214: 
        !          1215: 
        !          1216: 
        !          1217: Mockapetris                                                    [Page 21]
        !          1218: 
        !          1219: 
        !          1220: RFC 882                                                    November 1983
        !          1221:                                   Domain Names - Concepts and Facilities
        !          1222: 
        !          1223: 
        !          1224:    F.ISI.ARPA Name server for ARPA and ISI.ARPA
        !          1225: 
        !          1226:       In the same domain space, the F.ISI.ARPA database for the domains
        !          1227:       ARPA and ISI.ARPA might be:
        !          1228: 
        !          1229:             Domain        Resource Record                   
        !          1230: 
        !          1231:             " "           NS      IN     B.ISI.ARPA         
        !          1232:             " "           NS      CS     CSNET.UDEL         
        !          1233:             ARPA          SOA     IN     B.ISI.ARPA         
        !          1234:             ARPA          NS      IN     A.ISI.ARPA         
        !          1235:             ARPA          NS      IN     F.ISI.ARPA         
        !          1236:             MIT.ARPA      NS      IN     AI.MIT.ARPA        
        !          1237:             ISI.ARPA      SOA     IN     F.ISI.ARPA         
        !          1238:             ISI.ARPA      NS      IN     F.ISI.ARPA         
        !          1239: 
        !          1240:             A.ISI.ARPA    MD      IN     A.ISI.ARPA         
        !          1241:             ISI.ARPA      MD      IN     F.ISI.ARPA         
        !          1242:             A.ISI.ARPA    MF      IN     F.ISI.ARPA         
        !          1243:             B.ISI.ARPA    MD      IN     B.ISI.ARPA         
        !          1244:             B.ISI.ARPA    MF      IN     F.ISI.ARPA         
        !          1245:             F.ISI.ARPA    MD      IN     F.ISI.ARPA         
        !          1246:             F.ISI.ARPA    MF      IN     A.ISI.ARPA         
        !          1247:             DTI.ARPA      MD      IN     DTI.ARPA           
        !          1248:             NBS.ARPA      MD      IN     NBS.ARPA           
        !          1249:             UDEL.ARPA     MD      IN     UDEL.ARPA          
        !          1250: 
        !          1251:             A.ISI.ARPA    A       IN     10.1.0.32          
        !          1252:             F.ISI.ARPA    A       IN     10.2.0.52          
        !          1253:             B.ISI.ARPA    A       IN     10.3.0.52          
        !          1254:             DTI.ARPA      A       IN     10.0.0.12          
        !          1255:             AI.MIT.ARPA   A       IN     10.2.0.6           
        !          1256:             DMS.MIT.ARPA  A       IN     10.1.0.6           
        !          1257:             NBS.ARPA      A       IN     10.0.0.19          
        !          1258:             UDEL.ARPA     A       IN     10.0.0.96          
        !          1259: 
        !          1260:       For the IN class, the SOA RR for ARPA denotes that this name
        !          1261:       server is authoritative for the domain ARPA, and that the master
        !          1262:       file for this authority is stored on B.ISI.ARPA.  This zone
        !          1263:       extends to ISI.ARPA, where the database delegates authority back
        !          1264:       to this name server in another zone, and doesn't include the
        !          1265:       domain MIT.ARPA, which is served by a name server on AI.MIT.ARPA.
        !          1266: 
        !          1267:       This name server is not authoritative for any data in the CS
        !          1268:       class.  It has a pointer to the root server for CS data which
        !          1269:       could be use to resolve CS class queries.
        !          1270: 
        !          1271:       Suppose this name server received a query of the form
        !          1272:       QNAME=A.ISI.ARPA, QTYPE=A, and QCLASS=IN.  The authority search
        !          1273: 
        !          1274: 
        !          1275: Mockapetris                                                    [Page 22]
        !          1276: 
        !          1277: 
        !          1278: RFC 882                                                    November 1983
        !          1279:                                   Domain Names - Concepts and Facilities
        !          1280: 
        !          1281: 
        !          1282:       would notice the NS record for " ", its SOA at ARPA, a delegation
        !          1283:       at ISI.ARPA, and the reassumption of authority at ISI.ARPA.  Hence
        !          1284:       it would know that it was an authority for this query.  It would
        !          1285:       then find the A record for A.ISI.ARPA, and return a datagram
        !          1286:       containing this record.
        !          1287: 
        !          1288:       Another query might be QNAME=B.ISI.ARPA, QTYPE=MAILA, QCLASS=*.
        !          1289:       In this case the name server would know that it cannot be
        !          1290:       authoritative because of the "*" value of QCLASS, and would look
        !          1291:       for records for domain B.ISI.ARPA that match.  Assuming that the
        !          1292:       name server performs the additional record inclusion mentioned in
        !          1293:       the name server algorithm, the returned datagram would include:
        !          1294: 
        !          1295:             ISI.ARPA      NS      IN     F.ISI.ARPA         
        !          1296:             " "           NS      CS     UDEL.CSNET         
        !          1297:             B.ISI.ARPA    MD      IN     B.ISI.ARPA         
        !          1298:             B.ISI.ARPA    MF      IN     F.ISI.ARPA         
        !          1299:             B.ISI.ARPA    A       IN     10.3.0.52          
        !          1300:             F.ISI.ARPA    A       IN     10.2.0.52          
        !          1301: 
        !          1302:       If the query were QNAME=DMS.MIT.ARPA, QTYPE=MAILA, QCLASS=IN, the
        !          1303:       name server would discover that AI.MIT.ARPA was the authoritative
        !          1304:       name server and return the following:
        !          1305: 
        !          1306:             MIT.ARPA      NS      IN     AI.MIT.ARPA        
        !          1307:             AI.MIT.ARPA   A       IN     10.2.0.6           
        !          1308: 
        !          1309:       In this case, the requestor is directed to seek information from
        !          1310:       the MIT.ARPA domain name server residing on AI.MIT.ARPA.
        !          1311: 
        !          1312: 
        !          1313: 
        !          1314: 
        !          1315: 
        !          1316: 
        !          1317: 
        !          1318: 
        !          1319: 
        !          1320: 
        !          1321: 
        !          1322: 
        !          1323: 
        !          1324: 
        !          1325: 
        !          1326: 
        !          1327: 
        !          1328: 
        !          1329: 
        !          1330: 
        !          1331: 
        !          1332: 
        !          1333: Mockapetris                                                    [Page 23]
        !          1334: 
        !          1335: 
        !          1336: RFC 882                                                    November 1983
        !          1337:                                   Domain Names - Concepts and Facilities
        !          1338: 
        !          1339: 
        !          1340:    UDEL.ARPA and UDEL.CSNET name server
        !          1341: 
        !          1342:       In the previous discussion of the sample domain, we stated that
        !          1343:       UDEL.CSNET and UDEL.ARPA might be the same name server.  In this
        !          1344:       example, we assume that this is the case.  As such, the name
        !          1345:       server is an authority for the root for class CS, and an authority
        !          1346:       for the CSNET domain for class IN.
        !          1347: 
        !          1348:       This name server deals with mail forwarding between the ARPA
        !          1349:       Internet and CSNET systems.  Its RRs illustrate one approach to
        !          1350:       solving this problem.  The name server has the following resource
        !          1351:       records:
        !          1352: 
        !          1353:             " "           SOA     CS     UDEL.CSNET         
        !          1354:             " "           NS      CS     UDEL.CSNET         
        !          1355:             " "           NS      IN     B.ISI.ARPA         
        !          1356:             CSNET         SOA     IN     UDEL.ARPA          
        !          1357:             CSNET         NS      IN     UDEL.ARPA          
        !          1358:             ARPA          NS      IN     A.ISI.ARPA         
        !          1359: 
        !          1360:             *.CSNET       MF      IN     UDEL.ARPA          
        !          1361:             UDEL.CSNET    MD      CS     UDEL.CSNET         
        !          1362:             UCI.CSNET     MD      CS     UCI.CSNET          
        !          1363:             UDEL.ARPA     MD      IN     UDEL.ARPA          
        !          1364: 
        !          1365:             B.ISI.ARPA    A       IN     10.3.0.52          
        !          1366:             UDEL.ARPA     A       IN     10.0.0.96          
        !          1367:             UDEL.CSNET    A       CS     302-555-0000       
        !          1368:             UCI.CSNET     A       CS     714-555-0000       
        !          1369: 
        !          1370:       Suppose this name server received a query of the form
        !          1371:       QNAME=UCI.CSNET, QTYPE=MAILA, and QCLASS=IN.  The name server
        !          1372:       would discover it was authoritative for the CSNET domain under
        !          1373:       class IN, but would find no explicit mail data for UCI.CSNET.
        !          1374:       However, using the *.CSNET record, it would construct a reply:
        !          1375: 
        !          1376:             UCI.CSNET     MF      IN     UDEL.ARPA          
        !          1377:             UDEL.ARPA     A       IN     10.0.0.96          
        !          1378: 
        !          1379:       If this name server received a query of the form QNAME=UCI.CSNET,
        !          1380:       QTYPE=MAILA, and QCLASS=CS, the name server would return:
        !          1381: 
        !          1382:             UCI.CSNET     MD      CS     UCI.CSNET          
        !          1383:             UCI.CSNET     A       CS     714-555-0000       
        !          1384: 
        !          1385:       Note that although this scheme allows for forwarding of all mail
        !          1386:       addressed as <anything>.CSNET, it doesn't help with names that
        !          1387:       have more than two components, e.g. A.B.CSNET.  Although this
        !          1388:       problem could be "fixed" by a series of MF entries for *.*.CSNET,
        !          1389: 
        !          1390: 
        !          1391: Mockapetris                                                    [Page 24]
        !          1392: 
        !          1393: 
        !          1394: RFC 882                                                    November 1983
        !          1395:                                   Domain Names - Concepts and Facilities
        !          1396: 
        !          1397: 
        !          1398:       *.*.*.CSNET, etc, a more tasteful solution would be to introduce a
        !          1399:       cleverer pattern matching algorithm in the CSNET name server.
        !          1400: 
        !          1401:    Summary of requirements for name servers
        !          1402: 
        !          1403:       The requirements for a name server are as follows:
        !          1404: 
        !          1405:          1. It must be recognized by its parent.
        !          1406: 
        !          1407:          2. It must have complete resource information for all domain
        !          1408:             names for which it is the authority.
        !          1409: 
        !          1410:          3. It must periodically refresh authoritative information from
        !          1411:             a master file or name server which holds the master.
        !          1412: 
        !          1413:          4. If it caches information it must also handle TTL management
        !          1414:             for that information.
        !          1415: 
        !          1416:          5. It must answer simple queries.
        !          1417: 
        !          1418:    Inverse queries
        !          1419: 
        !          1420:       Name servers may also support inverse queries that map a
        !          1421:       particular resource to a domain name or domain names that have
        !          1422:       that resource.  For example, while a query might map a domain name
        !          1423:       to a host address, the corresponding inverse query might map the
        !          1424:       address back to the domain name.
        !          1425: 
        !          1426:       Implementation of this service is optional in a name server, but
        !          1427:       all name servers must at least be able to understand an inverse
        !          1428:       query message and return an error response.
        !          1429: 
        !          1430:       The domain system cannot guarantee the completeness or uniqueness
        !          1431:       of inverse queries because the domain system is organized by
        !          1432:       domain name rather than by host address or any other resource
        !          1433:       type.  In general, a resolver or other program that wishes to
        !          1434:       guarantee that an inverse query will work must use a name server
        !          1435:       that is known to have the appropriate data, or ask all name
        !          1436:       servers in a domain of interest.
        !          1437: 
        !          1438:       For example, if a resolver wishes to perform an inverse query for
        !          1439:       an arbitrary host on the ARPA Internet, it must consult a set of
        !          1440:       name servers sufficient to know that all IN data was considered.
        !          1441:       In practice, a single inverse query to a name server that has a
        !          1442:       fairly comprehensive database should satisfy the vast majority of
        !          1443:       inverse queries.
        !          1444: 
        !          1445:       A detailed discussion of inverse queries is contained in [14].
        !          1446: 
        !          1447: 
        !          1448: 
        !          1449: Mockapetris                                                    [Page 25]
        !          1450: 
        !          1451: 
        !          1452: RFC 882                                                    November 1983
        !          1453:                                   Domain Names - Concepts and Facilities
        !          1454: 
        !          1455: 
        !          1456:    Completion services
        !          1457: 
        !          1458:       Some existing systems provide the ability to complete partial
        !          1459:       specifications of arguments.  The general principle is that the
        !          1460:       user types the first few characters of the argument and then hits
        !          1461:       an escape character to prompt the system to complete the rest.
        !          1462:       Some completion systems require that the user type enough of the
        !          1463:       argument to be unique; others do not.
        !          1464: 
        !          1465:       Other systems allow the user to specify one argument and ask the
        !          1466:       system to fill in other arguments.  For example, many mail systems
        !          1467:       allow the user to specify a username without a host for local mail
        !          1468:       delivery.
        !          1469: 
        !          1470:       The domain system defines name server completion transactions that
        !          1471:       perform the analogous service for the domain system.
        !          1472:       Implementation of this service is optional in a name server, but
        !          1473:       all name servers must at least be able to understand a completion
        !          1474:       request and return an error response.
        !          1475: 
        !          1476:       When a resolver wishes to request a completion, it sends a name
        !          1477:       server a message that sets QNAME to the partial string, QTYPE to
        !          1478:       the type of resource desired, and QCLASS to the desired class.
        !          1479:       The completion request also includes a RR for the target domain.
        !          1480:       The target domain RR identifies the preferred location of the
        !          1481:       resource.  In completion requests, QNAME must still have a null
        !          1482:       label to terminate the name, but its presence is ignored.  Note
        !          1483:       that a completion request is not a query, but shares some of the
        !          1484:       same field formats.
        !          1485: 
        !          1486:       For example, a completion request might contain QTYPE=A, QNAME=B,
        !          1487:       QCLASS=IN and a RR for ISI.ARPA.  This request asks for completion
        !          1488:       for a resource whose name begins with "B" and is "close" to
        !          1489:       ISI.ARPA.  This might be a typical shorthand used in the ISI
        !          1490:       community which uses "B" as a way of referring to B.ISI.ARPA.
        !          1491: 
        !          1492:       The first step in processing a completion request is to look for a
        !          1493:       "whole label" match.  When the name server receives the request
        !          1494:       mentioned above, it looks at all records that are of type A, class
        !          1495:       IN, and whose domain name starts (on the left) with the labels of
        !          1496:       QNAME, in this case, "B".  If multiple records match, the name
        !          1497:       server selects those whose domain names match (from the right) the
        !          1498:       most labels of the preferred domain name.  If there are still
        !          1499:       multiple candidates, the name server selects the records that have
        !          1500:       the shortest (in terms of octets in the name) domain name.  If
        !          1501:       several records remain, then the name server returns them all.
        !          1502: 
        !          1503:       If no records are found in the previous algorithm, the name server
        !          1504:       assumes that the rightmost label in QNAME is not complete, and
        !          1505: 
        !          1506: 
        !          1507: Mockapetris                                                    [Page 26]
        !          1508: 
        !          1509: 
        !          1510: RFC 882                                                    November 1983
        !          1511:                                   Domain Names - Concepts and Facilities
        !          1512: 
        !          1513: 
        !          1514:       looks for records that match but require addition of characters to
        !          1515:       the rightmost label of QNAME.  For example, the previous search
        !          1516:       would not match BB.ARPA to B, but this search would.  If multiple
        !          1517:       hits are found, the same discarding strategy is followed.
        !          1518: 
        !          1519:       A detailed discussion of completion can be found in [14].
        !          1520: 
        !          1521: RESOLVERS
        !          1522: 
        !          1523:    Introduction
        !          1524: 
        !          1525:       Resolvers are programs that interface user programs to domain name
        !          1526:       servers.  In the simplest case, a resolver receives a request from
        !          1527:       a user program (e.g. mail programs, TELNET, FTP) in the form of a
        !          1528:       subroutine call, system call etc., and returns the desired
        !          1529:       information in a form compatible with the local host's data
        !          1530:       formats.
        !          1531: 
        !          1532:       Because a resolver may need to consult several name servers, the
        !          1533:       amount of time that a resolver will take to complete can vary.
        !          1534:       This variance is part of the justification for the split between
        !          1535:       name servers and resolvers; name servers may use datagrams and
        !          1536:       have a response time that is essentially equal to network delay
        !          1537:       plus a short service time, while resolvers may take an essentially
        !          1538:       indeterminate amount of time.
        !          1539: 
        !          1540:       We expect to see two types of resolvers: simple resolvers that can
        !          1541:       chain through multiple name servers when required, and more
        !          1542:       complicated resolvers that cache resource records for use in
        !          1543:       future queries.
        !          1544: 
        !          1545:    Simple resolvers
        !          1546: 
        !          1547:       A simple resolver needs the following capabilities:
        !          1548: 
        !          1549:       1. It must know how to access a name server, and should know the
        !          1550:          authoritative name server for the host that it services.
        !          1551: 
        !          1552:       2. It must know the protocol capabilities for its clients so that
        !          1553:          it can set the class fields of the queries it sends to return
        !          1554:          information that is useful to its clients.  If the resolver
        !          1555:          serves a client that has multiple protocol capabilities, it
        !          1556:          should be able to support the preferences of the client.
        !          1557: 
        !          1558:          The resolver for a multiple protocol client can either collect
        !          1559:          information for all classes using the * class value, or iterate
        !          1560:          on the classes supported by the client.  Note that in either
        !          1561:          case, the resolver must understand the preferences of the host.
        !          1562:          For example, the host that supports both CSNET and ARPA
        !          1563: 
        !          1564: 
        !          1565: Mockapetris                                                    [Page 27]
        !          1566: 
        !          1567: 
        !          1568: RFC 882                                                    November 1983
        !          1569:                                   Domain Names - Concepts and Facilities
        !          1570: 
        !          1571: 
        !          1572:          Internet protocols might prefer mail delivery (MD) to mail
        !          1573:          forwarding (MF), regardless of protocol, or might prefer one
        !          1574:          protocol regardless of whether MD or MF is required.  Care is
        !          1575:          required to prevent loops.
        !          1576: 
        !          1577:       3. The resolver must be capable of chaining through multiple name
        !          1578:          servers to get to an authoritative name server for any query.
        !          1579:          The resolver should guard against loops in referrals; a simple
        !          1580:          policy is to discard referrals that don't match more of the
        !          1581:          query name than the referring name server, and also to avoid
        !          1582:          querying the same name server twice (This test should be done
        !          1583:          using addresses of name servers instead of domain names to
        !          1584:          avoid problems when a name server has multiple domain names or
        !          1585:          errors are present in aliases).
        !          1586: 
        !          1587:       4. The resolver must be able to try alternate name servers when a
        !          1588:          name server doesn't respond.
        !          1589: 
        !          1590:       5. The resolver must be able to communicate different failure
        !          1591:          conditions to its client.  These failure conditions include
        !          1592:          unknown domain name, unknown resource for a know domain name,
        !          1593:          and inability to access any of the authoritative name servers
        !          1594:          for a domain.
        !          1595: 
        !          1596:       6. If the resolver uses datagrams for queries, it must recover
        !          1597:          from lost and duplicate datagrams.
        !          1598: 
        !          1599:    Resolvers with cache management
        !          1600: 
        !          1601:       Caching provides a tool for improving the performance of name
        !          1602:       service, but also is a potential source of incorrect results.  For
        !          1603:       example, a database might cache information that is later changed
        !          1604:       in the authoritative name servers.  While this problem can't be
        !          1605:       eliminated without eliminating caching, it can be reduced to an
        !          1606:       infrequent problem through the use of timeouts.
        !          1607: 
        !          1608:       When name servers return resource records, each record has an
        !          1609:       associated time-to-live (TTL) field.  This field is expressed in
        !          1610:       seconds, and has 16 bits of significance.
        !          1611: 
        !          1612:       When a resolver caches a returned resource record it must also
        !          1613:       remember the TTL field.  The resolver must discard the record when
        !          1614:       the equivalent amount of time has passed.  If the resolver shares
        !          1615:       a database with a name server, it must decrement the TTL field of
        !          1616:       imported records periodically rather than simply deleting the
        !          1617:       record.  This strategy is necessary to avoid exporting a resource
        !          1618:       record whose TTL field doesn't reflect the amount of time that the
        !          1619:       resource record has been cached.  Of course, the resolver should
        !          1620: 
        !          1621: 
        !          1622: 
        !          1623: Mockapetris                                                    [Page 28]
        !          1624: 
        !          1625: 
        !          1626: RFC 882                                                    November 1983
        !          1627:                                   Domain Names - Concepts and Facilities
        !          1628: 
        !          1629: 
        !          1630:       not decrement the TTL fields of records for which the associated
        !          1631:       name server is an authority.
        !          1632: 
        !          1633: 
        !          1634: 
        !          1635: 
        !          1636: 
        !          1637: 
        !          1638: 
        !          1639: 
        !          1640: 
        !          1641: 
        !          1642: 
        !          1643: 
        !          1644: 
        !          1645: 
        !          1646: 
        !          1647: 
        !          1648: 
        !          1649: 
        !          1650: 
        !          1651: 
        !          1652: 
        !          1653: 
        !          1654: 
        !          1655: 
        !          1656: 
        !          1657: 
        !          1658: 
        !          1659: 
        !          1660: 
        !          1661: 
        !          1662: 
        !          1663: 
        !          1664: 
        !          1665: 
        !          1666: 
        !          1667: 
        !          1668: 
        !          1669: 
        !          1670: 
        !          1671: 
        !          1672: 
        !          1673: 
        !          1674: 
        !          1675: 
        !          1676: 
        !          1677: 
        !          1678: 
        !          1679: 
        !          1680: 
        !          1681: Mockapetris                                                    [Page 29]
        !          1682: 
        !          1683: 
        !          1684: RFC 882                                                    November 1983
        !          1685:                                   Domain Names - Concepts and Facilities
        !          1686: 
        !          1687: 
        !          1688: Appendix 1 - Domain Name Syntax Specification
        !          1689: 
        !          1690:    The preferred syntax of domain names is given by the following BNF
        !          1691:    rules.  Adherence to this syntax will result in fewer problems with
        !          1692:    many applications that use domain names (e.g., mail, TELNET).  Note
        !          1693:    that some applications described in [14] use domain names containing
        !          1694:    binary information and hence do not follow this syntax.
        !          1695: 
        !          1696:       <domain> ::=  <subdomain> | " "
        !          1697: 
        !          1698:       <subdomain> ::=  <label> | <subdomain> "." <label>
        !          1699: 
        !          1700:       <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
        !          1701: 
        !          1702:       <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
        !          1703: 
        !          1704:       <let-dig-hyp> ::= <let-dig> | "-"
        !          1705: 
        !          1706:       <let-dig> ::= <letter> | <digit>
        !          1707: 
        !          1708:       <letter> ::= any one of the 52 alphabetic characters A through Z
        !          1709:       in upper case and a through z in lower case
        !          1710: 
        !          1711:       <digit> ::= any one of the ten digits 0 through 9
        !          1712: 
        !          1713:    Note that while upper and lower case letters are allowed in domain
        !          1714:    names no significance is attached to the case.  That is, two names
        !          1715:    with the same spelling but different case are to be treated as if
        !          1716:    identical.
        !          1717: 
        !          1718:    The labels must follow the rules for ARPANET host names.  They must
        !          1719:    start with a letter, end with a letter or digit, and have as interior
        !          1720:    characters only letters, digits, and hyphen.  There are also some
        !          1721:    restrictions on the length.  Labels must be 63 characters or less.
        !          1722: 
        !          1723:    For example, the following strings identify hosts in the ARPA
        !          1724:    Internet:
        !          1725: 
        !          1726:       F.ISI.ARPA     LINKABIT-DCN5.ARPA     UCL-TAC.ARPA
        !          1727: 
        !          1728: 
        !          1729: 
        !          1730: 
        !          1731: 
        !          1732: 
        !          1733: 
        !          1734: 
        !          1735: 
        !          1736: 
        !          1737: 
        !          1738: 
        !          1739: Mockapetris                                                    [Page 30]
        !          1740: 
        !          1741: 
        !          1742: RFC 882                                                    November 1983
        !          1743:                                   Domain Names - Concepts and Facilities
        !          1744: 
        !          1745: 
        !          1746: REFERENCES and BIBLIOGRAPHY
        !          1747: 
        !          1748:    [1]  E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD Internet
        !          1749:         Host Table Specification", RFC 810, Network Information Center,
        !          1750:         SRI International, March 1982.
        !          1751: 
        !          1752:    [2]  J. Postel, "Computer Mail Meeting Notes", RFC 805,
        !          1753:         USC/Information Sciences Institute, February 1982.
        !          1754: 
        !          1755:    [3]  Z. Su, and J. Postel, "The Domain Naming Convention for Internet
        !          1756:         User Applications", RFC 819, Network Information Center, SRI
        !          1757:         International, August 1982.
        !          1758: 
        !          1759:    [4]  Z. Su, "A Distributed System for Internet Name Service",
        !          1760:         RFC 830, Network Information Center, SRI International,
        !          1761:         October 1982.
        !          1762: 
        !          1763:    [5]  K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC 812, Network
        !          1764:         Information Center, SRI International, March 1982.
        !          1765: 
        !          1766:    [6]  M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET Name
        !          1767:         Server", Computer Networks, vol 6, nr 3, July 1982.
        !          1768: 
        !          1769:    [7]  K. Harrenstien, "NAME/FINGER", RFC 742, Network Information
        !          1770:         Center, SRI International, December 1977.
        !          1771: 
        !          1772:    [8]  J. Postel, "Internet Name Server", IEN 116, USC/Information
        !          1773:         Sciences Institute, August 1979.
        !          1774: 
        !          1775:    [9]  K. Harrenstien, V. White, and E. Feinler, "Hostnames Server",
        !          1776:         RFC 811, Network Information Center, SRI International,
        !          1777:         March 1982.
        !          1778: 
        !          1779:    [10] J. Postel, "Transmission Control Protocol", RFC 793,
        !          1780:         USC/Information Sciences Institute, September 1981.
        !          1781: 
        !          1782:    [11] J. Postel, "User Datagram Protocol", RFC 768, USC/Information
        !          1783:         Sciences Institute, August 1980.
        !          1784: 
        !          1785:    [12] J. Postel, "Simple Mail Transfer Protocol", RFC 821,
        !          1786:         USC/Information Sciences Institute, August 1980.
        !          1787: 
        !          1788:    [13] J. Reynolds, and J. Postel, "Assigned Numbers", RFC 870,
        !          1789:         USC/Information Sciences Institute, October 1983.
        !          1790: 
        !          1791:    [14] P. Mockapetris, "Domain Names - Implementation and
        !          1792:         Specification", RFC 883, USC/Information Sciences Institute,
        !          1793:         November 1983.
        !          1794: 
        !          1795: 
        !          1796: 
        !          1797: Mockapetris                                                    [Page 31]
        !          1798: 

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.