Return to rfc1034.lpr CVS log

Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / named / doc

Annotation of 43BSDReno/usr.sbin/named/doc/rfc1034.lpr, revision 1.1

1.1     ! root        1: Network Working Group                                     P. Mockapetris
        !             2: Request for Comments: 1034                                           ISI
        !             3: Obsoletes: RFCs 882, 883, 973                              November 1987
        !             4: 
        !             5: 
        !             6:                  DOMAIN NAMES - CONCEPTS AND FACILITIES
        !             7: 
        !             8: 
        !             9: 
        !            10: 1. STATUS OF THIS MEMO
        !            11: 
        !            12: This RFC is an introduction to the Domain Name System (DNS), and omits
        !            13: many details which can be found in a companion RFC, "Domain Names -
        !            14: Implementation and Specification" [RFC-1035].  That RFC assumes that the
        !            15: reader is familiar with the concepts discussed in this memo.
        !            16: 
        !            17: A subset of DNS functions and data types constitute an official
        !            18: protocol.  The official protocol includes standard queries and their
        !            19: responses and most of the Internet class data formats (e.g., host
        !            20: addresses).
        !            21: 
        !            22: However, the domain system is intentionally extensible.  Researchers are
        !            23: continuously proposing, implementing and experimenting with new data
        !            24: types, query types, classes, functions, etc.  Thus while the components
        !            25: of the official protocol are expected to stay essentially unchanged and
        !            26: operate as a production service, experimental behavior should always be
        !            27: expected in extensions beyond the official protocol.  Experimental or
        !            28: obsolete features are clearly marked in these RFCs, and such information
        !            29: should be used with caution.
        !            30: 
        !            31: The reader is especially cautioned not to depend on the values which
        !            32: appear in examples to be current or complete, since their purpose is
        !            33: primarily pedagogical.  Distribution of this memo is unlimited.
        !            34: 
        !            35: 2. INTRODUCTION
        !            36: 
        !            37: This RFC introduces domain style names, their use for Internet mail and
        !            38: host address support, and the protocols and servers used to implement
        !            39: domain name facilities.
        !            40: 
        !            41: 2.1. The history of domain names
        !            42: 
        !            43: The impetus for the development of the domain system was growth in the
        !            44: Internet:
        !            45: 
        !            46:    - Host name to address mappings were maintained by the Network
        !            47:      Information Center (NIC) in a single file (HOSTS.TXT) which
        !            48:      was FTPed by all hosts [RFC-952, RFC-953].  The total network
        !            49: 
        !            50: 
        !            51: 
        !            52: Mockapetris                                                     [Page 1]
        !            53: 
        !            54: RFC 1034             Domain Concepts and Facilities        November 1987
        !            55: 
        !            56: 
        !            57:      bandwidth consumed in distributing a new version by this
        !            58:      scheme is proportional to the square of the number of hosts in
        !            59:      the network, and even when multiple levels of FTP are used,
        !            60:      the outgoing FTP load on the NIC host is considerable.
        !            61:      Explosive growth in the number of hosts didn't bode well for
        !            62:      the future.
        !            63: 
        !            64:    - The network population was also changing in character.  The
        !            65:      timeshared hosts that made up the original ARPANET were being
        !            66:      replaced with local networks of workstations.  Local
        !            67:      organizations were administering their own names and
        !            68:      addresses, but had to wait for the NIC to change HOSTS.TXT to
        !            69:      make changes visible to the Internet at large.  Organizations
        !            70:      also wanted some local structure on the name space.
        !            71: 
        !            72:    - The applications on the Internet were getting more
        !            73:      sophisticated and creating a need for general purpose name
        !            74:      service.
        !            75: 
        !            76: 
        !            77: The result was several ideas about name spaces and their management
        !            78: [IEN-116, RFC-799, RFC-819, RFC-830].  The proposals varied, but a
        !            79: common thread was the idea of a hierarchical name space, with the
        !            80: hierarchy roughly corresponding to organizational structure, and names
        !            81: using "."  as the character to mark the boundary between hierarchy
        !            82: levels.  A design using a distributed database and generalized resources
        !            83: was described in [RFC-882, RFC-883].  Based on experience with several
        !            84: implementations, the system evolved into the scheme described in this
        !            85: memo.
        !            86: 
        !            87: The terms "domain" or "domain name" are used in many contexts beyond the
        !            88: DNS described here.  Very often, the term domain name is used to refer
        !            89: to a name with structure indicated by dots, but no relation to the DNS.
        !            90: This is particularly true in mail addressing [Quarterman 86].
        !            91: 
        !            92: 2.2. DNS design goals
        !            93: 
        !            94: The design goals of the DNS influence its structure.  They are:
        !            95: 
        !            96:    - The primary goal is a consistent name space which will be used
        !            97:      for referring to resources.  In order to avoid the problems
        !            98:      caused by ad hoc encodings, names should not be required to
        !            99:      contain network identifiers, addresses, routes, or similar
        !           100:      information as part of the name.
        !           101: 
        !           102:    - The sheer size of the database and frequency of updates
        !           103:      suggest that it must be maintained in a distributed manner,
        !           104:      with local caching to improve performance.  Approaches that
        !           105: 
        !           106: 
        !           107: 
        !           108: Mockapetris                                                     [Page 2]
        !           109: 
        !           110: RFC 1034             Domain Concepts and Facilities        November 1987
        !           111: 
        !           112: 
        !           113:      attempt to collect a consistent copy of the entire database
        !           114:      will become more and more expensive and difficult, and hence
        !           115:      should be avoided.  The same principle holds for the structure
        !           116:      of the name space, and in particular mechanisms for creating
        !           117:      and deleting names; these should also be distributed.
        !           118: 
        !           119:    - Where there tradeoffs between the cost of acquiring data, the
        !           120:      speed of updates, and the accuracy of caches, the source of
        !           121:      the data should control the tradeoff.
        !           122: 
        !           123:    - The costs of implementing such a facility dictate that it be
        !           124:      generally useful, and not restricted to a single application.
        !           125:      We should be able to use names to retrieve host addresses,
        !           126:      mailbox data, and other as yet undetermined information.  All
        !           127:      data associated with a name is tagged with a type, and queries
        !           128:      can be limited to a single type.
        !           129: 
        !           130:    - Because we want the name space to be useful in dissimilar
        !           131:      networks and applications, we provide the ability to use the
        !           132:      same name space with different protocol families or
        !           133:      management.  For example, host address formats differ between
        !           134:      protocols, though all protocols have the notion of address.
        !           135:      The DNS tags all data with a class as well as the type, so
        !           136:      that we can allow parallel use of different formats for data
        !           137:      of type address.
        !           138: 
        !           139:    - We want name server transactions to be independent of the
        !           140:      communications system that carries them.  Some systems may
        !           141:      wish to use datagrams for queries and responses, and only
        !           142:      establish virtual circuits for transactions that need the
        !           143:      reliability (e.g., database updates, long transactions); other
        !           144:      systems will use virtual circuits exclusively.
        !           145: 
        !           146:    - The system should be useful across a wide spectrum of host
        !           147:      capabilities.  Both personal computers and large timeshared
        !           148:      hosts should be able to use the system, though perhaps in
        !           149:      different ways.
        !           150: 
        !           151: 2.3. Assumptions about usage
        !           152: 
        !           153: The organization of the domain system derives from some assumptions
        !           154: about the needs and usage patterns of its user community and is designed
        !           155: to avoid many of the the complicated problems found in general purpose
        !           156: database systems.
        !           157: 
        !           158: The assumptions are:
        !           159: 
        !           160:    - The size of the total database will initially be proportional
        !           161: 
        !           162: 
        !           163: 
        !           164: Mockapetris                                                     [Page 3]
        !           165: 
        !           166: RFC 1034             Domain Concepts and Facilities        November 1987
        !           167: 
        !           168: 
        !           169:      to the number of hosts using the system, but will eventually
        !           170:      grow to be proportional to the number of users on those hosts
        !           171:      as mailboxes and other information are added to the domain
        !           172:      system.
        !           173: 
        !           174:    - Most of the data in the system will change very slowly (e.g.,
        !           175:      mailbox bindings, host addresses), but that the system should
        !           176:      be able to deal with subsets that change more rapidly (on the
        !           177:      order of seconds or minutes).
        !           178: 
        !           179:    - The administrative boundaries used to distribute
        !           180:      responsibility for the database will usually correspond to
        !           181:      organizations that have one or more hosts.  Each organization
        !           182:      that has responsibility for a particular set of domains will
        !           183:      provide redundant name servers, either on the organization's
        !           184:      own hosts or other hosts that the organization arranges to
        !           185:      use.
        !           186: 
        !           187:    - Clients of the domain system should be able to identify
        !           188:      trusted name servers they prefer to use before accepting
        !           189:      referrals to name servers outside of this "trusted" set.
        !           190: 
        !           191:    - Access to information is more critical than instantaneous
        !           192:      updates or guarantees of consistency.  Hence the update
        !           193:      process allows updates to percolate out through the users of
        !           194:      the domain system rather than guaranteeing that all copies are
        !           195:      simultaneously updated.  When updates are unavailable due to
        !           196:      network or host failure, the usual course is to believe old
        !           197:      information while continuing efforts to update it.  The
        !           198:      general model is that copies are distributed with timeouts for
        !           199:      refreshing.  The distributor sets the timeout value and the
        !           200:      recipient of the distribution is responsible for performing
        !           201:      the refresh.  In special situations, very short intervals can
        !           202:      be specified, or the owner can prohibit copies.
        !           203: 
        !           204:    - In any system that has a distributed database, a particular
        !           205:      name server may be presented with a query that can only be
        !           206:      answered by some other server.  The two general approaches to
        !           207:      dealing with this problem are "recursive", in which the first
        !           208:      server pursues the query for the client at another server, and
        !           209:      "iterative", in which the server refers the client to another
        !           210:      server and lets the client pursue the query.  Both approaches
        !           211:      have advantages and disadvantages, but the iterative approach
        !           212:      is preferred for the datagram style of access.  The domain
        !           213:      system requires implementation of the iterative approach, but
        !           214:      allows the recursive approach as an option.
        !           215: 
        !           216: 
        !           217: 
        !           218: 
        !           219: 
        !           220: Mockapetris                                                     [Page 4]
        !           221: 
        !           222: RFC 1034             Domain Concepts and Facilities        November 1987
        !           223: 
        !           224: 
        !           225: The domain system assumes that all data originates in master files
        !           226: scattered through the hosts that use the domain system.  These master
        !           227: files are updated by local system administrators.  Master files are text
        !           228: files that are read by a local name server, and hence become available
        !           229: through the name servers to users of the domain system.  The user
        !           230: programs access name servers through standard programs called resolvers.
        !           231: 
        !           232: The standard format of master files allows them to be exchanged between
        !           233: hosts (via FTP, mail, or some other mechanism); this facility is useful
        !           234: when an organization wants a domain, but doesn't want to support a name
        !           235: server.  The organization can maintain the master files locally using a
        !           236: text editor, transfer them to a foreign host which runs a name server,
        !           237: and then arrange with the system administrator of the name server to get
        !           238: the files loaded.
        !           239: 
        !           240: Each host's name servers and resolvers are configured by a local system
        !           241: administrator [RFC-1033].  For a name server, this configuration data
        !           242: includes the identity of local master files and instructions on which
        !           243: non-local master files are to be loaded from foreign servers.  The name
        !           244: server uses the master files or copies to load its zones.  For
        !           245: resolvers, the configuration data identifies the name servers which
        !           246: should be the primary sources of information.
        !           247: 
        !           248: The domain system defines procedures for accessing the data and for
        !           249: referrals to other name servers.  The domain system also defines
        !           250: procedures for caching retrieved data and for periodic refreshing of
        !           251: data defined by the system administrator.
        !           252: 
        !           253: The system administrators provide:
        !           254: 
        !           255:    - The definition of zone boundaries.
        !           256: 
        !           257:    - Master files of data.
        !           258: 
        !           259:    - Updates to master files.
        !           260: 
        !           261:    - Statements of the refresh policies desired.
        !           262: 
        !           263: The domain system provides:
        !           264: 
        !           265:    - Standard formats for resource data.
        !           266: 
        !           267:    - Standard methods for querying the database.
        !           268: 
        !           269:    - Standard methods for name servers to refresh local data from
        !           270:      foreign name servers.
        !           271: 
        !           272: 
        !           273: 
        !           274: 
        !           275: 
        !           276: Mockapetris                                                     [Page 5]
        !           277: 
        !           278: RFC 1034             Domain Concepts and Facilities        November 1987
        !           279: 
        !           280: 
        !           281: 2.4. Elements of the DNS
        !           282: 
        !           283: The DNS has three major components:
        !           284: 
        !           285:    - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are
        !           286:      specifications for a tree structured name space and data
        !           287:      associated with the names.  Conceptually, each node and leaf
        !           288:      of the domain name space tree names a set of information, and
        !           289:      query operations are attempts to extract specific types of
        !           290:      information from a particular set.  A query names the domain
        !           291:      name of interest and describes the type of resource
        !           292:      information that is desired.  For example, the Internet
        !           293:      uses some of its domain names to identify hosts; queries for
        !           294:      address resources return Internet host addresses.
        !           295: 
        !           296:    - NAME SERVERS are server programs which hold information about
        !           297:      the domain tree's structure and set information.  A name
        !           298:      server may cache structure or set information about any part
        !           299:      of the domain tree, but in general a particular name server
        !           300:      has complete information about a subset of the domain space,
        !           301:      and pointers to other name servers that can be used to lead to
        !           302:      information from any part of the domain tree.  Name servers
        !           303:      know the parts of the domain tree for which they have complete
        !           304:      information; a name server is said to be an AUTHORITY for
        !           305:      these parts of the name space.  Authoritative information is
        !           306:      organized into units called ZONEs, and these zones can be
        !           307:      automatically distributed to the name servers which provide
        !           308:      redundant service for the data in a zone.
        !           309: 
        !           310:    - RESOLVERS are programs that extract information from name
        !           311:      servers in response to client requests.  Resolvers must be
        !           312:      able to access at least one name server and use that name
        !           313:      server's information to answer a query directly, or pursue the
        !           314:      query using referrals to other name servers.  A resolver will
        !           315:      typically be a system routine that is directly accessible to
        !           316:      user programs; hence no protocol is necessary between the
        !           317:      resolver and the user program.
        !           318: 
        !           319: These three components roughly correspond to the three layers or views
        !           320: of the domain system:
        !           321: 
        !           322:    - From the user's point of view, the domain system is accessed
        !           323:      through a simple procedure or OS call to a local resolver.
        !           324:      The domain space consists of a single tree and the user can
        !           325:      request information from any section of the tree.
        !           326: 
        !           327:    - From the resolver's point of view, the domain system is
        !           328:      composed of an unknown number of name servers.  Each name
        !           329: 
        !           330: 
        !           331: 
        !           332: Mockapetris                                                     [Page 6]
        !           333: 
        !           334: RFC 1034             Domain Concepts and Facilities        November 1987
        !           335: 
        !           336: 
        !           337:      server has one or more pieces of the whole domain tree's data,
        !           338:      but the resolver views each of these databases as essentially
        !           339:      static.
        !           340: 
        !           341:    - From a name server's point of view, the domain system consists
        !           342:      of separate sets of local information called zones.  The name
        !           343:      server has local copies of some of the zones.  The name server
        !           344:      must periodically refresh its zones from master copies in
        !           345:      local files or foreign name servers.  The name server must
        !           346:      concurrently process queries that arrive from resolvers.
        !           347: 
        !           348: In the interests of performance, implementations may couple these
        !           349: functions.  For example, a resolver on the same machine as a name server
        !           350: might share a database consisting of the the zones managed by the name
        !           351: server and the cache managed by the resolver.
        !           352: 
        !           353: 3. DOMAIN NAME SPACE and RESOURCE RECORDS
        !           354: 
        !           355: 3.1. Name space specifications and terminology
        !           356: 
        !           357: The domain name space is a tree structure.  Each node and leaf on the
        !           358: tree corresponds to a resource set (which may be empty).  The domain
        !           359: system makes no distinctions between the uses of the interior nodes and
        !           360: leaves, and this memo uses the term "node" to refer to both.
        !           361: 
        !           362: Each node has a label, which is zero to 63 octets in length.  Brother
        !           363: nodes may not have the same label, although the same label can be used
        !           364: for nodes which are not brothers.  One label is reserved, and that is
        !           365: the null (i.e., zero length) label used for the root.
        !           366: 
        !           367: The domain name of a node is the list of the labels on the path from the
        !           368: node to the root of the tree.  By convention, the labels that compose a
        !           369: domain name are printed or read left to right, from the most specific
        !           370: (lowest, farthest from the root) to the least specific (highest, closest
        !           371: to the root).
        !           372: 
        !           373: Internally, programs that manipulate domain names should represent them
        !           374: as sequences of labels, where each label is a length octet followed by
        !           375: an octet string.  Because all domain names end at the root, which has a
        !           376: null string for a label, these internal representations can use a length
        !           377: byte of zero to terminate a domain name.
        !           378: 
        !           379: By convention, domain names can be stored with arbitrary case, but
        !           380: domain name comparisons for all present domain functions are done in a
        !           381: case-insensitive manner, assuming an ASCII character set, and a high
        !           382: order zero bit.  This means that you are free to create a node with
        !           383: label "A" or a node with label "a", but not both as brothers; you could
        !           384: refer to either using "a" or "A".  When you receive a domain name or
        !           385: 
        !           386: 
        !           387: 
        !           388: Mockapetris                                                     [Page 7]
        !           389: 
        !           390: RFC 1034             Domain Concepts and Facilities        November 1987
        !           391: 
        !           392: 
        !           393: label, you should preserve its case.  The rationale for this choice is
        !           394: that we may someday need to add full binary domain names for new
        !           395: services; existing services would not be changed.
        !           396: 
        !           397: When a user needs to type a domain name, the length of each label is
        !           398: omitted and the labels are separated by dots (".").  Since a complete
        !           399: domain name ends with the root label, this leads to a printed form which
        !           400: ends in a dot.  We use this property to distinguish between:
        !           401: 
        !           402:    - a character string which represents a complete domain name
        !           403:      (often called "absolute").  For example, "poneria.ISI.EDU."
        !           404: 
        !           405:    - a character string that represents the starting labels of a
        !           406:      domain name which is incomplete, and should be completed by
        !           407:      local software using knowledge of the local domain (often
        !           408:      called "relative").  For example, "poneria" used in the
        !           409:      ISI.EDU domain.
        !           410: 
        !           411: Relative names are either taken relative to a well known origin, or to a
        !           412: list of domains used as a search list.  Relative names appear mostly at
        !           413: the user interface, where their interpretation varies from
        !           414: implementation to implementation, and in master files, where they are
        !           415: relative to a single origin domain name.  The most common interpretation
        !           416: uses the root "." as either the single origin or as one of the members
        !           417: of the search list, so a multi-label relative name is often one where
        !           418: the trailing dot has been omitted to save typing.
        !           419: 
        !           420: To simplify implementations, the total number of octets that represent a
        !           421: domain name (i.e., the sum of all label octets and label lengths) is
        !           422: limited to 255.
        !           423: 
        !           424: A domain is identified by a domain name, and consists of that part of
        !           425: the domain name space that is at or below the domain name which
        !           426: specifies the domain.  A domain is a subdomain of another domain if it
        !           427: is contained within that domain.  This relationship can be tested by
        !           428: seeing if the subdomain's name ends with the containing domain's name.
        !           429: For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".
        !           430: 
        !           431: 3.2. Administrative guidelines on use
        !           432: 
        !           433: As a matter of policy, the DNS technical specifications do not mandate a
        !           434: particular tree structure or rules for selecting labels; its goal is to
        !           435: be as general as possible, so that it can be used to build arbitrary
        !           436: applications.  In particular, the system was designed so that the name
        !           437: space did not have to be organized along the lines of network
        !           438: boundaries, name servers, etc.  The rationale for this is not that the
        !           439: name space should have no implied semantics, but rather that the choice
        !           440: of implied semantics should be left open to be used for the problem at
        !           441: 
        !           442: 
        !           443: 
        !           444: Mockapetris                                                     [Page 8]
        !           445: 
        !           446: RFC 1034             Domain Concepts and Facilities        November 1987
        !           447: 
        !           448: 
        !           449: hand, and that different parts of the tree can have different implied
        !           450: semantics.  For example, the IN-ADDR.ARPA domain is organized and
        !           451: distributed by network and host address because its role is to translate
        !           452: from network or host numbers to names; NetBIOS domains [RFC-1001, RFC-
        !           453: 1002] are flat because that is appropriate for that application.
        !           454: 
        !           455: However, there are some guidelines that apply to the "normal" parts of
        !           456: the name space used for hosts, mailboxes, etc., that will make the name
        !           457: space more uniform, provide for growth, and minimize problems as
        !           458: software is converted from the older host table.  The political
        !           459: decisions about the top levels of the tree originated in RFC-920.
        !           460: Current policy for the top levels is discussed in [RFC-1032].  MILNET
        !           461: conversion issues are covered in [RFC-1031].
        !           462: 
        !           463: Lower domains which will eventually be broken into multiple zones should
        !           464: provide branching at the top of the domain so that the eventual
        !           465: decomposition can be done without renaming.  Node labels which use
        !           466: special characters, leading digits, etc., are likely to break older
        !           467: software which depends on more restrictive choices.
        !           468: 
        !           469: 3.3. Technical guidelines on use
        !           470: 
        !           471: Before the DNS can be used to hold naming information for some kind of
        !           472: object, two needs must be met:
        !           473: 
        !           474:    - A convention for mapping between object names and domain
        !           475:      names.  This describes how information about an object is
        !           476:      accessed.
        !           477: 
        !           478:    - RR types and data formats for describing the object.
        !           479: 
        !           480: These rules can be quite simple or fairly complex.  Very often, the
        !           481: designer must take into account existing formats and plan for upward
        !           482: compatibility for existing usage.  Multiple mappings or levels of
        !           483: mapping may be required.
        !           484: 
        !           485: For hosts, the mapping depends on the existing syntax for host names
        !           486: which is a subset of the usual text representation for domain names,
        !           487: together with RR formats for describing host addresses, etc.  Because we
        !           488: need a reliable inverse mapping from address to host name, a special
        !           489: mapping for addresses into the IN-ADDR.ARPA domain is also defined.
        !           490: 
        !           491: For mailboxes, the mapping is slightly more complex.  The usual mail
        !           492: address <local-part>@<mail-domain> is mapped into a domain name by
        !           493: converting <local-part> into a single label (regardles of dots it
        !           494: contains), converting <mail-domain> into a domain name using the usual
        !           495: text format for domain names (dots denote label breaks), and
        !           496: concatenating the two to form a single domain name.  Thus the mailbox
        !           497: 
        !           498: 
        !           499: 
        !           500: Mockapetris                                                     [Page 9]
        !           501: 
        !           502: RFC 1034             Domain Concepts and Facilities        November 1987
        !           503: 
        !           504: 
        !           505: [email protected] is represented as a domain name by
        !           506: HOSTMASTER.SRI-NIC.ARPA.  An appreciation for the reasons behind this
        !           507: design also must take into account the scheme for mail exchanges [RFC-
        !           508: 974].
        !           509: 
        !           510: The typical user is not concerned with defining these rules, but should
        !           511: understand that they usually are the result of numerous compromises
        !           512: between desires for upward compatibility with old usage, interactions
        !           513: between different object definitions, and the inevitable urge to add new
        !           514: features when defining the rules.  The way the DNS is used to support
        !           515: some object is often more crucial than the restrictions inherent in the
        !           516: DNS.
        !           517: 
        !           518: 3.4. Example name space
        !           519: 
        !           520: The following figure shows a part of the current domain name space, and
        !           521: is used in many examples in this RFC.  Note that the tree is a very
        !           522: small subset of the actual name space.
        !           523: 
        !           524:                                    |
        !           525:                                    |
        !           526:              +---------------------+------------------+
        !           527:              |                     |                  |
        !           528:             MIL                   EDU                ARPA
        !           529:              |                     |                  |
        !           530:              |                     |                  |
        !           531:        +-----+-----+               |     +------+-----+-----+
        !           532:        |     |     |               |     |      |           |
        !           533:       BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
        !           534:                                    |
        !           535:        +--------+------------------+---------------+--------+
        !           536:        |        |                  |               |        |
        !           537:       UCI      MIT                 |              UDEL     YALE
        !           538:                 |                 ISI
        !           539:                 |                  |
        !           540:             +---+---+              |
        !           541:             |       |              |
        !           542:            LCS  ACHILLES  +--+-----+-----+--------+
        !           543:             |             |  |     |     |        |
        !           544:             XX            A  C   VAXA  VENERA Mockapetris
        !           545: 
        !           546: In this example, the root domain has three immediate subdomains: MIL,
        !           547: EDU, and ARPA.  The LCS.MIT.EDU domain has one immediate subdomain named
        !           548: XX.LCS.MIT.EDU.  All of the leaves are also domains.
        !           549: 
        !           550: 3.5. Preferred name syntax
        !           551: 
        !           552: The DNS specifications attempt to be as general as possible in the rules
        !           553: 
        !           554: 
        !           555: 
        !           556: Mockapetris                                                    [Page 10]
        !           557: 
        !           558: RFC 1034             Domain Concepts and Facilities        November 1987
        !           559: 
        !           560: 
        !           561: for constructing domain names.  The idea is that the name of any
        !           562: existing object can be expressed as a domain name with minimal changes.
        !           563: However, when assigning a domain name for an object, the prudent user
        !           564: will select a name which satisfies both the rules of the domain system
        !           565: and any existing rules for the object, whether these rules are published
        !           566: or implied by existing programs.
        !           567: 
        !           568: For example, when naming a mail domain, the user should satisfy both the
        !           569: rules of this memo and those in RFC-822.  When creating a new host name,
        !           570: the old rules for HOSTS.TXT should be followed.  This avoids problems
        !           571: when old software is converted to use domain names.
        !           572: 
        !           573: The following syntax will result in fewer problems with many
        !           574: applications that use domain names (e.g., mail, TELNET).
        !           575: 
        !           576: <domain> ::= <subdomain> | " "
        !           577: 
        !           578: <subdomain> ::= <label> | <subdomain> "." <label>
        !           579: 
        !           580: <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
        !           581: 
        !           582: <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
        !           583: 
        !           584: <let-dig-hyp> ::= <let-dig> | "-"
        !           585: 
        !           586: <let-dig> ::= <letter> | <digit>
        !           587: 
        !           588: <letter> ::= any one of the 52 alphabetic characters A through Z in
        !           589: upper case and a through z in lower case
        !           590: 
        !           591: <digit> ::= any one of the ten digits 0 through 9
        !           592: 
        !           593: Note that while upper and lower case letters are allowed in domain
        !           594: names, no significance is attached to the case.  That is, two names with
        !           595: the same spelling but different case are to be treated as if identical.
        !           596: 
        !           597: The labels must follow the rules for ARPANET host names.  They must
        !           598: start with a letter, end with a letter or digit, and have as interior
        !           599: characters only letters, digits, and hyphen.  There are also some
        !           600: restrictions on the length.  Labels must be 63 characters or less.
        !           601: 
        !           602: For example, the following strings identify hosts in the Internet:
        !           603: 
        !           604: A.ISI.EDU  XX.LCS.MIT.EDU  SRI-NIC.ARPA
        !           605: 
        !           606: 3.6. Resource Records
        !           607: 
        !           608: A domain name identifies a node.  Each node has a set of resource
        !           609: 
        !           610: 
        !           611: 
        !           612: Mockapetris                                                    [Page 11]
        !           613: 
        !           614: RFC 1034             Domain Concepts and Facilities        November 1987
        !           615: 
        !           616: 
        !           617: information, which may be empty.  The set of resource information
        !           618: associated with a particular name is composed of separate resource
        !           619: records (RRs).  The order of RRs in a set is not significant, and need
        !           620: not be preserved by name servers, resolvers, or other parts of the DNS.
        !           621: 
        !           622: When we talk about a specific RR, we assume it has the following:
        !           623: 
        !           624: owner           which is the domain name where the RR is found.
        !           625: 
        !           626: type            which is an encoded 16 bit value that specifies the type
        !           627:                 of the resource in this resource record.  Types refer to
        !           628:                 abstract resources.
        !           629: 
        !           630:                 This memo uses the following types:
        !           631: 
        !           632:                 A               a host address
        !           633: 
        !           634:                 CNAME           identifies the canonical name of an
        !           635:                                 alias
        !           636: 
        !           637:                 HINFO           identifies the CPU and OS used by a host
        !           638: 
        !           639:                 MX              identifies a mail exchange for the
        !           640:                                 domain.  See [RFC-974 for details.
        !           641: 
        !           642:                 NS
        !           643:                 the authoritative name server for the domain
        !           644: 
        !           645:                 PTR
        !           646:                 a pointer to another part of the domain name space
        !           647: 
        !           648:                 SOA
        !           649:                 identifies the start of a zone of authority]
        !           650: 
        !           651: class           which is an encoded 16 bit value which identifies a
        !           652:                 protocol family or instance of a protocol.
        !           653: 
        !           654:                 This memo uses the following classes:
        !           655: 
        !           656:                 IN              the Internet system
        !           657: 
        !           658:                 CH              the Chaos system
        !           659: 
        !           660: TTL             which is the time to live of the RR.  This field is a 32
        !           661:                 bit integer in units of seconds, an is primarily used by
        !           662:                 resolvers when they cache RRs.  The TTL describes how
        !           663:                 long a RR can be cached before it should be discarded.
        !           664: 
        !           665: 
        !           666: 
        !           667: 
        !           668: Mockapetris                                                    [Page 12]
        !           669: 
        !           670: RFC 1034             Domain Concepts and Facilities        November 1987
        !           671: 
        !           672: 
        !           673: RDATA           which is the type and sometimes class dependent data
        !           674:                 which describes the resource:
        !           675: 
        !           676:                 A               For the IN class, a 32 bit IP address
        !           677: 
        !           678:                                 For the CH class, a domain name followed
        !           679:                                 by a 16 bit octal Chaos address.
        !           680: 
        !           681:                 CNAME           a domain name.
        !           682: 
        !           683:                 MX              a 16 bit preference value (lower is
        !           684:                                 better) followed by a host name willing
        !           685:                                 to act as a mail exchange for the owner
        !           686:                                 domain.
        !           687: 
        !           688:                 NS              a host name.
        !           689: 
        !           690:                 PTR             a domain name.
        !           691: 
        !           692:                 SOA             several fields.
        !           693: 
        !           694: The owner name is often implicit, rather than forming an integral part
        !           695: of the RR.  For example, many name servers internally form tree or hash
        !           696: structures for the name space, and chain RRs off nodes.  The remaining
        !           697: RR parts are the fixed header (type, class, TTL) which is consistent for
        !           698: all RRs, and a variable part (RDATA) that fits the needs of the resource
        !           699: being described.
        !           700: 
        !           701: The meaning of the TTL field is a time limit on how long an RR can be
        !           702: kept in a cache.  This limit does not apply to authoritative data in
        !           703: zones; it is also timed out, but by the refreshing policies for the
        !           704: zone.  The TTL is assigned by the administrator for the zone where the
        !           705: data originates.  While short TTLs can be used to minimize caching, and
        !           706: a zero TTL prohibits caching, the realities of Internet performance
        !           707: suggest that these times should be on the order of days for the typical
        !           708: host.  If a change can be anticipated, the TTL can be reduced prior to
        !           709: the change to minimize inconsistency during the change, and then
        !           710: increased back to its former value following the change.
        !           711: 
        !           712: The data in the RDATA section of RRs is carried as a combination of
        !           713: binary strings and domain names.  The domain names are frequently used
        !           714: as "pointers" to other data in the DNS.
        !           715: 
        !           716: 3.6.1. Textual expression of RRs
        !           717: 
        !           718: RRs are represented in binary form in the packets of the DNS protocol,
        !           719: and are usually represented in highly encoded form when stored in a name
        !           720: server or resolver.  In this memo, we adopt a style similar to that used
        !           721: 
        !           722: 
        !           723: 
        !           724: Mockapetris                                                    [Page 13]
        !           725: 
        !           726: RFC 1034             Domain Concepts and Facilities        November 1987
        !           727: 
        !           728: 
        !           729: in master files in order to show the contents of RRs.  In this format,
        !           730: most RRs are shown on a single line, although continuation lines are
        !           731: possible using parentheses.
        !           732: 
        !           733: The start of the line gives the owner of the RR.  If a line begins with
        !           734: a blank, then the owner is assumed to be the same as that of the
        !           735: previous RR.  Blank lines are often included for readability.
        !           736: 
        !           737: Following the owner, we list the TTL, type, and class of the RR.  Class
        !           738: and type use the mnemonics defined above, and TTL is an integer before
        !           739: the type field.  In order to avoid ambiguity in parsing, type and class
        !           740: mnemonics are disjoint, TTLs are integers, and the type mnemonic is
        !           741: always last. The IN class and TTL values are often omitted from examples
        !           742: in the interests of clarity.
        !           743: 
        !           744: The resource data or RDATA section of the RR are given using knowledge
        !           745: of the typical representation for the data.
        !           746: 
        !           747: For example, we might show the RRs carried in a message as:
        !           748: 
        !           749:     ISI.EDU.        MX      10 VENERA.ISI.EDU.
        !           750:                     MX      10 VAXA.ISI.EDU.
        !           751:     VENERA.ISI.EDU. A       128.9.0.32
        !           752:                     A       10.1.0.52
        !           753:     VAXA.ISI.EDU.   A       10.2.0.27
        !           754:                     A       128.9.0.33
        !           755: 
        !           756: The MX RRs have an RDATA section which consists of a 16 bit number
        !           757: followed by a domain name.  The address RRs use a standard IP address
        !           758: format to contain a 32 bit internet address.
        !           759: 
        !           760: This example shows six RRs, with two RRs at each of three domain names.
        !           761: 
        !           762: Similarly we might see:
        !           763: 
        !           764:     XX.LCS.MIT.EDU. IN      A       10.0.0.44
        !           765:                     CH      A       MIT.EDU. 2420
        !           766: 
        !           767: This example shows two addresses for XX.LCS.MIT.EDU, each of a different
        !           768: class.
        !           769: 
        !           770: 3.6.2. Aliases and canonical names
        !           771: 
        !           772: In existing systems, hosts and other resources often have several names
        !           773: that identify the same resource.  For example, the names C.ISI.EDU and
        !           774: USC-ISIC.ARPA both identify the same host.  Similarly, in the case of
        !           775: mailboxes, many organizations provide many names that actually go to the
        !           776: same mailbox; for example [email protected], [email protected],
        !           777: 
        !           778: 
        !           779: 
        !           780: Mockapetris                                                    [Page 14]
        !           781: 
        !           782: RFC 1034             Domain Concepts and Facilities        November 1987
        !           783: 
        !           784: 
        !           785: and [email protected] all go to the same mailbox (although the mechanism
        !           786: behind this is somewhat complicated).
        !           787: 
        !           788: Most of these systems have a notion that one of the equivalent set of
        !           789: names is the canonical or primary name and all others are aliases.
        !           790: 
        !           791: The domain system provides such a feature using the canonical name
        !           792: (CNAME) RR.  A CNAME RR identifies its owner name as an alias, and
        !           793: specifies the corresponding canonical name in the RDATA section of the
        !           794: RR.  If a CNAME RR is present at a node, no other data should be
        !           795: present; this ensures that the data for a canonical name and its aliases
        !           796: cannot be different.  This rule also insures that a cached CNAME can be
        !           797: used without checking with an authoritative server for other RR types.
        !           798: 
        !           799: CNAME RRs cause special action in DNS software.  When a name server
        !           800: fails to find a desired RR in the resource set associated with the
        !           801: domain name, it checks to see if the resource set consists of a CNAME
        !           802: record with a matching class.  If so, the name server includes the CNAME
        !           803: record in the response and restarts the query at the domain name
        !           804: specified in the data field of the CNAME record.  The one exception to
        !           805: this rule is that queries which match the CNAME type are not restarted.
        !           806: 
        !           807: For example, suppose a name server was processing a query with for USC-
        !           808: ISIC.ARPA, asking for type A information, and had the following resource
        !           809: records:
        !           810: 
        !           811:     USC-ISIC.ARPA   IN      CNAME   C.ISI.EDU
        !           812: 
        !           813:     C.ISI.EDU       IN      A       10.0.0.52
        !           814: 
        !           815: Both of these RRs would be returned in the response to the type A query,
        !           816: while a type CNAME or * query should return just the CNAME.
        !           817: 
        !           818: Domain names in RRs which point at another name should always point at
        !           819: the primary name and not the alias.  This avoids extra indirections in
        !           820: accessing information.  For example, the address to name RR for the
        !           821: above host should be:
        !           822: 
        !           823:     52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU
        !           824: 
        !           825: rather than pointing at USC-ISIC.ARPA.  Of course, by the robustness
        !           826: principle, domain software should not fail when presented with CNAME
        !           827: chains or loops; CNAME chains should be followed and CNAME loops
        !           828: signalled as an error.
        !           829: 
        !           830: 3.7. Queries
        !           831: 
        !           832: Queries are messages which may be sent to a name server to provoke a
        !           833: 
        !           834: 
        !           835: 
        !           836: Mockapetris                                                    [Page 15]
        !           837: 
        !           838: RFC 1034             Domain Concepts and Facilities        November 1987
        !           839: 
        !           840: 
        !           841: response.  In the Internet, queries are carried in UDP datagrams or over
        !           842: TCP connections.  The response by the name server either answers the
        !           843: question posed in the query, refers the requester to another set of name
        !           844: servers, or signals some error condition.
        !           845: 
        !           846: In general, the user does not generate queries directly, but instead
        !           847: makes a request to a resolver which in turn sends one or more queries to
        !           848: name servers and deals with the error conditions and referrals that may
        !           849: result.  Of course, the possible questions which can be asked in a query
        !           850: does shape the kind of service a resolver can provide.
        !           851: 
        !           852: DNS queries and responses are carried in a standard message format.  The
        !           853: message format has a header containing a number of fixed fields which
        !           854: are always present, and four sections which carry query parameters and
        !           855: RRs.
        !           856: 
        !           857: The most important field in the header is a four bit field called an
        !           858: opcode which separates different queries.  Of the possible 16 values,
        !           859: one (standard query) is part of the official protocol, two (inverse
        !           860: query and status query) are options, one (completion) is obsolete, and
        !           861: the rest are unassigned.
        !           862: 
        !           863: The four sections are:
        !           864: 
        !           865: Question        Carries the query name and other query parameters.
        !           866: 
        !           867: Answer          Carries RRs which directly answer the query.
        !           868: 
        !           869: Authority       Carries RRs which describe other authoritative servers.
        !           870:                 May optionally carry the SOA RR for the authoritative
        !           871:                 data in the answer section.
        !           872: 
        !           873: Additional      Carries RRs which may be helpful in using the RRs in the
        !           874:                 other sections.
        !           875: 
        !           876: Note that the content, but not the format, of these sections varies with
        !           877: header opcode.
        !           878: 
        !           879: 3.7.1. Standard queries
        !           880: 
        !           881: A standard query specifies a target domain name (QNAME), query type
        !           882: (QTYPE), and query class (QCLASS) and asks for RRs which match.  This
        !           883: type of query makes up such a vast majority of DNS queries that we use
        !           884: the term "query" to mean standard query unless otherwise specified.  The
        !           885: QTYPE and QCLASS fields are each 16 bits long, and are a superset of
        !           886: defined types and classes.
        !           887: 
        !           888: 
        !           889: 
        !           890: 
        !           891: 
        !           892: Mockapetris                                                    [Page 16]
        !           893: 
        !           894: RFC 1034             Domain Concepts and Facilities        November 1987
        !           895: 
        !           896: 
        !           897: The QTYPE field may contain:
        !           898: 
        !           899: <any type>      matches just that type. (e.g., A, PTR).
        !           900: 
        !           901: AXFR            special zone transfer QTYPE.
        !           902: 
        !           903: MAILB           matches all mail box related RRs (e.g. MB and MG).
        !           904: 
        !           905: *               matches all RR types.
        !           906: 
        !           907: The QCLASS field may contain:
        !           908: 
        !           909: <any class>     matches just that class (e.g., IN, CH).
        !           910: 
        !           911: *               matches aLL RR classes.
        !           912: 
        !           913: Using the query domain name, QTYPE, and QCLASS, the name server looks
        !           914: for matching RRs.  In addition to relevant records, the name server may
        !           915: return RRs that point toward a name server that has the desired
        !           916: information or RRs that are expected to be useful in interpreting the
        !           917: relevant RRs.  For example, a name server that doesn't have the
        !           918: requested information may know a name server that does; a name server
        !           919: that returns a domain name in a relevant RR may also return the RR that
        !           920: binds that domain name to an address.
        !           921: 
        !           922: For example, a mailer tying to send mail to [email protected] might
        !           923: ask the resolver for mail information about ISI.EDU, resulting in a
        !           924: query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN.  The response's answer
        !           925: section would be:
        !           926: 
        !           927:     ISI.EDU.        MX      10 VENERA.ISI.EDU.
        !           928:                     MX      10 VAXA.ISI.EDU.
        !           929: 
        !           930: while the additional section might be:
        !           931: 
        !           932:     VAXA.ISI.EDU.   A       10.2.0.27
        !           933:                     A       128.9.0.33
        !           934:     VENERA.ISI.EDU. A       10.1.0.52
        !           935:                     A       128.9.0.32
        !           936: 
        !           937: Because the server assumes that if the requester wants mail exchange
        !           938: information, it will probably want the addresses of the mail exchanges
        !           939: soon afterward.
        !           940: 
        !           941: Note that the QCLASS=* construct requires special interpretation
        !           942: regarding authority.  Since a particular name server may not know all of
        !           943: the classes available in the domain system, it can never know if it is
        !           944: authoritative for all classes.  Hence responses to QCLASS=* queries can
        !           945: 
        !           946: 
        !           947: 
        !           948: Mockapetris                                                    [Page 17]
        !           949: 
        !           950: RFC 1034             Domain Concepts and Facilities        November 1987
        !           951: 
        !           952: 
        !           953: never be authoritative.
        !           954: 
        !           955: 3.7.2. Inverse queries (Optional)
        !           956: 
        !           957: Name servers may also support inverse queries that map a particular
        !           958: resource to a domain name or domain names that have that resource.  For
        !           959: example, while a standard query might map a domain name to a SOA RR, the
        !           960: corresponding inverse query might map the SOA RR back to the domain
        !           961: name.
        !           962: 
        !           963: Implementation of this service is optional in a name server, but all
        !           964: name servers must at least be able to understand an inverse query
        !           965: message and return a not-implemented error response.
        !           966: 
        !           967: The domain system cannot guarantee the completeness or uniqueness of
        !           968: inverse queries because the domain system is organized by domain name
        !           969: rather than by host address or any other resource type.  Inverse queries
        !           970: are primarily useful for debugging and database maintenance activities.
        !           971: 
        !           972: Inverse queries may not return the proper TTL, and do not indicate cases
        !           973: where the identified RR is one of a set (for example, one address for a
        !           974: host having multiple addresses).  Therefore, the RRs returned in inverse
        !           975: queries should never be cached.
        !           976: 
        !           977: Inverse queries are NOT an acceptable method for mapping host addresses
        !           978: to host names; use the IN-ADDR.ARPA domain instead.
        !           979: 
        !           980: A detailed discussion of inverse queries is contained in [RFC-1035].
        !           981: 
        !           982: 3.8. Status queries (Experimental)
        !           983: 
        !           984: To be defined.
        !           985: 
        !           986: 3.9. Completion queries (Obsolete)
        !           987: 
        !           988: The optional completion services described in RFCs 882 and 883 have been
        !           989: deleted.  Redesigned services may become available in the future, or the
        !           990: opcodes may be reclaimed for other use.
        !           991: 
        !           992: 4. NAME SERVERS
        !           993: 
        !           994: 4.1. Introduction
        !           995: 
        !           996: Name servers are the repositories of information that make up the domain
        !           997: database.  The database is divided up into sections called zones, which
        !           998: are distributed among the name servers.  While name servers can have
        !           999: several optional functions and sources of data, the essential task of a
        !          1000: name server is to answer queries using data in its zones.  By design,
        !          1001: 
        !          1002: 
        !          1003: 
        !          1004: Mockapetris                                                    [Page 18]
        !          1005: 
        !          1006: RFC 1034             Domain Concepts and Facilities        November 1987
        !          1007: 
        !          1008: 
        !          1009: name servers can answer queries in a simple manner; the response can
        !          1010: always be generated using only local data, and either contains the
        !          1011: answer to the question or a referral to other name servers "closer" to
        !          1012: the desired information.
        !          1013: 
        !          1014: A given zone will be available from several name servers to insure its
        !          1015: availability in spite of host or communication link failure.  By
        !          1016: administrative fiat, we require every zone to be available on at least
        !          1017: two servers, and many zones have more redundancy than that.
        !          1018: 
        !          1019: A given name server will typically support one or more zones, but this
        !          1020: gives it authoritative information about only a small section of the
        !          1021: domain tree.  It may also have some cached non-authoritative data about
        !          1022: other parts of the tree.  The name server marks its responses to queries
        !          1023: so that the requester can tell whether the response comes from
        !          1024: authoritative data or not.
        !          1025: 
        !          1026: 4.2. How the database is divided into zones
        !          1027: 
        !          1028: The domain database is partitioned in two ways: by class, and by "cuts"
        !          1029: made in the name space between nodes.
        !          1030: 
        !          1031: The class partition is simple.  The database for any class is organized,
        !          1032: delegated, and maintained separately from all other classes.  Since, by
        !          1033: convention, the name spaces are the same for all classes, the separate
        !          1034: classes can be thought of as an array of parallel namespace trees.  Note
        !          1035: that the data attached to nodes will be different for these different
        !          1036: parallel classes.  The most common reasons for creating a new class are
        !          1037: the necessity for a new data format for existing types or a desire for a
        !          1038: separately managed version of the existing name space.
        !          1039: 
        !          1040: Within a class, "cuts" in the name space can be made between any two
        !          1041: adjacent nodes.  After all cuts are made, each group of connected name
        !          1042: space is a separate zone.  The zone is said to be authoritative for all
        !          1043: names in the connected region.  Note that the "cuts" in the name space
        !          1044: may be in different places for different classes, the name servers may
        !          1045: be different, etc.
        !          1046: 
        !          1047: These rules mean that every zone has at least one node, and hence domain
        !          1048: name, for which it is authoritative, and all of the nodes in a
        !          1049: particular zone are connected.  Given, the tree structure, every zone
        !          1050: has a highest node which is closer to the root than any other node in
        !          1051: the zone.  The name of this node is often used to identify the zone.
        !          1052: 
        !          1053: It would be possible, though not particularly useful, to partition the
        !          1054: name space so that each domain name was in a separate zone or so that
        !          1055: all nodes were in a single zone.  Instead, the database is partitioned
        !          1056: at points where a particular organization wants to take over control of
        !          1057: 
        !          1058: 
        !          1059: 
        !          1060: Mockapetris                                                    [Page 19]
        !          1061: 
        !          1062: RFC 1034             Domain Concepts and Facilities        November 1987
        !          1063: 
        !          1064: 
        !          1065: a subtree.  Once an organization controls its own zone it can
        !          1066: unilaterally change the data in the zone, grow new tree sections
        !          1067: connected to the zone, delete existing nodes, or delegate new subzones
        !          1068: under its zone.
        !          1069: 
        !          1070: If the organization has substructure, it may want to make further
        !          1071: internal partitions to achieve nested delegations of name space control.
        !          1072: In some cases, such divisions are made purely to make database
        !          1073: maintenance more convenient.
        !          1074: 
        !          1075: 4.2.1. Technical considerations
        !          1076: 
        !          1077: The data that describes a zone has four major parts:
        !          1078: 
        !          1079:    - Authoritative data for all nodes within the zone.
        !          1080: 
        !          1081:    - Data that defines the top node of the zone (can be thought of
        !          1082:      as part of the authoritative data).
        !          1083: 
        !          1084:    - Data that describes delegated subzones, i.e., cuts around the
        !          1085:      bottom of the zone.
        !          1086: 
        !          1087:    - Data that allows access to name servers for subzones
        !          1088:      (sometimes called "glue" data).
        !          1089: 
        !          1090: All of this data is expressed in the form of RRs, so a zone can be
        !          1091: completely described in terms of a set of RRs.  Whole zones can be
        !          1092: transferred between name servers by transferring the RRs, either carried
        !          1093: in a series of messages or by FTPing a master file which is a textual
        !          1094: representation.
        !          1095: 
        !          1096: The authoritative data for a zone is simply all of the RRs attached to
        !          1097: all of the nodes from the top node of the zone down to leaf nodes or
        !          1098: nodes above cuts around the bottom edge of the zone.
        !          1099: 
        !          1100: Though logically part of the authoritative data, the RRs that describe
        !          1101: the top node of the zone are especially important to the zone's
        !          1102: management.  These RRs are of two types: name server RRs that list, one
        !          1103: per RR, all of the servers for the zone, and a single SOA RR that
        !          1104: describes zone management parameters.
        !          1105: 
        !          1106: The RRs that describe cuts around the bottom of the zone are NS RRs that
        !          1107: name the servers for the subzones.  Since the cuts are between nodes,
        !          1108: these RRs are NOT part of the authoritative data of the zone, and should
        !          1109: be exactly the same as the corresponding RRs in the top node of the
        !          1110: subzone.  Since name servers are always associated with zone boundaries,
        !          1111: NS RRs are only found at nodes which are the top node of some zone.  In
        !          1112: the data that makes up a zone, NS RRs are found at the top node of the
        !          1113: 
        !          1114: 
        !          1115: 
        !          1116: Mockapetris                                                    [Page 20]
        !          1117: 
        !          1118: RFC 1034             Domain Concepts and Facilities        November 1987
        !          1119: 
        !          1120: 
        !          1121: zone (and are authoritative) and at cuts around the bottom of the zone
        !          1122: (where they are not authoritative), but never in between.
        !          1123: 
        !          1124: One of the goals of the zone structure is that any zone have all the
        !          1125: data required to set up communications with the name servers for any
        !          1126: subzones.  That is, parent zones have all the information needed to
        !          1127: access servers for their children zones.  The NS RRs that name the
        !          1128: servers for subzones are often not enough for this task since they name
        !          1129: the servers, but do not give their addresses.  In particular, if the
        !          1130: name of the name server is itself in the subzone, we could be faced with
        !          1131: the situation where the NS RRs tell us that in order to learn a name
        !          1132: server's address, we should contact the server using the address we wish
        !          1133: to learn.  To fix this problem, a zone contains "glue" RRs which are not
        !          1134: part of the authoritative data, and are address RRs for the servers.
        !          1135: These RRs are only necessary if the name server's name is "below" the
        !          1136: cut, and are only used as part of a referral response.
        !          1137: 
        !          1138: 4.2.2. Administrative considerations
        !          1139: 
        !          1140: When some organization wants to control its own domain, the first step
        !          1141: is to identify the proper parent zone, and get the parent zone's owners
        !          1142: to agree to the delegation of control.  While there are no particular
        !          1143: technical constraints dealing with where in the tree this can be done,
        !          1144: there are some administrative groupings discussed in [RFC-1032] which
        !          1145: deal with top level organization, and middle level zones are free to
        !          1146: create their own rules.  For example, one university might choose to use
        !          1147: a single zone, while another might choose to organize by subzones
        !          1148: dedicated to individual departments or schools.  [RFC-1033] catalogs
        !          1149: available DNS software an discusses administration procedures.
        !          1150: 
        !          1151: Once the proper name for the new subzone is selected, the new owners
        !          1152: should be required to demonstrate redundant name server support.  Note
        !          1153: that there is no requirement that the servers for a zone reside in a
        !          1154: host which has a name in that domain.  In many cases, a zone will be
        !          1155: more accessible to the internet at large if its servers are widely
        !          1156: distributed rather than being within the physical facilities controlled
        !          1157: by the same organization that manages the zone.  For example, in the
        !          1158: current DNS, one of the name servers for the United Kingdom, or UK
        !          1159: domain, is found in the US.  This allows US hosts to get UK data without
        !          1160: using limited transatlantic bandwidth.
        !          1161: 
        !          1162: As the last installation step, the delegation NS RRs and glue RRs
        !          1163: necessary to make the delegation effective should be added to the parent
        !          1164: zone.  The administrators of both zones should insure that the NS and
        !          1165: glue RRs which mark both sides of the cut are consistent and remain so.
        !          1166: 
        !          1167: 4.3. Name server internals
        !          1168: 
        !          1169: 
        !          1170: 
        !          1171: 
        !          1172: Mockapetris                                                    [Page 21]
        !          1173: 
        !          1174: RFC 1034             Domain Concepts and Facilities        November 1987
        !          1175: 
        !          1176: 
        !          1177: 4.3.1. Queries and responses
        !          1178: 
        !          1179: The principal activity of name servers is to answer standard queries.
        !          1180: Both the query and its response are carried in a standard message format
        !          1181: which is described in [RFC-1035].  The query contains a QTYPE, QCLASS,
        !          1182: and QNAME, which describe the types and classes of desired information
        !          1183: and the name of interest.
        !          1184: 
        !          1185: The way that the name server answers the query depends upon whether it
        !          1186: is operating in recursive mode or not:
        !          1187: 
        !          1188:    - The simplest mode for the server is non-recursive, since it
        !          1189:      can answer queries using only local information: the response
        !          1190:      contains an error, the answer, or a referral to some other
        !          1191:      server "closer" to the answer.  All name servers must
        !          1192:      implement non-recursive queries.
        !          1193: 
        !          1194:    - The simplest mode for the client is recursive, since in this
        !          1195:      mode the name server acts in the role of a resolver and
        !          1196:      returns either an error or the answer, but never referrals.
        !          1197:      This service is optional in a name server, and the name server
        !          1198:      may also choose to restrict the clients which can use
        !          1199:      recursive mode.
        !          1200: 
        !          1201: Recursive service is helpful in several situations:
        !          1202: 
        !          1203:    - a relatively simple requester that lacks the ability to use
        !          1204:      anything other than a direct answer to the question.
        !          1205: 
        !          1206:    - a request that needs to cross protocol or other boundaries and
        !          1207:      can be sent to a server which can act as intermediary.
        !          1208: 
        !          1209:    - a network where we want to concentrate the cache rather than
        !          1210:      having a separate cache for each client.
        !          1211: 
        !          1212: Non-recursive service is appropriate if the requester is capable of
        !          1213: pursuing referrals and interested in information which will aid future
        !          1214: requests.
        !          1215: 
        !          1216: The use of recursive mode is limited to cases where both the client and
        !          1217: the name server agree to its use.  The agreement is negotiated through
        !          1218: the use of two bits in query and response messages:
        !          1219: 
        !          1220:    - The recursion available, or RA bit, is set or cleared by a
        !          1221:      name server in all responses.  The bit is true if the name
        !          1222:      server is willing to provide recursive service for the client,
        !          1223:      regardless of whether the client requested recursive service.
        !          1224:      That is, RA signals availability rather than use.
        !          1225: 
        !          1226: 
        !          1227: 
        !          1228: Mockapetris                                                    [Page 22]
        !          1229: 
        !          1230: RFC 1034             Domain Concepts and Facilities        November 1987
        !          1231: 
        !          1232: 
        !          1233:    - Queries contain a bit called recursion desired or RD.  This
        !          1234:      bit specifies specifies whether the requester wants recursive
        !          1235:      service for this query.  Clients may request recursive service
        !          1236:      from any name server, though they should depend upon receiving
        !          1237:      it only from servers which have previously sent an RA, or
        !          1238:      servers which have agreed to provide service through private
        !          1239:      agreement or some other means outside of the DNS protocol.
        !          1240: 
        !          1241: The recursive mode occurs when a query with RD set arrives at a server
        !          1242: which is willing to provide recursive service; the client can verify
        !          1243: that recursive mode was used by checking that both RA and RD are set in
        !          1244: the reply.  Note that the name server should never perform recursive
        !          1245: service unless asked via RD, since this interferes with trouble shooting
        !          1246: of name servers and their databases.
        !          1247: 
        !          1248: If recursive service is requested and available, the recursive response
        !          1249: to a query will be one of the following:
        !          1250: 
        !          1251:    - The answer to the query, possibly preface by one or more CNAME
        !          1252:      RRs that specify aliases encountered on the way to an answer.
        !          1253: 
        !          1254:    - A name error indicating that the name does not exist.  This
        !          1255:      may include CNAME RRs that indicate that the original query
        !          1256:      name was an alias for a name which does not exist.
        !          1257: 
        !          1258:    - A temporary error indication.
        !          1259: 
        !          1260: If recursive service is not requested or is not available, the non-
        !          1261: recursive response will be one of the following:
        !          1262: 
        !          1263:    - An authoritative name error indicating that the name does not
        !          1264:      exist.
        !          1265: 
        !          1266:    - A temporary error indication.
        !          1267: 
        !          1268:    - Some combination of:
        !          1269: 
        !          1270:      RRs that answer the question, together with an indication
        !          1271:      whether the data comes from a zone or is cached.
        !          1272: 
        !          1273:      A referral to name servers which have zones which are closer
        !          1274:      ancestors to the name than the server sending the reply.
        !          1275: 
        !          1276:    - RRs that the name server thinks will prove useful to the
        !          1277:      requester.
        !          1278: 
        !          1279: 
        !          1280: 
        !          1281: 
        !          1282: 
        !          1283: 
        !          1284: Mockapetris                                                    [Page 23]
        !          1285: 
        !          1286: RFC 1034             Domain Concepts and Facilities        November 1987
        !          1287: 
        !          1288: 
        !          1289: 4.3.2. Algorithm
        !          1290: 
        !          1291: The actual algorithm used by the name server will depend on the local OS
        !          1292: and data structures used to store RRs.  The following algorithm assumes
        !          1293: that the RRs are organized in several tree structures, one for each
        !          1294: zone, and another for the cache:
        !          1295: 
        !          1296:    1. Set or clear the value of recursion available in the response
        !          1297:       depending on whether the name server is willing to provide
        !          1298:       recursive service.  If recursive service is available and
        !          1299:       requested via the RD bit in the query, go to step 5,
        !          1300:       otherwise step 2.
        !          1301: 
        !          1302:    2. Search the available zones for the zone which is the nearest
        !          1303:       ancestor to QNAME.  If such a zone is found, go to step 3,
        !          1304:       otherwise step 4.
        !          1305: 
        !          1306:    3. Start matching down, label by label, in the zone.  The
        !          1307:       matching process can terminate several ways:
        !          1308: 
        !          1309:          a. If the whole of QNAME is matched, we have found the
        !          1310:             node.
        !          1311: 
        !          1312:             If the data at the node is a CNAME, and QTYPE doesn't
        !          1313:             match CNAME, copy the CNAME RR into the answer section
        !          1314:             of the response, change QNAME to the canonical name in
        !          1315:             the CNAME RR, and go back to step 1.
        !          1316: 
        !          1317:             Otherwise, copy all RRs which match QTYPE into the
        !          1318:             answer section and go to step 6.
        !          1319: 
        !          1320:          b. If a match would take us out of the authoritative data,
        !          1321:             we have a referral.  This happens when we encounter a
        !          1322:             node with NS RRs marking cuts along the bottom of a
        !          1323:             zone.
        !          1324: 
        !          1325:             Copy the NS RRs for the subzone into the authority
        !          1326:             section of the reply.  Put whatever addresses are
        !          1327:             available into the additional section, using glue RRs
        !          1328:             if the addresses are not available from authoritative
        !          1329:             data or the cache.  Go to step 4.
        !          1330: 
        !          1331:          c. If at some label, a match is impossible (i.e., the
        !          1332:             corresponding label does not exist), look to see if a
        !          1333:             the "*" label exists.
        !          1334: 
        !          1335:             If the "*" label does not exist, check whether the name
        !          1336:             we are looking for is the original QNAME in the query
        !          1337: 
        !          1338: 
        !          1339: 
        !          1340: Mockapetris                                                    [Page 24]
        !          1341: 
        !          1342: RFC 1034             Domain Concepts and Facilities        November 1987
        !          1343: 
        !          1344: 
        !          1345:             or a name we have followed due to a CNAME.  If the name
        !          1346:             is original, set an authoritative name error in the
        !          1347:             response and exit.  Otherwise just exit.
        !          1348: 
        !          1349:             If the "*" label does exist, match RRs at that node
        !          1350:             against QTYPE.  If any match, copy them into the answer
        !          1351:             section, but set the owner of the RR to be QNAME, and
        !          1352:             not the node with the "*" label.  Go to step 6.
        !          1353: 
        !          1354:    4. Start matching down in the cache.  If QNAME is found in the
        !          1355:       cache, copy all RRs attached to it that match QTYPE into the
        !          1356:       answer section.  If there was no delegation from
        !          1357:       authoritative data, look for the best one from the cache, and
        !          1358:       put it in the authority section.  Go to step 6.
        !          1359: 
        !          1360:    5. Using the local resolver or a copy of its algorithm (see
        !          1361:       resolver section of this memo) to answer the query.  Store
        !          1362:       the results, including any intermediate CNAMEs, in the answer
        !          1363:       section of the response.
        !          1364: 
        !          1365:    6. Using local data only, attempt to add other RRs which may be
        !          1366:       useful to the additional section of the query.  Exit.
        !          1367: 
        !          1368: 4.3.3. Wildcards
        !          1369: 
        !          1370: In the previous algorithm, special treatment was given to RRs with owner
        !          1371: names starting with the label "*".  Such RRs are called wildcards.
        !          1372: Wildcard RRs can be thought of as instructions for synthesizing RRs.
        !          1373: When the appropriate conditions are met, the name server creates RRs
        !          1374: with an owner name equal to the query name and contents taken from the
        !          1375: wildcard RRs.
        !          1376: 
        !          1377: This facility is most often used to create a zone which will be used to
        !          1378: forward mail from the Internet to some other mail system.  The general
        !          1379: idea is that any name in that zone which is presented to server in a
        !          1380: query will be assumed to exist, with certain properties, unless explicit
        !          1381: evidence exists to the contrary.  Note that the use of the term zone
        !          1382: here, instead of domain, is intentional; such defaults do not propagate
        !          1383: across zone boundaries, although a subzone may choose to achieve that
        !          1384: appearance by setting up similar defaults.
        !          1385: 
        !          1386: The contents of the wildcard RRs follows the usual rules and formats for
        !          1387: RRs.  The wildcards in the zone have an owner name that controls the
        !          1388: query names they will match.  The owner name of the wildcard RRs is of
        !          1389: the form "*.<anydomain>", where <anydomain> is any domain name.
        !          1390: <anydomain> should not contain other * labels, and should be in the
        !          1391: authoritative data of the zone.  The wildcards potentially apply to
        !          1392: descendants of <anydomain>, but not to <anydomain> itself.  Another way
        !          1393: 
        !          1394: 
        !          1395: 
        !          1396: Mockapetris                                                    [Page 25]
        !          1397: 
        !          1398: RFC 1034             Domain Concepts and Facilities        November 1987
        !          1399: 
        !          1400: 
        !          1401: to look at this is that the "*" label always matches at least one whole
        !          1402: label and sometimes more, but always whole labels.
        !          1403: 
        !          1404: Wildcard RRs do not apply:
        !          1405: 
        !          1406:    - When the query is in another zone.  That is, delegation cancels
        !          1407:      the wildcard defaults.
        !          1408: 
        !          1409:    - When the query name or a name between the wildcard domain and
        !          1410:      the query name is know to exist.  For example, if a wildcard
        !          1411:      RR has an owner name of "*.X", and the zone also contains RRs
        !          1412:      attached to B.X, the wildcards would apply to queries for name
        !          1413:      Z.X (presuming there is no explicit information for Z.X), but
        !          1414:      not to B.X, A.B.X, or X.
        !          1415: 
        !          1416: A * label appearing in a query name has no special effect, but can be
        !          1417: used to test for wildcards in an authoritative zone; such a query is the
        !          1418: only way to get a response containing RRs with an owner name with * in
        !          1419: it.  The result of such a query should not be cached.
        !          1420: 
        !          1421: Note that the contents of the wildcard RRs are not modified when used to
        !          1422: synthesize RRs.
        !          1423: 
        !          1424: To illustrate the use of wildcard RRs, suppose a large company with a
        !          1425: large, non-IP/TCP, network wanted to create a mail gateway.  If the
        !          1426: company was called X.COM, and IP/TCP capable gateway machine was called
        !          1427: A.X.COM, the following RRs might be entered into the COM zone:
        !          1428: 
        !          1429:     X.COM           MX      10      A.X.COM
        !          1430: 
        !          1431:     *.X.COM         MX      10      A.X.COM
        !          1432: 
        !          1433:     A.X.COM         A       1.2.3.4
        !          1434:     A.X.COM         MX      10      A.X.COM
        !          1435: 
        !          1436:     *.A.X.COM       MX      10      A.X.COM
        !          1437: 
        !          1438: This would cause any MX query for any domain name ending in X.COM to
        !          1439: return an MX RR pointing at A.X.COM.  Two wildcard RRs are required
        !          1440: since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM
        !          1441: subtree by the explicit data for A.X.COM.  Note also that the explicit
        !          1442: MX data at X.COM and A.X.COM is required, and that none of the RRs above
        !          1443: would match a query name of XX.COM.
        !          1444: 
        !          1445: 4.3.4. Negative response caching (Optional)
        !          1446: 
        !          1447: The DNS provides an optional service which allows name servers to
        !          1448: distribute, and resolvers to cache, negative results with TTLs.  For
        !          1449: 
        !          1450: 
        !          1451: 
        !          1452: Mockapetris                                                    [Page 26]
        !          1453: 
        !          1454: RFC 1034             Domain Concepts and Facilities        November 1987
        !          1455: 
        !          1456: 
        !          1457: example, a name server can distribute a TTL along with a name error
        !          1458: indication, and a resolver receiving such information is allowed to
        !          1459: assume that the name does not exist during the TTL period without
        !          1460: consulting authoritative data.  Similarly, a resolver can make a query
        !          1461: with a QTYPE which matches multiple types, and cache the fact that some
        !          1462: of the types are not present.
        !          1463: 
        !          1464: This feature can be particularly important in a system which implements
        !          1465: naming shorthands that use search lists beacuse a popular shorthand,
        !          1466: which happens to require a suffix toward the end of the search list,
        !          1467: will generate multiple name errors whenever it is used.
        !          1468: 
        !          1469: The method is that a name server may add an SOA RR to the additional
        !          1470: section of a response when that response is authoritative.  The SOA must
        !          1471: be that of the zone which was the source of the authoritative data in
        !          1472: the answer section, or name error if applicable.  The MINIMUM field of
        !          1473: the SOA controls the length of time that the negative result may be
        !          1474: cached.
        !          1475: 
        !          1476: Note that in some circumstances, the answer section may contain multiple
        !          1477: owner names.  In this case, the SOA mechanism should only be used for
        !          1478: the data which matches QNAME, which is the only authoritative data in
        !          1479: this section.
        !          1480: 
        !          1481: Name servers and resolvers should never attempt to add SOAs to the
        !          1482: additional section of a non-authoritative response, or attempt to infer
        !          1483: results which are not directly stated in an authoritative response.
        !          1484: There are several reasons for this, including: cached information isn't
        !          1485: usually enough to match up RRs and their zone names, SOA RRs may be
        !          1486: cached due to direct SOA queries, and name servers are not required to
        !          1487: output the SOAs in the authority section.
        !          1488: 
        !          1489: This feature is optional, although a refined version is expected to
        !          1490: become part of the standard protocol in the future.  Name servers are
        !          1491: not required to add the SOA RRs in all authoritative responses, nor are
        !          1492: resolvers required to cache negative results.  Both are recommended.
        !          1493: All resolvers and recursive name servers are required to at least be
        !          1494: able to ignore the SOA RR when it is present in a response.
        !          1495: 
        !          1496: Some experiments have also been proposed which will use this feature.
        !          1497: The idea is that if cached data is known to come from a particular zone,
        !          1498: and if an authoritative copy of the zone's SOA is obtained, and if the
        !          1499: zone's SERIAL has not changed since the data was cached, then the TTL of
        !          1500: the cached data can be reset to the zone MINIMUM value if it is smaller.
        !          1501: This usage is mentioned for planning purposes only, and is not
        !          1502: recommended as yet.
        !          1503: 
        !          1504: 
        !          1505: 
        !          1506: 
        !          1507: 
        !          1508: Mockapetris                                                    [Page 27]
        !          1509: 
        !          1510: RFC 1034             Domain Concepts and Facilities        November 1987
        !          1511: 
        !          1512: 
        !          1513: 4.3.5. Zone maintenance and transfers
        !          1514: 
        !          1515: Part of the job of a zone administrator is to maintain the zones at all
        !          1516: of the name servers which are authoritative for the zone.  When the
        !          1517: inevitable changes are made, they must be distributed to all of the name
        !          1518: servers.  While this distribution can be accomplished using FTP or some
        !          1519: other ad hoc procedure, the preferred method is the zone transfer part
        !          1520: of the DNS protocol.
        !          1521: 
        !          1522: The general model of automatic zone transfer or refreshing is that one
        !          1523: of the name servers is the master or primary for the zone.  Changes are
        !          1524: coordinated at the primary, typically by editing a master file for the
        !          1525: zone.  After editing, the administrator signals the master server to
        !          1526: load the new zone.  The other non-master or secondary servers for the
        !          1527: zone periodically check for changes (at a selectable interval) and
        !          1528: obtain new zone copies when changes have been made.
        !          1529: 
        !          1530: To detect changes, secondaries just check the SERIAL field of the SOA
        !          1531: for the zone.  In addition to whatever other changes are made, the
        !          1532: SERIAL field in the SOA of the zone is always advanced whenever any
        !          1533: change is made to the zone.  The advancing can be a simple increment, or
        !          1534: could be based on the write date and time of the master file, etc.  The
        !          1535: purpose is to make it possible to determine which of two copies of a
        !          1536: zone is more recent by comparing serial numbers.  Serial number advances
        !          1537: and comparisons use sequence space arithmetic, so there is a theoretic
        !          1538: limit on how fast a zone can be updated, basically that old copies must
        !          1539: die out before the serial number covers half of its 32 bit range.  In
        !          1540: practice, the only concern is that the compare operation deals properly
        !          1541: with comparisons around the boundary between the most positive and most
        !          1542: negative 32 bit numbers.
        !          1543: 
        !          1544: The periodic polling of the secondary servers is controlled by
        !          1545: parameters in the SOA RR for the zone, which set the minimum acceptable
        !          1546: polling intervals.  The parameters are called REFRESH, RETRY, and
        !          1547: EXPIRE.  Whenever a new zone is loaded in a secondary, the secondary
        !          1548: waits REFRESH seconds before checking with the primary for a new serial.
        !          1549: If this check cannot be completed, new checks are started every RETRY
        !          1550: seconds.  The check is a simple query to the primary for the SOA RR of
        !          1551: the zone.  If the serial field in the secondary's zone copy is equal to
        !          1552: the serial returned by the primary, then no changes have occurred, and
        !          1553: the REFRESH interval wait is restarted.  If the secondary finds it
        !          1554: impossible to perform a serial check for the EXPIRE interval, it must
        !          1555: assume that its copy of the zone is obsolete an discard it.
        !          1556: 
        !          1557: When the poll shows that the zone has changed, then the secondary server
        !          1558: must request a zone transfer via an AXFR request for the zone.  The AXFR
        !          1559: may cause an error, such as refused, but normally is answered by a
        !          1560: sequence of response messages.  The first and last messages must contain
        !          1561: 
        !          1562: 
        !          1563: 
        !          1564: Mockapetris                                                    [Page 28]
        !          1565: 
        !          1566: RFC 1034             Domain Concepts and Facilities        November 1987
        !          1567: 
        !          1568: 
        !          1569: the data for the top authoritative node of the zone.  Intermediate
        !          1570: messages carry all of the other RRs from the zone, including both
        !          1571: authoritative and non-authoritative RRs.  The stream of messages allows
        !          1572: the secondary to construct a copy of the zone.  Because accuracy is
        !          1573: essential, TCP or some other reliable protocol must be used for AXFR
        !          1574: requests.
        !          1575: 
        !          1576: Each secondary server is required to perform the following operations
        !          1577: against the master, but may also optionally perform these operations
        !          1578: against other secondary servers.  This strategy can improve the transfer
        !          1579: process when the primary is unavailable due to host downtime or network
        !          1580: problems, or when a secondary server has better network access to an
        !          1581: "intermediate" secondary than to the primary.
        !          1582: 
        !          1583: 5. RESOLVERS
        !          1584: 
        !          1585: 5.1. Introduction
        !          1586: 
        !          1587: Resolvers are programs that interface user programs to domain name
        !          1588: servers.  In the simplest case, a resolver receives a request from a
        !          1589: user program (e.g., mail programs, TELNET, FTP) in the form of a
        !          1590: subroutine call, system call etc., and returns the desired information
        !          1591: in a form compatible with the local host's data formats.
        !          1592: 
        !          1593: The resolver is located on the same machine as the program that requests
        !          1594: the resolver's services, but it may need to consult name servers on
        !          1595: other hosts.  Because a resolver may need to consult several name
        !          1596: servers, or may have the requested information in a local cache, the
        !          1597: amount of time that a resolver will take to complete can vary quite a
        !          1598: bit, from milliseconds to several seconds.
        !          1599: 
        !          1600: A very important goal of the resolver is to eliminate network delay and
        !          1601: name server load from most requests by answering them from its cache of
        !          1602: prior results.  It follows that caches which are shared by multiple
        !          1603: processes, users, machines, etc., are more efficient than non-shared
        !          1604: caches.
        !          1605: 
        !          1606: 5.2. Client-resolver interface
        !          1607: 
        !          1608: 5.2.1. Typical functions
        !          1609: 
        !          1610: The client interface to the resolver is influenced by the local host's
        !          1611: conventions, but the typical resolver-client interface has three
        !          1612: functions:
        !          1613: 
        !          1614:    1. Host name to host address translation.
        !          1615: 
        !          1616:       This function is often defined to mimic a previous HOSTS.TXT
        !          1617: 
        !          1618: 
        !          1619: 
        !          1620: Mockapetris                                                    [Page 29]
        !          1621: 
        !          1622: RFC 1034             Domain Concepts and Facilities        November 1987
        !          1623: 
        !          1624: 
        !          1625:       based function.  Given a character string, the caller wants
        !          1626:       one or more 32 bit IP addresses.  Under the DNS, it
        !          1627:       translates into a request for type A RRs.  Since the DNS does
        !          1628:       not preserve the order of RRs, this function may choose to
        !          1629:       sort the returned addresses or select the "best" address if
        !          1630:       the service returns only one choice to the client.  Note that
        !          1631:       a multiple address return is recommended, but a single
        !          1632:       address may be the only way to emulate prior HOSTS.TXT
        !          1633:       services.
        !          1634: 
        !          1635:    2. Host address to host name translation
        !          1636: 
        !          1637:       This function will often follow the form of previous
        !          1638:       functions.  Given a 32 bit IP address, the caller wants a
        !          1639:       character string.  The octets of the IP address are reversed,
        !          1640:       used as name components, and suffixed with "IN-ADDR.ARPA".  A
        !          1641:       type PTR query is used to get the RR with the primary name of
        !          1642:       the host.  For example, a request for the host name
        !          1643:       corresponding to IP address 1.2.3.4 looks for PTR RRs for
        !          1644:       domain name "4.3.2.1.IN-ADDR.ARPA".
        !          1645: 
        !          1646:    3. General lookup function
        !          1647: 
        !          1648:       This function retrieves arbitrary information from the DNS,
        !          1649:       and has no counterpart in previous systems.  The caller
        !          1650:       supplies a QNAME, QTYPE, and QCLASS, and wants all of the
        !          1651:       matching RRs.  This function will often use the DNS format
        !          1652:       for all RR data instead of the local host's, and returns all
        !          1653:       RR content (e.g., TTL) instead of a processed form with local
        !          1654:       quoting conventions.
        !          1655: 
        !          1656: When the resolver performs the indicated function, it usually has one of
        !          1657: the following results to pass back to the client:
        !          1658: 
        !          1659:    - One or more RRs giving the requested data.
        !          1660: 
        !          1661:      In this case the resolver returns the answer in the
        !          1662:      appropriate format.
        !          1663: 
        !          1664:    - A name error (NE).
        !          1665: 
        !          1666:      This happens when the referenced name does not exist.  For
        !          1667:      example, a user may have mistyped a host name.
        !          1668: 
        !          1669:    - A data not found error.
        !          1670: 
        !          1671:      This happens when the referenced name exists, but data of the
        !          1672:      appropriate type does not.  For example, a host address
        !          1673: 
        !          1674: 
        !          1675: 
        !          1676: Mockapetris                                                    [Page 30]
        !          1677: 
        !          1678: RFC 1034             Domain Concepts and Facilities        November 1987
        !          1679: 
        !          1680: 
        !          1681:      function applied to a mailbox name would return this error
        !          1682:      since the name exists, but no address RR is present.
        !          1683: 
        !          1684: It is important to note that the functions for translating between host
        !          1685: names and addresses may combine the "name error" and "data not found"
        !          1686: error conditions into a single type of error return, but the general
        !          1687: function should not.  One reason for this is that applications may ask
        !          1688: first for one type of information about a name followed by a second
        !          1689: request to the same name for some other type of information; if the two
        !          1690: errors are combined, then useless queries may slow the application.
        !          1691: 
        !          1692: 5.2.2. Aliases
        !          1693: 
        !          1694: While attempting to resolve a particular request, the resolver may find
        !          1695: that the name in question is an alias.  For example, the resolver might
        !          1696: find that the name given for host name to address translation is an
        !          1697: alias when it finds the CNAME RR.  If possible, the alias condition
        !          1698: should be signalled back from the resolver to the client.
        !          1699: 
        !          1700: In most cases a resolver simply restarts the query at the new name when
        !          1701: it encounters a CNAME.  However, when performing the general function,
        !          1702: the resolver should not pursue aliases when the CNAME RR matches the
        !          1703: query type.  This allows queries which ask whether an alias is present.
        !          1704: For example, if the query type is CNAME, the user is interested in the
        !          1705: CNAME RR itself, and not the RRs at the name it points to.
        !          1706: 
        !          1707: Several special conditions can occur with aliases.  Multiple levels of
        !          1708: aliases should be avoided due to their lack of efficiency, but should
        !          1709: not be signalled as an error.  Alias loops and aliases which point to
        !          1710: non-existent names should be caught and an error condition passed back
        !          1711: to the client.
        !          1712: 
        !          1713: 5.2.3. Temporary failures
        !          1714: 
        !          1715: In a less than perfect world, all resolvers will occasionally be unable
        !          1716: to resolve a particular request.  This condition can be caused by a
        !          1717: resolver which becomes separated from the rest of the network due to a
        !          1718: link failure or gateway problem, or less often by coincident failure or
        !          1719: unavailability of all servers for a particular domain.
        !          1720: 
        !          1721: It is essential that this sort of condition should not be signalled as a
        !          1722: name or data not present error to applications.  This sort of behavior
        !          1723: is annoying to humans, and can wreak havoc when mail systems use the
        !          1724: DNS.
        !          1725: 
        !          1726: While in some cases it is possible to deal with such a temporary problem
        !          1727: by blocking the request indefinitely, this is usually not a good choice,
        !          1728: particularly when the client is a server process that could move on to
        !          1729: 
        !          1730: 
        !          1731: 
        !          1732: Mockapetris                                                    [Page 31]
        !          1733: 
        !          1734: RFC 1034             Domain Concepts and Facilities        November 1987
        !          1735: 
        !          1736: 
        !          1737: other tasks.  The recommended solution is to always have temporary
        !          1738: failure as one of the possible results of a resolver function, even
        !          1739: though this may make emulation of existing HOSTS.TXT functions more
        !          1740: difficult.
        !          1741: 
        !          1742: 5.3. Resolver internals
        !          1743: 
        !          1744: Every resolver implementation uses slightly different algorithms, and
        !          1745: typically spends much more logic dealing with errors of various sorts
        !          1746: than typical occurances.  This section outlines a recommended basic
        !          1747: strategy for resolver operation, but leaves details to [RFC-1035].
        !          1748: 
        !          1749: 5.3.1. Stub resolvers
        !          1750: 
        !          1751: One option for implementing a resolver is to move the resolution
        !          1752: function out of the local machine and into a name server which supports
        !          1753: recursive queries.  This can provide an easy method of providing domain
        !          1754: service in a PC which lacks the resources to perform the resolver
        !          1755: function, or can centralize the cache for a whole local network or
        !          1756: organization.
        !          1757: 
        !          1758: All that the remaining stub needs is a list of name server addresses
        !          1759: that will perform the recursive requests.  This type of resolver
        !          1760: presumably needs the information in a configuration file, since it
        !          1761: probably lacks the sophistication to locate it in the domain database.
        !          1762: The user also needs to verify that the listed servers will perform the
        !          1763: recursive service; a name server is free to refuse to perform recursive
        !          1764: services for any or all clients.  The user should consult the local
        !          1765: system administrator to find name servers willing to perform the
        !          1766: service.
        !          1767: 
        !          1768: This type of service suffers from some drawbacks.  Since the recursive
        !          1769: requests may take an arbitrary amount of time to perform, the stub may
        !          1770: have difficulty optimizing retransmission intervals to deal with both
        !          1771: lost UDP packets and dead servers; the name server can be easily
        !          1772: overloaded by too zealous a stub if it interprets retransmissions as new
        !          1773: requests.  Use of TCP may be an answer, but TCP may well place burdens
        !          1774: on the host's capabilities which are similar to those of a real
        !          1775: resolver.
        !          1776: 
        !          1777: 5.3.2. Resources
        !          1778: 
        !          1779: In addition to its own resources, the resolver may also have shared
        !          1780: access to zones maintained by a local name server.  This gives the
        !          1781: resolver the advantage of more rapid access, but the resolver must be
        !          1782: careful to never let cached information override zone data.  In this
        !          1783: discussion the term "local information" is meant to mean the union of
        !          1784: the cache and such shared zones, with the understanding that
        !          1785: 
        !          1786: 
        !          1787: 
        !          1788: Mockapetris                                                    [Page 32]
        !          1789: 
        !          1790: RFC 1034             Domain Concepts and Facilities        November 1987
        !          1791: 
        !          1792: 
        !          1793: authoritative data is always used in preference to cached data when both
        !          1794: are present.
        !          1795: 
        !          1796: The following resolver algorithm assumes that all functions have been
        !          1797: converted to a general lookup function, and uses the following data
        !          1798: structures to represent the state of a request in progress in the
        !          1799: resolver:
        !          1800: 
        !          1801: SNAME           the domain name we are searching for.
        !          1802: 
        !          1803: STYPE           the QTYPE of the search request.
        !          1804: 
        !          1805: SCLASS          the QCLASS of the search request.
        !          1806: 
        !          1807: SLIST           a structure which describes the name servers and the
        !          1808:                 zone which the resolver is currently trying to query.
        !          1809:                 This structure keeps track of the resolver's current
        !          1810:                 best guess about which name servers hold the desired
        !          1811:                 information; it is updated when arriving information
        !          1812:                 changes the guess.  This structure includes the
        !          1813:                 equivalent of a zone name, the known name servers for
        !          1814:                 the zone, the known addresses for the name servers, and
        !          1815:                 history information which can be used to suggest which
        !          1816:                 server is likely to be the best one to try next.  The
        !          1817:                 zone name equivalent is a match count of the number of
        !          1818:                 labels from the root down which SNAME has in common with
        !          1819:                 the zone being queried; this is used as a measure of how
        !          1820:                 "close" the resolver is to SNAME.
        !          1821: 
        !          1822: SBELT           a "safety belt" structure of the same form as SLIST,
        !          1823:                 which is initialized from a configuration file, and
        !          1824:                 lists servers which should be used when the resolver
        !          1825:                 doesn't have any local information to guide name server
        !          1826:                 selection.  The match count will be -1 to indicate that
        !          1827:                 no labels are known to match.
        !          1828: 
        !          1829: CACHE           A structure which stores the results from previous
        !          1830:                 responses.  Since resolvers are responsible for
        !          1831:                 discarding old RRs whose TTL has expired, most
        !          1832:                 implementations convert the interval specified in
        !          1833:                 arriving RRs to some sort of absolute time when the RR
        !          1834:                 is stored in the cache.  Instead of counting the TTLs
        !          1835:                 down individually, the resolver just ignores or discards
        !          1836:                 old RRs when it runs across them in the course of a
        !          1837:                 search, or discards them during periodic sweeps to
        !          1838:                 reclaim the memory consumed by old RRs.
        !          1839: 
        !          1840: 
        !          1841: 
        !          1842: 
        !          1843: 
        !          1844: Mockapetris                                                    [Page 33]
        !          1845: 
        !          1846: RFC 1034             Domain Concepts and Facilities        November 1987
        !          1847: 
        !          1848: 
        !          1849: 5.3.3. Algorithm
        !          1850: 
        !          1851: The top level algorithm has four steps:
        !          1852: 
        !          1853:    1. See if the answer is in local information, and if so return
        !          1854:       it to the client.
        !          1855: 
        !          1856:    2. Find the best servers to ask.
        !          1857: 
        !          1858:    3. Send them queries until one returns a response.
        !          1859: 
        !          1860:    4. Analyze the response, either:
        !          1861: 
        !          1862:          a. if the response answers the question or contains a name
        !          1863:             error, cache the data as well as returning it back to
        !          1864:             the client.
        !          1865: 
        !          1866:          b. if the response contains a better delegation to other
        !          1867:             servers, cache the delegation information, and go to
        !          1868:             step 2.
        !          1869: 
        !          1870:          c. if the response shows a CNAME and that is not the
        !          1871:             answer itself, cache the CNAME, change the SNAME to the
        !          1872:             canonical name in the CNAME RR and go to step 1.
        !          1873: 
        !          1874:          d. if the response shows a servers failure or other
        !          1875:             bizarre contents, delete the server from the SLIST and
        !          1876:             go back to step 3.
        !          1877: 
        !          1878: Step 1 searches the cache for the desired data. If the data is in the
        !          1879: cache, it is assumed to be good enough for normal use.  Some resolvers
        !          1880: have an option at the user interface which will force the resolver to
        !          1881: ignore the cached data and consult with an authoritative server.  This
        !          1882: is not recommended as the default.  If the resolver has direct access to
        !          1883: a name server's zones, it should check to see if the desired data is
        !          1884: present in authoritative form, and if so, use the authoritative data in
        !          1885: preference to cached data.
        !          1886: 
        !          1887: Step 2 looks for a name server to ask for the required data.  The
        !          1888: general strategy is to look for locally-available name server RRs,
        !          1889: starting at SNAME, then the parent domain name of SNAME, the
        !          1890: grandparent, and so on toward the root.  Thus if SNAME were
        !          1891: Mockapetris.ISI.EDU, this step would look for NS RRs for
        !          1892: Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root).
        !          1893: These NS RRs list the names of hosts for a zone at or above SNAME.  Copy
        !          1894: the names into SLIST.  Set up their addresses using local data.  It may
        !          1895: be the case that the addresses are not available.  The resolver has many
        !          1896: choices here; the best is to start parallel resolver processes looking
        !          1897: 
        !          1898: 
        !          1899: 
        !          1900: Mockapetris                                                    [Page 34]
        !          1901: 
        !          1902: RFC 1034             Domain Concepts and Facilities        November 1987
        !          1903: 
        !          1904: 
        !          1905: for the addresses while continuing onward with the addresses which are
        !          1906: available.  Obviously, the design choices and options are complicated
        !          1907: and a function of the local host's capabilities.  The recommended
        !          1908: priorities for the resolver designer are:
        !          1909: 
        !          1910:    1. Bound the amount of work (packets sent, parallel processes
        !          1911:       started) so that a request can't get into an infinite loop or
        !          1912:       start off a chain reaction of requests or queries with other
        !          1913:       implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
        !          1914:       SOME DATA.
        !          1915: 
        !          1916:    2. Get back an answer if at all possible.
        !          1917: 
        !          1918:    3. Avoid unnecessary transmissions.
        !          1919: 
        !          1920:    4. Get the answer as quickly as possible.
        !          1921: 
        !          1922: If the search for NS RRs fails, then the resolver initializes SLIST from
        !          1923: the safety belt SBELT.  The basic idea is that when the resolver has no
        !          1924: idea what servers to ask, it should use information from a configuration
        !          1925: file that lists several servers which are expected to be helpful.
        !          1926: Although there are special situations, the usual choice is two of the
        !          1927: root servers and two of the servers for the host's domain.  The reason
        !          1928: for two of each is for redundancy.  The root servers will provide
        !          1929: eventual access to all of the domain space.  The two local servers will
        !          1930: allow the resolver to continue to resolve local names if the local
        !          1931: network becomes isolated from the internet due to gateway or link
        !          1932: failure.
        !          1933: 
        !          1934: In addition to the names and addresses of the servers, the SLIST data
        !          1935: structure can be sorted to use the best servers first, and to insure
        !          1936: that all addresses of all servers are used in a round-robin manner.  The
        !          1937: sorting can be a simple function of preferring addresses on the local
        !          1938: network over others, or may involve statistics from past events, such as
        !          1939: previous response times and batting averages.
        !          1940: 
        !          1941: Step 3 sends out queries until a response is received.  The strategy is
        !          1942: to cycle around all of the addresses for all of the servers with a
        !          1943: timeout between each transmission.  In practice it is important to use
        !          1944: all addresses of a multihomed host, and too aggressive a retransmission
        !          1945: policy actually slows response when used by multiple resolvers
        !          1946: contending for the same name server and even occasionally for a single
        !          1947: resolver.  SLIST typically contains data values to control the timeouts
        !          1948: and keep track of previous transmissions.
        !          1949: 
        !          1950: Step 4 involves analyzing responses.  The resolver should be highly
        !          1951: paranoid in its parsing of responses.  It should also check that the
        !          1952: response matches the query it sent using the ID field in the response.
        !          1953: 
        !          1954: 
        !          1955: 
        !          1956: Mockapetris                                                    [Page 35]
        !          1957: 
        !          1958: RFC 1034             Domain Concepts and Facilities        November 1987
        !          1959: 
        !          1960: 
        !          1961: The ideal answer is one from a server authoritative for the query which
        !          1962: either gives the required data or a name error.  The data is passed back
        !          1963: to the user and entered in the cache for future use if its TTL is
        !          1964: greater than zero.
        !          1965: 
        !          1966: If the response shows a delegation, the resolver should check to see
        !          1967: that the delegation is "closer" to the answer than the servers in SLIST
        !          1968: are.  This can be done by comparing the match count in SLIST with that
        !          1969: computed from SNAME and the NS RRs in the delegation.  If not, the reply
        !          1970: is bogus and should be ignored.  If the delegation is valid the NS
        !          1971: delegation RRs and any address RRs for the servers should be cached.
        !          1972: The name servers are entered in the SLIST, and the search is restarted.
        !          1973: 
        !          1974: If the response contains a CNAME, the search is restarted at the CNAME
        !          1975: unless the response has the data for the canonical name or if the CNAME
        !          1976: is the answer itself.
        !          1977: 
        !          1978: Details and implementation hints can be found in [RFC-1035].
        !          1979: 
        !          1980: 6. A SCENARIO
        !          1981: 
        !          1982: In our sample domain space, suppose we wanted separate administrative
        !          1983: control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones.  We might
        !          1984: allocate name servers as follows:
        !          1985: 
        !          1986: 
        !          1987:                                    |(C.ISI.EDU,SRI-NIC.ARPA
        !          1988:                                    | A.ISI.EDU)
        !          1989:              +---------------------+------------------+
        !          1990:              |                     |                  |
        !          1991:             MIL                   EDU                ARPA
        !          1992:              |(SRI-NIC.ARPA,       |(SRI-NIC.ARPA,    |
        !          1993:              | A.ISI.EDU           | C.ISI.EDU)       |
        !          1994:        +-----+-----+               |     +------+-----+-----+
        !          1995:        |     |     |               |     |      |           |
        !          1996:       BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
        !          1997:                                    |
        !          1998:        +--------+------------------+---------------+--------+
        !          1999:        |        |                  |               |        |
        !          2000:       UCI      MIT                 |              UDEL     YALE
        !          2001:                 |(XX.LCS.MIT.EDU, ISI
        !          2002:                 |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU,
        !          2003:             +---+---+              | A.ISI.EDU)
        !          2004:             |       |              |
        !          2005:            LCS   ACHILLES +--+-----+-----+--------+
        !          2006:             |             |  |     |     |        |
        !          2007:             XX            A  C   VAXA  VENERA Mockapetris
        !          2008: 
        !          2009: 
        !          2010: 
        !          2011: 
        !          2012: Mockapetris                                                    [Page 36]
        !          2013: 
        !          2014: RFC 1034             Domain Concepts and Facilities        November 1987
        !          2015: 
        !          2016: 
        !          2017: In this example, the authoritative name server is shown in parentheses
        !          2018: at the point in the domain tree at which is assumes control.
        !          2019: 
        !          2020: Thus the root name servers are on C.ISI.EDU, SRI-NIC.ARPA, and
        !          2021: A.ISI.EDU.  The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU.  The
        !          2022: EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU.  Note that servers
        !          2023: may have zones which are contiguous or disjoint.  In this scenario,
        !          2024: C.ISI.EDU has contiguous zones at the root and EDU domains.  A.ISI.EDU
        !          2025: has contiguous zones at the root and MIL domains, but also has a non-
        !          2026: contiguous zone at ISI.EDU.
        !          2027: 
        !          2028: 6.1. C.ISI.EDU name server
        !          2029: 
        !          2030: C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN
        !          2031: class, and would have zones for these domains.  The zone data for the
        !          2032: root domain might be:
        !          2033: 
        !          2034:     .       IN      SOA     SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
        !          2035:                             870611          ;serial
        !          2036:                             1800            ;refresh every 30 min
        !          2037:                             300             ;retry every 5 min
        !          2038:                             604800          ;expire after a week
        !          2039:                             86400)          ;minimum of a day
        !          2040:                     NS      A.ISI.EDU.
        !          2041:                     NS      C.ISI.EDU.
        !          2042:                     NS      SRI-NIC.ARPA.
        !          2043: 
        !          2044:     MIL.    86400   NS      SRI-NIC.ARPA.
        !          2045:             86400   NS      A.ISI.EDU.
        !          2046: 
        !          2047:     EDU.    86400   NS      SRI-NIC.ARPA.
        !          2048:             86400   NS      C.ISI.EDU.
        !          2049: 
        !          2050:     SRI-NIC.ARPA.   A       26.0.0.73
        !          2051:                     A       10.0.0.51
        !          2052:                     MX      0 SRI-NIC.ARPA.
        !          2053:                     HINFO   DEC-2060 TOPS20
        !          2054: 
        !          2055:     ACC.ARPA.       A       26.6.0.65
        !          2056:                     HINFO   PDP-11/70 UNIX
        !          2057:                     MX      10 ACC.ARPA.
        !          2058: 
        !          2059:     USC-ISIC.ARPA.  CNAME   C.ISI.EDU.
        !          2060: 
        !          2061:     73.0.0.26.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
        !          2062:     65.0.6.26.IN-ADDR.ARPA.  PTR    ACC.ARPA.
        !          2063:     51.0.0.10.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
        !          2064:     52.0.0.10.IN-ADDR.ARPA.  PTR    C.ISI.EDU.
        !          2065: 
        !          2066: 
        !          2067: 
        !          2068: Mockapetris                                                    [Page 37]
        !          2069: 
        !          2070: RFC 1034             Domain Concepts and Facilities        November 1987
        !          2071: 
        !          2072: 
        !          2073:     103.0.3.26.IN-ADDR.ARPA. PTR    A.ISI.EDU.
        !          2074: 
        !          2075:     A.ISI.EDU. 86400 A      26.3.0.103
        !          2076:     C.ISI.EDU. 86400 A      10.0.0.52
        !          2077: 
        !          2078: This data is represented as it would be in a master file.  Most RRs are
        !          2079: single line entries; the sole exception here is the SOA RR, which uses
        !          2080: "(" to start a multi-line RR and ")" to show the end of a multi-line RR.
        !          2081: Since the class of all RRs in a zone must be the same, only the first RR
        !          2082: in a zone need specify the class.  When a name server loads a zone, it
        !          2083: forces the TTL of all authoritative RRs to be at least the MINIMUM field
        !          2084: of the SOA, here 86400 seconds, or one day.  The NS RRs marking
        !          2085: delegation of the MIL and EDU domains, together with the glue RRs for
        !          2086: the servers host addresses, are not part of the authoritative data in
        !          2087: the zone, and hence have explicit TTLs.
        !          2088: 
        !          2089: Four RRs are attached to the root node: the SOA which describes the root
        !          2090: zone and the 3 NS RRs which list the name servers for the root.  The
        !          2091: data in the SOA RR describes the management of the zone.  The zone data
        !          2092: is maintained on host SRI-NIC.ARPA, and the responsible party for the
        !          2093: zone is [email protected].  A key item in the SOA is the 86400
        !          2094: second minimum TTL, which means that all authoritative data in the zone
        !          2095: has at least that TTL, although higher values may be explicitly
        !          2096: specified.
        !          2097: 
        !          2098: The NS RRs for the MIL and EDU domains mark the boundary between the
        !          2099: root zone and the MIL and EDU zones.  Note that in this example, the
        !          2100: lower zones happen to be supported by name servers which also support
        !          2101: the root zone.
        !          2102: 
        !          2103: The master file for the EDU zone might be stated relative to the origin
        !          2104: EDU.  The zone data for the EDU domain might be:
        !          2105: 
        !          2106:     EDU.  IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
        !          2107:                             870729 ;serial
        !          2108:                             1800 ;refresh every 30 minutes
        !          2109:                             300 ;retry every 5 minutes
        !          2110:                             604800 ;expire after a week
        !          2111:                             86400 ;minimum of a day
        !          2112:                             )
        !          2113:                     NS SRI-NIC.ARPA.
        !          2114:                     NS C.ISI.EDU.
        !          2115: 
        !          2116:     UCI 172800 NS ICS.UCI
        !          2117:                     172800 NS ROME.UCI
        !          2118:     ICS.UCI 172800 A 192.5.19.1
        !          2119:     ROME.UCI 172800 A 192.5.19.31
        !          2120: 
        !          2121: 
        !          2122: 
        !          2123: 
        !          2124: Mockapetris                                                    [Page 38]
        !          2125: 
        !          2126: RFC 1034             Domain Concepts and Facilities        November 1987
        !          2127: 
        !          2128: 
        !          2129:     ISI 172800 NS VAXA.ISI
        !          2130:                     172800 NS A.ISI
        !          2131:                     172800 NS VENERA.ISI.EDU.
        !          2132:     VAXA.ISI 172800 A 10.2.0.27
        !          2133:                     172800 A 128.9.0.33
        !          2134:     VENERA.ISI.EDU. 172800 A 10.1.0.52
        !          2135:                     172800 A 128.9.0.32
        !          2136:     A.ISI 172800 A 26.3.0.103
        !          2137: 
        !          2138:     UDEL.EDU.  172800 NS LOUIE.UDEL.EDU.
        !          2139:                     172800 NS UMN-REI-UC.ARPA.
        !          2140:     LOUIE.UDEL.EDU. 172800 A 10.0.0.96
        !          2141:                     172800 A 192.5.39.3
        !          2142: 
        !          2143:     YALE.EDU.  172800 NS YALE.ARPA.
        !          2144:     YALE.EDU.  172800 NS YALE-BULLDOG.ARPA.
        !          2145: 
        !          2146:     MIT.EDU.  43200 NS XX.LCS.MIT.EDU.
        !          2147:                       43200 NS ACHILLES.MIT.EDU.
        !          2148:     XX.LCS.MIT.EDU.  43200 A 10.0.0.44
        !          2149:     ACHILLES.MIT.EDU. 43200 A 18.72.0.8
        !          2150: 
        !          2151: Note the use of relative names here.  The owner name for the ISI.EDU. is
        !          2152: stated using a relative name, as are two of the name server RR contents.
        !          2153: Relative and absolute domain names may be freely intermixed in a master
        !          2154: 
        !          2155: 6.2. Example standard queries
        !          2156: 
        !          2157: The following queries and responses illustrate name server behavior.
        !          2158: Unless otherwise noted, the queries do not have recursion desired (RD)
        !          2159: in the header.  Note that the answers to non-recursive queries do depend
        !          2160: on the server being asked, but do not depend on the identity of the
        !          2161: requester.
        !          2162: 
        !          2163: 
        !          2164: 
        !          2165: 
        !          2166: 
        !          2167: 
        !          2168: 
        !          2169: 
        !          2170: 
        !          2171: 
        !          2172: 
        !          2173: 
        !          2174: 
        !          2175: 
        !          2176: 
        !          2177: 
        !          2178: 
        !          2179: 
        !          2180: Mockapetris                                                    [Page 39]
        !          2181: 
        !          2182: RFC 1034             Domain Concepts and Facilities        November 1987
        !          2183: 
        !          2184: 
        !          2185: 6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A
        !          2186: 
        !          2187: The query would look like:
        !          2188: 
        !          2189:                +---------------------------------------------------+
        !          2190:     Header     | OPCODE=SQUERY                                     |
        !          2191:                +---------------------------------------------------+
        !          2192:     Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
        !          2193:                +---------------------------------------------------+
        !          2194:     Answer     | <empty>                                           |
        !          2195:                +---------------------------------------------------+
        !          2196:     Authority  | <empty>                                           |
        !          2197:                +---------------------------------------------------+
        !          2198:     Additional | <empty>                                           |
        !          2199:                +---------------------------------------------------+
        !          2200: 
        !          2201: The response from C.ISI.EDU would be:
        !          2202: 
        !          2203:                +---------------------------------------------------+
        !          2204:     Header     | OPCODE=SQUERY, RESPONSE, AA                       |
        !          2205:                +---------------------------------------------------+
        !          2206:     Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
        !          2207:                +---------------------------------------------------+
        !          2208:     Answer     | SRI-NIC.ARPA. 86400 IN A 26.0.0.73                |
        !          2209:                |               86400 IN A 10.0.0.51                |
        !          2210:                +---------------------------------------------------+
        !          2211:     Authority  | <empty>                                           |
        !          2212:                +---------------------------------------------------+
        !          2213:     Additional | <empty>                                           |
        !          2214:                +---------------------------------------------------+
        !          2215: 
        !          2216: The header of the response looks like the header of the query, except
        !          2217: that the RESPONSE bit is set, indicating that this message is a
        !          2218: response, not a query, and the Authoritative Answer (AA) bit is set
        !          2219: indicating that the address RRs in the answer section are from
        !          2220: authoritative data.  The question section of the response matches the
        !          2221: question section of the query.
        !          2222: 
        !          2223: 
        !          2224: 
        !          2225: 
        !          2226: 
        !          2227: 
        !          2228: 
        !          2229: 
        !          2230: 
        !          2231: 
        !          2232: 
        !          2233: 
        !          2234: 
        !          2235: 
        !          2236: Mockapetris                                                    [Page 40]
        !          2237: 
        !          2238: RFC 1034             Domain Concepts and Facilities        November 1987
        !          2239: 
        !          2240: 
        !          2241: If the same query was sent to some other server which was not
        !          2242: authoritative for SRI-NIC.ARPA, the response might be:
        !          2243: 
        !          2244:                +---------------------------------------------------+
        !          2245:     Header     | OPCODE=SQUERY,RESPONSE                            |
        !          2246:                +---------------------------------------------------+
        !          2247:     Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
        !          2248:                +---------------------------------------------------+
        !          2249:     Answer     | SRI-NIC.ARPA. 1777 IN A 10.0.0.51                 |
        !          2250:                |               1777 IN A 26.0.0.73                 |
        !          2251:                +---------------------------------------------------+
        !          2252:     Authority  | <empty>                                           |
        !          2253:                +---------------------------------------------------+
        !          2254:     Additional | <empty>                                           |
        !          2255:                +---------------------------------------------------+
        !          2256: 
        !          2257: This response is different from the previous one in two ways: the header
        !          2258: does not have AA set, and the TTLs are different.  The inference is that
        !          2259: the data did not come from a zone, but from a cache.  The difference
        !          2260: between the authoritative TTL and the TTL here is due to aging of the
        !          2261: data in a cache.  The difference in ordering of the RRs in the answer
        !          2262: section is not significant.
        !          2263: 
        !          2264: 6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=*
        !          2265: 
        !          2266: A query similar to the previous one, but using a QTYPE of *, would
        !          2267: receive the following response from C.ISI.EDU:
        !          2268: 
        !          2269:                +---------------------------------------------------+
        !          2270:     Header     | OPCODE=SQUERY, RESPONSE, AA                       |
        !          2271:                +---------------------------------------------------+
        !          2272:     Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
        !          2273:                +---------------------------------------------------+
        !          2274:     Answer     | SRI-NIC.ARPA. 86400 IN  A     26.0.0.73           |
        !          2275:                |                         A     10.0.0.51           |
        !          2276:                |                         MX    0 SRI-NIC.ARPA.     |
        !          2277:                |                         HINFO DEC-2060 TOPS20     |
        !          2278:                +---------------------------------------------------+
        !          2279:     Authority  | <empty>                                           |
        !          2280:                +---------------------------------------------------+
        !          2281:     Additional | <empty>                                           |
        !          2282:                +---------------------------------------------------+
        !          2283: 
        !          2284: 
        !          2285: 
        !          2286: 
        !          2287: 
        !          2288: 
        !          2289: 
        !          2290: 
        !          2291: 
        !          2292: Mockapetris                                                    [Page 41]
        !          2293: 
        !          2294: RFC 1034             Domain Concepts and Facilities        November 1987
        !          2295: 
        !          2296: 
        !          2297: If a similar query was directed to two name servers which are not
        !          2298: authoritative for SRI-NIC.ARPA, the responses might be:
        !          2299: 
        !          2300:                +---------------------------------------------------+
        !          2301:     Header     | OPCODE=SQUERY, RESPONSE                           |
        !          2302:                +---------------------------------------------------+
        !          2303:     Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
        !          2304:                +---------------------------------------------------+
        !          2305:     Answer     | SRI-NIC.ARPA. 12345 IN     A       26.0.0.73      |
        !          2306:                |                            A       10.0.0.51      |
        !          2307:                +---------------------------------------------------+
        !          2308:     Authority  | <empty>                                           |
        !          2309:                +---------------------------------------------------+
        !          2310:     Additional | <empty>                                           |
        !          2311:                +---------------------------------------------------+
        !          2312: 
        !          2313: and
        !          2314: 
        !          2315:                +---------------------------------------------------+
        !          2316:     Header     | OPCODE=SQUERY, RESPONSE                           |
        !          2317:                +---------------------------------------------------+
        !          2318:     Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
        !          2319:                +---------------------------------------------------+
        !          2320:     Answer     | SRI-NIC.ARPA. 1290 IN HINFO  DEC-2060 TOPS20      |
        !          2321:                +---------------------------------------------------+
        !          2322:     Authority  | <empty>                                           |
        !          2323:                +---------------------------------------------------+
        !          2324:     Additional | <empty>                                           |
        !          2325:                +---------------------------------------------------+
        !          2326: 
        !          2327: Neither of these answers have AA set, so neither response comes from
        !          2328: authoritative data.  The different contents and different TTLs suggest
        !          2329: that the two servers cached data at different times, and that the first
        !          2330: server cached the response to a QTYPE=A query and the second cached the
        !          2331: response to a HINFO query.
        !          2332: 
        !          2333: 
        !          2334: 
        !          2335: 
        !          2336: 
        !          2337: 
        !          2338: 
        !          2339: 
        !          2340: 
        !          2341: 
        !          2342: 
        !          2343: 
        !          2344: 
        !          2345: 
        !          2346: 
        !          2347: 
        !          2348: Mockapetris                                                    [Page 42]
        !          2349: 
        !          2350: RFC 1034             Domain Concepts and Facilities        November 1987
        !          2351: 
        !          2352: 
        !          2353: 6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX
        !          2354: 
        !          2355: This type of query might be result from a mailer trying to look up
        !          2356: routing information for the mail destination [email protected].
        !          2357: The response from C.ISI.EDU would be:
        !          2358: 
        !          2359:                +---------------------------------------------------+
        !          2360:     Header     | OPCODE=SQUERY, RESPONSE, AA                       |
        !          2361:                +---------------------------------------------------+
        !          2362:     Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX          |
        !          2363:                +---------------------------------------------------+
        !          2364:     Answer     | SRI-NIC.ARPA. 86400 IN     MX      0 SRI-NIC.ARPA.|
        !          2365:                +---------------------------------------------------+
        !          2366:     Authority  | <empty>                                           |
        !          2367:                +---------------------------------------------------+
        !          2368:     Additional | SRI-NIC.ARPA. 86400 IN     A       26.0.0.73      |
        !          2369:                |                            A       10.0.0.51      |
        !          2370:                +---------------------------------------------------+
        !          2371: 
        !          2372: This response contains the MX RR in the answer section of the response.
        !          2373: The additional section contains the address RRs because the name server
        !          2374: at C.ISI.EDU guesses that the requester will need the addresses in order
        !          2375: to properly use the information carried by the MX.
        !          2376: 
        !          2377: 6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS
        !          2378: 
        !          2379: C.ISI.EDU would reply to this query with:
        !          2380: 
        !          2381:                +---------------------------------------------------+
        !          2382:     Header     | OPCODE=SQUERY, RESPONSE, AA                       |
        !          2383:                +---------------------------------------------------+
        !          2384:     Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS          |
        !          2385:                +---------------------------------------------------+
        !          2386:     Answer     | <empty>                                           |
        !          2387:                +---------------------------------------------------+
        !          2388:     Authority  | <empty>                                           |
        !          2389:                +---------------------------------------------------+
        !          2390:     Additional | <empty>                                           |
        !          2391:                +---------------------------------------------------+
        !          2392: 
        !          2393: The only difference between the response and the query is the AA and
        !          2394: RESPONSE bits in the header.  The interpretation of this response is
        !          2395: that the server is authoritative for the name, and the name exists, but
        !          2396: no RRs of type NS are present there.
        !          2397: 
        !          2398: 6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A
        !          2399: 
        !          2400: If a user mistyped a host name, we might see this type of query.
        !          2401: 
        !          2402: 
        !          2403: 
        !          2404: Mockapetris                                                    [Page 43]
        !          2405: 
        !          2406: RFC 1034             Domain Concepts and Facilities        November 1987
        !          2407: 
        !          2408: 
        !          2409: C.ISI.EDU would answer it with:
        !          2410: 
        !          2411:                +---------------------------------------------------+
        !          2412:     Header     | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE             |
        !          2413:                +---------------------------------------------------+
        !          2414:     Question   | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A           |
        !          2415:                +---------------------------------------------------+
        !          2416:     Answer     | <empty>                                           |
        !          2417:                +---------------------------------------------------+
        !          2418:     Authority  | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA.      |
        !          2419:                |       870611 1800 300 604800 86400                |
        !          2420:                +---------------------------------------------------+
        !          2421:     Additional | <empty>                                           |
        !          2422:                +---------------------------------------------------+
        !          2423: 
        !          2424: This response states that the name does not exist.  This condition is
        !          2425: signalled in the response code (RCODE) section of the header.
        !          2426: 
        !          2427: The SOA RR in the authority section is the optional negative caching
        !          2428: information which allows the resolver using this response to assume that
        !          2429: the name will not exist for the SOA MINIMUM (86400) seconds.
        !          2430: 
        !          2431: 6.2.6. QNAME=BRL.MIL, QTYPE=A
        !          2432: 
        !          2433: If this query is sent to C.ISI.EDU, the reply would be:
        !          2434: 
        !          2435:                +---------------------------------------------------+
        !          2436:     Header     | OPCODE=SQUERY, RESPONSE                           |
        !          2437:                +---------------------------------------------------+
        !          2438:     Question   | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A                 |
        !          2439:                +---------------------------------------------------+
        !          2440:     Answer     | <empty>                                           |
        !          2441:                +---------------------------------------------------+
        !          2442:     Authority  | MIL.             86400 IN NS       SRI-NIC.ARPA.  |
        !          2443:                |                  86400    NS       A.ISI.EDU.     |
        !          2444:                +---------------------------------------------------+
        !          2445:     Additional | A.ISI.EDU.                A        26.3.0.103     |
        !          2446:                | SRI-NIC.ARPA.             A        26.0.0.73      |
        !          2447:                |                           A        10.0.0.51      |
        !          2448:                +---------------------------------------------------+
        !          2449: 
        !          2450: This response has an empty answer section, but is not authoritative, so
        !          2451: it is a referral.  The name server on C.ISI.EDU, realizing that it is
        !          2452: not authoritative for the MIL domain, has referred the requester to
        !          2453: servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative
        !          2454: for the MIL domain.
        !          2455: 
        !          2456: 
        !          2457: 
        !          2458: 
        !          2459: 
        !          2460: Mockapetris                                                    [Page 44]
        !          2461: 
        !          2462: RFC 1034             Domain Concepts and Facilities        November 1987
        !          2463: 
        !          2464: 
        !          2465: 6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A
        !          2466: 
        !          2467: The response to this query from A.ISI.EDU would be:
        !          2468: 
        !          2469:                +---------------------------------------------------+
        !          2470:     Header     | OPCODE=SQUERY, RESPONSE, AA                       |
        !          2471:                +---------------------------------------------------+
        !          2472:     Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
        !          2473:                +---------------------------------------------------+
        !          2474:     Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
        !          2475:                | C.ISI.EDU.     86400 IN A          10.0.0.52      |
        !          2476:                +---------------------------------------------------+
        !          2477:     Authority  | <empty>                                           |
        !          2478:                +---------------------------------------------------+
        !          2479:     Additional | <empty>                                           |
        !          2480:                +---------------------------------------------------+
        !          2481: 
        !          2482: Note that the AA bit in the header guarantees that the data matching
        !          2483: QNAME is authoritative, but does not say anything about whether the data
        !          2484: for C.ISI.EDU is authoritative.  This complete reply is possible because
        !          2485: A.ISI.EDU happens to be authoritative for both the ARPA domain where
        !          2486: USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is
        !          2487: found.
        !          2488: 
        !          2489: If the same query was sent to C.ISI.EDU, its response might be the same
        !          2490: as shown above if it had its own address in its cache, but might also
        !          2491: be:
        !          2492: 
        !          2493: 
        !          2494: 
        !          2495: 
        !          2496: 
        !          2497: 
        !          2498: 
        !          2499: 
        !          2500: 
        !          2501: 
        !          2502: 
        !          2503: 
        !          2504: 
        !          2505: 
        !          2506: 
        !          2507: 
        !          2508: 
        !          2509: 
        !          2510: 
        !          2511: 
        !          2512: 
        !          2513: 
        !          2514: 
        !          2515: 
        !          2516: Mockapetris                                                    [Page 45]
        !          2517: 
        !          2518: RFC 1034             Domain Concepts and Facilities        November 1987
        !          2519: 
        !          2520: 
        !          2521:                +---------------------------------------------------+
        !          2522:     Header     | OPCODE=SQUERY, RESPONSE, AA                       |
        !          2523:                +---------------------------------------------------+
        !          2524:     Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
        !          2525:                +---------------------------------------------------+
        !          2526:     Answer     | USC-ISIC.ARPA.   86400 IN CNAME   C.ISI.EDU.      |
        !          2527:                +---------------------------------------------------+
        !          2528:     Authority  | ISI.EDU.        172800 IN NS      VAXA.ISI.EDU.   |
        !          2529:                |                           NS      A.ISI.EDU.      |
        !          2530:                |                           NS      VENERA.ISI.EDU. |
        !          2531:                +---------------------------------------------------+
        !          2532:     Additional | VAXA.ISI.EDU.   172800    A       10.2.0.27       |
        !          2533:                |                 172800    A       128.9.0.33      |
        !          2534:                | VENERA.ISI.EDU. 172800    A       10.1.0.52       |
        !          2535:                |                 172800    A       128.9.0.32      |
        !          2536:                | A.ISI.EDU.      172800    A       26.3.0.103      |
        !          2537:                +---------------------------------------------------+
        !          2538: 
        !          2539: This reply contains an authoritative reply for the alias USC-ISIC.ARPA,
        !          2540: plus a referral to the name servers for ISI.EDU.  This sort of reply
        !          2541: isn't very likely given that the query is for the host name of the name
        !          2542: server being asked, but would be common for other aliases.
        !          2543: 
        !          2544: 6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME
        !          2545: 
        !          2546: If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would
        !          2547: be:
        !          2548: 
        !          2549:                +---------------------------------------------------+
        !          2550:     Header     | OPCODE=SQUERY, RESPONSE, AA                       |
        !          2551:                +---------------------------------------------------+
        !          2552:     Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
        !          2553:                +---------------------------------------------------+
        !          2554:     Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
        !          2555:                +---------------------------------------------------+
        !          2556:     Authority  | <empty>                                           |
        !          2557:                +---------------------------------------------------+
        !          2558:     Additional | <empty>                                           |
        !          2559:                +---------------------------------------------------+
        !          2560: 
        !          2561: Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name
        !          2562: server doesn't attempt to look up anything for C.ISI.EDU.  (Except
        !          2563: possibly for the additional section.)
        !          2564: 
        !          2565: 6.3. Example resolution
        !          2566: 
        !          2567: The following examples illustrate the operations a resolver must perform
        !          2568: for its client.  We assume that the resolver is starting without a
        !          2569: 
        !          2570: 
        !          2571: 
        !          2572: Mockapetris                                                    [Page 46]
        !          2573: 
        !          2574: RFC 1034             Domain Concepts and Facilities        November 1987
        !          2575: 
        !          2576: 
        !          2577: cache, as might be the case after system boot.  We further assume that
        !          2578: the system is not one of the hosts in the data and that the host is
        !          2579: located somewhere on net 26, and that its safety belt (SBELT) data
        !          2580: structure has the following information:
        !          2581: 
        !          2582:     Match count = -1
        !          2583:     SRI-NIC.ARPA.   26.0.0.73       10.0.0.51
        !          2584:     A.ISI.EDU.      26.3.0.103
        !          2585: 
        !          2586: This information specifies servers to try, their addresses, and a match
        !          2587: count of -1, which says that the servers aren't very close to the
        !          2588: target.  Note that the -1 isn't supposed to be an accurate closeness
        !          2589: measure, just a value so that later stages of the algorithm will work.
        !          2590: 
        !          2591: The following examples illustrate the use of a cache, so each example
        !          2592: assumes that previous requests have completed.
        !          2593: 
        !          2594: 6.3.1. Resolve MX for ISI.EDU.
        !          2595: 
        !          2596: Suppose the first request to the resolver comes from the local mailer,
        !          2597: which has mail for [email protected].  The mailer might then ask for type MX
        !          2598: RRs for the domain name ISI.EDU.
        !          2599: 
        !          2600: The resolver would look in its cache for MX RRs at ISI.EDU, but the
        !          2601: empty cache wouldn't be helpful.  The resolver would recognize that it
        !          2602: needed to query foreign servers and try to determine the best servers to
        !          2603: query.  This search would look for NS RRs for the domains ISI.EDU, EDU,
        !          2604: and the root.  These searches of the cache would also fail.  As a last
        !          2605: resort, the resolver would use the information from the SBELT, copying
        !          2606: it into its SLIST structure.
        !          2607: 
        !          2608: At this point the resolver would need to pick one of the three available
        !          2609: addresses to try.  Given that the resolver is on net 26, it should
        !          2610: choose either 26.0.0.73 or 26.3.0.103 as its first choice.  It would
        !          2611: then send off a query of the form:
        !          2612: 
        !          2613: 
        !          2614: 
        !          2615: 
        !          2616: 
        !          2617: 
        !          2618: 
        !          2619: 
        !          2620: 
        !          2621: 
        !          2622: 
        !          2623: 
        !          2624: 
        !          2625: 
        !          2626: 
        !          2627: 
        !          2628: Mockapetris                                                    [Page 47]
        !          2629: 
        !          2630: RFC 1034             Domain Concepts and Facilities        November 1987
        !          2631: 
        !          2632: 
        !          2633:                +---------------------------------------------------+
        !          2634:     Header     | OPCODE=SQUERY                                     |
        !          2635:                +---------------------------------------------------+
        !          2636:     Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
        !          2637:                +---------------------------------------------------+
        !          2638:     Answer     | <empty>                                           |
        !          2639:                +---------------------------------------------------+
        !          2640:     Authority  | <empty>                                           |
        !          2641:                +---------------------------------------------------+
        !          2642:     Additional | <empty>                                           |
        !          2643:                +---------------------------------------------------+
        !          2644: 
        !          2645: The resolver would then wait for a response to its query or a timeout.
        !          2646: If the timeout occurs, it would try different servers, then different
        !          2647: addresses of the same servers, lastly retrying addresses already tried.
        !          2648: It might eventually receive a reply from SRI-NIC.ARPA:
        !          2649: 
        !          2650:                +---------------------------------------------------+
        !          2651:     Header     | OPCODE=SQUERY, RESPONSE                           |
        !          2652:                +---------------------------------------------------+
        !          2653:     Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
        !          2654:                +---------------------------------------------------+
        !          2655:     Answer     | <empty>                                           |
        !          2656:                +---------------------------------------------------+
        !          2657:     Authority  | ISI.EDU.        172800 IN NS       VAXA.ISI.EDU.  |
        !          2658:                |                           NS       A.ISI.EDU.     |
        !          2659:                |                           NS       VENERA.ISI.EDU.|
        !          2660:                +---------------------------------------------------+
        !          2661:     Additional | VAXA.ISI.EDU.   172800    A        10.2.0.27      |
        !          2662:                |                 172800    A        128.9.0.33     |
        !          2663:                | VENERA.ISI.EDU. 172800    A        10.1.0.52      |
        !          2664:                |                 172800    A        128.9.0.32     |
        !          2665:                | A.ISI.EDU.      172800    A        26.3.0.103     |
        !          2666:                +---------------------------------------------------+
        !          2667: 
        !          2668: The resolver would notice that the information in the response gave a
        !          2669: closer delegation to ISI.EDU than its existing SLIST (since it matches
        !          2670: three labels).  The resolver would then cache the information in this
        !          2671: response and use it to set up a new SLIST:
        !          2672: 
        !          2673:     Match count = 3
        !          2674:     A.ISI.EDU.      26.3.0.103
        !          2675:     VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
        !          2676:     VENERA.ISI.EDU. 10.1.0.52       128.9.0.32
        !          2677: 
        !          2678: A.ISI.EDU appears on this list as well as the previous one, but that is
        !          2679: purely coincidental.  The resolver would again start transmitting and
        !          2680: waiting for responses.  Eventually it would get an answer:
        !          2681: 
        !          2682: 
        !          2683: 
        !          2684: Mockapetris                                                    [Page 48]
        !          2685: 
        !          2686: RFC 1034             Domain Concepts and Facilities        November 1987
        !          2687: 
        !          2688: 
        !          2689:                +---------------------------------------------------+
        !          2690:     Header     | OPCODE=SQUERY, RESPONSE, AA                       |
        !          2691:                +---------------------------------------------------+
        !          2692:     Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
        !          2693:                +---------------------------------------------------+
        !          2694:     Answer     | ISI.EDU.                MX 10 VENERA.ISI.EDU.     |
        !          2695:                |                         MX 20 VAXA.ISI.EDU.       |
        !          2696:                +---------------------------------------------------+
        !          2697:     Authority  | <empty>                                           |
        !          2698:                +---------------------------------------------------+
        !          2699:     Additional | VAXA.ISI.EDU.   172800  A  10.2.0.27              |
        !          2700:                |                 172800  A  128.9.0.33             |
        !          2701:                | VENERA.ISI.EDU. 172800  A  10.1.0.52              |
        !          2702:                |                 172800  A  128.9.0.32             |
        !          2703:                +---------------------------------------------------+
        !          2704: 
        !          2705: The resolver would add this information to its cache, and return the MX
        !          2706: RRs to its client.
        !          2707: 
        !          2708: 6.3.2. Get the host name for address 26.6.0.65
        !          2709: 
        !          2710: The resolver would translate this into a request for PTR RRs for
        !          2711: 65.0.6.26.IN-ADDR.ARPA.  This information is not in the cache, so the
        !          2712: resolver would look for foreign servers to ask.  No servers would match,
        !          2713: so it would use SBELT again.  (Note that the servers for the ISI.EDU
        !          2714: domain are in the cache, but ISI.EDU is not an ancestor of
        !          2715: 65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.)
        !          2716: 
        !          2717: Since this request is within the authoritative data of both servers in
        !          2718: SBELT, eventually one would return:
        !          2719: 
        !          2720: 
        !          2721: 
        !          2722: 
        !          2723: 
        !          2724: 
        !          2725: 
        !          2726: 
        !          2727: 
        !          2728: 
        !          2729: 
        !          2730: 
        !          2731: 
        !          2732: 
        !          2733: 
        !          2734: 
        !          2735: 
        !          2736: 
        !          2737: 
        !          2738: 
        !          2739: 
        !          2740: Mockapetris                                                    [Page 49]
        !          2741: 
        !          2742: RFC 1034             Domain Concepts and Facilities        November 1987
        !          2743: 
        !          2744: 
        !          2745:                +---------------------------------------------------+
        !          2746:     Header     | OPCODE=SQUERY, RESPONSE, AA                       |
        !          2747:                +---------------------------------------------------+
        !          2748:     Question   | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR |
        !          2749:                +---------------------------------------------------+
        !          2750:     Answer     | 65.0.6.26.IN-ADDR.ARPA.    PTR     ACC.ARPA.      |
        !          2751:                +---------------------------------------------------+
        !          2752:     Authority  | <empty>                                           |
        !          2753:                +---------------------------------------------------+
        !          2754:     Additional | <empty>                                           |
        !          2755:                +---------------------------------------------------+
        !          2756: 
        !          2757: 6.3.3. Get the host address of poneria.ISI.EDU
        !          2758: 
        !          2759: This request would translate into a type A request for poneria.ISI.EDU.
        !          2760: The resolver would not find any cached data for this name, but would
        !          2761: find the NS RRs in the cache for ISI.EDU when it looks for foreign
        !          2762: servers to ask.  Using this data, it would construct a SLIST of the
        !          2763: form:
        !          2764: 
        !          2765:     Match count = 3
        !          2766: 
        !          2767:     A.ISI.EDU.      26.3.0.103
        !          2768:     VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
        !          2769:     VENERA.ISI.EDU. 10.1.0.52
        !          2770: 
        !          2771: A.ISI.EDU is listed first on the assumption that the resolver orders its
        !          2772: choices by preference, and A.ISI.EDU is on the same network.
        !          2773: 
        !          2774: One of these servers would answer the query.
        !          2775: 
        !          2776: 7. REFERENCES and BIBLIOGRAPHY
        !          2777: 
        !          2778: [Dyer 87]       Dyer, S., and F. Hsu, "Hesiod", Project Athena
        !          2779:                 Technical Plan - Name Service, April 1987, version 1.9.
        !          2780: 
        !          2781:                 Describes the fundamentals of the Hesiod name service.
        !          2782: 
        !          2783: [IEN-116]       J. Postel, "Internet Name Server", IEN-116,
        !          2784:                 USC/Information Sciences Institute, August 1979.
        !          2785: 
        !          2786:                 A name service obsoleted by the Domain Name System, but
        !          2787:                 still in use.
        !          2788: 
        !          2789: 
        !          2790: 
        !          2791: 
        !          2792: 
        !          2793: 
        !          2794: 
        !          2795: 
        !          2796: Mockapetris                                                    [Page 50]
        !          2797: 
        !          2798: RFC 1034             Domain Concepts and Facilities        November 1987
        !          2799: 
        !          2800: 
        !          2801: [Quarterman 86] Quarterman, J., and J. Hoskins, "Notable Computer
        !          2802:                 Networks",Communications of the ACM, October 1986,
        !          2803:                 volume 29, number 10.
        !          2804: 
        !          2805: [RFC-742]       K. Harrenstien, "NAME/FINGER", RFC-742, Network
        !          2806:                 Information Center, SRI International, December 1977.
        !          2807: 
        !          2808: [RFC-768]       J. Postel, "User Datagram Protocol", RFC-768,
        !          2809:                 USC/Information Sciences Institute, August 1980.
        !          2810: 
        !          2811: [RFC-793]       J. Postel, "Transmission Control Protocol", RFC-793,
        !          2812:                 USC/Information Sciences Institute, September 1981.
        !          2813: 
        !          2814: [RFC-799]       D. Mills, "Internet Name Domains", RFC-799, COMSAT,
        !          2815:                 September 1981.
        !          2816: 
        !          2817:                 Suggests introduction of a hierarchy in place of a flat
        !          2818:                 name space for the Internet.
        !          2819: 
        !          2820: [RFC-805]       J. Postel, "Computer Mail Meeting Notes", RFC-805,
        !          2821:                 USC/Information Sciences Institute, February 1982.
        !          2822: 
        !          2823: [RFC-810]       E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
        !          2824:                 Internet Host Table Specification", RFC-810, Network
        !          2825:                 Information Center, SRI International, March 1982.
        !          2826: 
        !          2827:                 Obsolete.  See RFC-952.
        !          2828: 
        !          2829: [RFC-811]       K. Harrenstien, V. White, and E. Feinler, "Hostnames
        !          2830:                 Server", RFC-811, Network Information Center, SRI
        !          2831:                 International, March 1982.
        !          2832: 
        !          2833:                 Obsolete.  See RFC-953.
        !          2834: 
        !          2835: [RFC-812]       K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
        !          2836:                 Network Information Center, SRI International, March
        !          2837:                 1982.
        !          2838: 
        !          2839: [RFC-819]       Z. Su, and J. Postel, "The Domain Naming Convention for
        !          2840:                 Internet User Applications", RFC-819, Network
        !          2841:                 Information Center, SRI International, August 1982.
        !          2842: 
        !          2843:                 Early thoughts on the design of the domain system.
        !          2844:                 Current implementation is completely different.
        !          2845: 
        !          2846: [RFC-821]       J. Postel, "Simple Mail Transfer Protocol", RFC-821,
        !          2847:                 USC/Information Sciences Institute, August 1980.
        !          2848: 
        !          2849: 
        !          2850: 
        !          2851: 
        !          2852: Mockapetris                                                    [Page 51]
        !          2853: 
        !          2854: RFC 1034             Domain Concepts and Facilities        November 1987
        !          2855: 
        !          2856: 
        !          2857: [RFC-830]       Z. Su, "A Distributed System for Internet Name Service",
        !          2858:                 RFC-830, Network Information Center, SRI International,
        !          2859:                 October 1982.
        !          2860: 
        !          2861:                 Early thoughts on the design of the domain system.
        !          2862:                 Current implementation is completely different.
        !          2863: 
        !          2864: [RFC-882]       P. Mockapetris, "Domain names - Concepts and
        !          2865:                 Facilities," RFC-882, USC/Information Sciences
        !          2866:                 Institute, November 1983.
        !          2867: 
        !          2868:                 Superceeded by this memo.
        !          2869: 
        !          2870: [RFC-883]       P. Mockapetris, "Domain names - Implementation and
        !          2871:                 Specification," RFC-883, USC/Information Sciences
        !          2872:                 Institute, November 1983.
        !          2873: 
        !          2874:                 Superceeded by this memo.
        !          2875: 
        !          2876: [RFC-920]       J. Postel and J. Reynolds, "Domain Requirements",
        !          2877:                 RFC-920, USC/Information Sciences Institute
        !          2878:                 October 1984.
        !          2879: 
        !          2880:                 Explains the naming scheme for top level domains.
        !          2881: 
        !          2882: [RFC-952]       K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
        !          2883:                 Table Specification", RFC-952, SRI, October 1985.
        !          2884: 
        !          2885:                 Specifies the format of HOSTS.TXT, the host/address
        !          2886:                 table replaced by the DNS.
        !          2887: 
        !          2888: [RFC-953]       K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
        !          2889:                 RFC-953, SRI, October 1985.
        !          2890: 
        !          2891:                 This RFC contains the official specification of the
        !          2892:                 hostname server protocol, which is obsoleted by the DNS.
        !          2893:                 This TCP based protocol accesses information stored in
        !          2894:                 the RFC-952 format, and is used to obtain copies of the
        !          2895:                 host table.
        !          2896: 
        !          2897: [RFC-973]       P. Mockapetris, "Domain System Changes and
        !          2898:                 Observations", RFC-973, USC/Information Sciences
        !          2899:                 Institute, January 1986.
        !          2900: 
        !          2901:                 Describes changes to RFC-882 and RFC-883 and reasons for
        !          2902:                 them.  Now obsolete.
        !          2903: 
        !          2904: 
        !          2905: 
        !          2906: 
        !          2907: 
        !          2908: Mockapetris                                                    [Page 52]
        !          2909: 
        !          2910: RFC 1034             Domain Concepts and Facilities        November 1987
        !          2911: 
        !          2912: 
        !          2913: [RFC-974]       C. Partridge, "Mail routing and the domain system",
        !          2914:                 RFC-974, CSNET CIC BBN Labs, January 1986.
        !          2915: 
        !          2916:                 Describes the transition from HOSTS.TXT based mail
        !          2917:                 addressing to the more powerful MX system used with the
        !          2918:                 domain system.
        !          2919: 
        !          2920: [RFC-1001]      NetBIOS Working Group, "Protocol standard for a NetBIOS
        !          2921:                 service on a TCP/UDP transport: Concepts and Methods",
        !          2922:                 RFC-1001, March 1987.
        !          2923: 
        !          2924:                 This RFC and RFC-1002 are a preliminary design for
        !          2925:                 NETBIOS on top of TCP/IP which proposes to base NetBIOS
        !          2926:                 name service on top of the DNS.
        !          2927: 
        !          2928: [RFC-1002]      NetBIOS Working Group, "Protocol standard for a NetBIOS
        !          2929:                 service on a TCP/UDP transport: Detailed
        !          2930:                 Specifications", RFC-1002, March 1987.
        !          2931: 
        !          2932: [RFC-1010]      J. Reynolds and J. Postel, "Assigned Numbers", RFC-1010,
        !          2933:                 USC/Information Sciences Institute, May 1987
        !          2934: 
        !          2935:                 Contains socket numbers and mnemonics for host names,
        !          2936:                 operating systems, etc.
        !          2937: 
        !          2938: [RFC-1031]      W. Lazear, "MILNET Name Domain Transition", RFC-1031,
        !          2939:                 November 1987.
        !          2940: 
        !          2941:                 Describes a plan for converting the MILNET to the DNS.
        !          2942: 
        !          2943: [RFC-1032]      M. K. Stahl, "Establishing a Domain - Guidelines for
        !          2944:                 Administrators", RFC-1032, November 1987.
        !          2945: 
        !          2946:                 Describes the registration policies used by the NIC to
        !          2947:                 administer the top level domains and delegate subzones.
        !          2948: 
        !          2949: [RFC-1033]      M. K. Lottor, "Domain Administrators Operations Guide",
        !          2950:                 RFC-1033, November 1987.
        !          2951: 
        !          2952:                 A cookbook for domain administrators.
        !          2953: 
        !          2954: [Solomon 82]    M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
        !          2955:                 Name Server", Computer Networks, vol 6, nr 3, July 1982.
        !          2956: 
        !          2957:                 Describes a name service for CSNET which is independent
        !          2958:                 from the DNS and DNS use in the CSNET.
        !          2959: 
        !          2960: 
        !          2961: 
        !          2962: 
        !          2963: 
        !          2964: Mockapetris                                                    [Page 53]
        !          2965: 
        !          2966: RFC 1034             Domain Concepts and Facilities        November 1987
        !          2967: 
        !          2968: 
        !          2969: Index
        !          2970: 
        !          2971:           A   12
        !          2972:           Absolute names   8
        !          2973:           Aliases   14, 31
        !          2974:           Authority   6
        !          2975:           AXFR   17
        !          2976: 
        !          2977:           Case of characters   7
        !          2978:           CH   12
        !          2979:           CNAME   12, 13, 31
        !          2980:           Completion queries   18
        !          2981: 
        !          2982:           Domain name   6, 7
        !          2983: 
        !          2984:           Glue RRs   20
        !          2985: 
        !          2986:           HINFO   12
        !          2987: 
        !          2988:           IN   12
        !          2989:           Inverse queries   16
        !          2990:           Iterative   4
        !          2991: 
        !          2992:           Label   7
        !          2993: 
        !          2994:           Mailbox names   9
        !          2995:           MX   12
        !          2996: 
        !          2997:           Name error   27, 36
        !          2998:           Name servers   5, 17
        !          2999:           NE   30
        !          3000:           Negative caching   44
        !          3001:           NS   12
        !          3002: 
        !          3003:           Opcode   16
        !          3004: 
        !          3005:           PTR   12
        !          3006: 
        !          3007:           QCLASS   16
        !          3008:           QTYPE   16
        !          3009: 
        !          3010:           RDATA   13
        !          3011:           Recursive   4
        !          3012:           Recursive service   22
        !          3013:           Relative names   7
        !          3014:           Resolvers   6
        !          3015:           RR   12
        !          3016: 
        !          3017: 
        !          3018: 
        !          3019: 
        !          3020: Mockapetris                                                    [Page 54]
        !          3021: 
        !          3022: RFC 1034             Domain Concepts and Facilities        November 1987
        !          3023: 
        !          3024: 
        !          3025:           Safety belt   33
        !          3026:           Sections   16
        !          3027:           SOA   12
        !          3028:           Standard queries   22
        !          3029: 
        !          3030:           Status queries   18
        !          3031:           Stub resolvers   32
        !          3032: 
        !          3033:           TTL   12, 13
        !          3034: 
        !          3035:           Wildcards   25
        !          3036: 
        !          3037:           Zone transfers   28
        !          3038:           Zones   19
        !          3039: 
        !          3040: 
        !          3041: 
        !          3042: 
        !          3043: 
        !          3044: 
        !          3045: 
        !          3046: 
        !          3047: 
        !          3048: 
        !          3049: 
        !          3050: 
        !          3051: 
        !          3052: 
        !          3053: 
        !          3054: 
        !          3055: 
        !          3056: 
        !          3057: 
        !          3058: 
        !          3059: 
        !          3060: 
        !          3061: 
        !          3062: 
        !          3063: 
        !          3064: 
        !          3065: 
        !          3066: 
        !          3067: 
        !          3068: 
        !          3069: 
        !          3070: 
        !          3071: 
        !          3072: 
        !          3073: 
        !          3074: 
        !          3075: 
        !          3076: Mockapetris                                                    [Page 55]
        !          3077: 

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