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

`
`
`RFC 882 November 1983
` Domain Names - Concepts and Facilities
`
` mailbox names, they have also created an increasingly large and
` irregular set of methods for identifying the location of a
` mailbox. Some of these methods involve the use of routes and
` forwarding hosts as part of the mail destination address, and
` consequently force the mail user to know multiple address formats,
` the capabilities of various forwarders, and ad hoc tricks for
` passing address specifications through intermediaries.
`
` These problems have common characteristics that suggest the nature
` of any solution:
`
` The basic need is for a consistent name space which will be
` used for referring to resources. In order to avoid the
` problems caused by ad hoc encodings, names should not contain
` addresses, routes, or similar information as part of the name.
`
` The sheer size of the database and frequency of updates suggest
` that it must be maintained in a distributed manner, with local
` caching to improve performance. Approaches that attempt to
` collect a consistent copy of the entire database will become
` more and more expensive and difficult, and hence should be
` avoided. The same principle holds for the structure of the
` name space, and in particular mechanisms for creating and
` deleting names; these should also be distributed.
`
` The costs of implementing such a facility dictate that it be
` generally useful, and not restricted to a single application.
` We should be able to use names to retrieve host addresses,
` mailbox data, and other as yet undetermined information.
`
` Because we want the name space to be useful in dissimilar
` networks, it is unlikely that all users of domain names will be
` able to agree on the set of resources or resource information
` that names will be used to retrieve. Hence names refer to a
` set of resources, and queries contain resource identifiers.
` The only standard types of information that we expect to see
` throughout the name space is structuring information for the
` name space itself, and resources that are described using
` domain names and no nonstandard data.
`
` We also want the name server transactions to be independent of
` the communications system that carries them. Some systems may
` wish to use datagrams for simple queries and responses, and
` only establish virtual circuits for transactions that need the
` reliability (e.g. database updates, long transactions); other
` systems will use virtual circuits exclusively.
`
`Mockapetris [Page 2]
`
`Petitioner Apple Inc. - Ex. 1032, p. 2
`
`

`
`
`RFC 882 November 1983
` Domain Names - Concepts and Facilities
`
` Elements of the solution
`
` The proposed solution has three major components:
`
` The DOMAIN NAME SPACE, which is a specification for a tree
` structured name space. Conceptually, each node and leaf of the
` domain name space tree names a set of information, and query
` operations are attempts to extract specific types of
` information from a particular set. A query names the domain
` name of interest and describes the type of resource information
` that is desired. For example, the ARPA Internet uses some of
` its domain names to identify hosts; queries for address
` resources return ARPA Internet host addresses. However, to
` preserve the generality of the domain mechanism, domain names
` are not required to have a one-to-one correspondence with host
` names, host addresses, or any other type of information.
`
` NAME SERVERS are server programs which hold information about
` the domain tree’s structure and set information. A name server
` may cache structure or set information about any part of the
` domain tree, but in general a particular name server has
` complete information about a subset of the domain space, and
` pointers to other name servers that can be used to lead to
` information from any part of the domain tree. Name servers
` know the parts of the domain tree for which they have complete
` information; these parts are called ZONEs; a name server is an
` AUTHORITY for these parts of the name space.
`
` RESOLVERS are programs that extract information from name
` servers in response to user requests. Resolvers must be able
` to access at least one name server and use that name server’s
` information to answer a query directly, or pursue the query
` using referrals to other name servers. A resolver will
` typically be a system routine that is directly accessible to
` user programs; hence no protocol is necessary between the
` resolver and the user program.
`
` These three components roughly correspond to the three layers or
` views of the domain system:
`
` From the user’s point of view, the domain system is accessed
` through simple procedure or OS calls to resolvers. The domain
` space consists of a single tree and the user can request
` information from any section of the tree.
`
` From the resolver’s point of view, the domain system is
` composed of an unknown number of name servers. Each name
` server has one or more pieces of the whole domain tree’s data,
`
`Mockapetris [Page 3]
`
`Petitioner Apple Inc. - Ex. 1032, p. 3
`
`

`
`
`RFC 882 November 1983
` Domain Names - Concepts and Facilities
`
` but the resolver views each of these databases as essentially
` static.
`
` From a name server’s point of view, the domain system consists
` of separate sets of local information called zones. The name
` server has local copies of some of the zones. The name server
` must periodically refresh its zones from master copies in local
` files or foreign name servers. The name server must
` concurrently process queries that arrive from resolvers using
` the local zones.
`
` In the interests of performance, these layers blur a bit. For
` example, resolvers on the same machine as a name server may share
` a database and may also introduce foreign information for use in
` later queries. This cached information is treated differently
` from the authoritative data in zones.
`
` Database model
`
` The organization of the domain system derives from some
` assumptions about the needs and usage patterns of its user
` community and is designed to avoid many of the the complicated
` problems found in general purpose database systems.
`
` The assumptions are:
`
` The size of the total database will initially be proportional
` to the number of hosts using the system, but will eventually
` grow to be proportional to the number of users on those hosts
` as mailboxes and other information are added to the domain
` system.
`
` Most of the data in the system will change very slowly (e.g.,
` mailbox bindings, host addresses), but that the system should
` be able to deal with subsets that change more rapidly (on the
` order of minutes).
`
` The administrative boundaries used to distribute responsibility
` for the database will usually correspond to organizations that
` have one or more hosts. Each organization that has
` responsibility for a particular set of domains will provide
` redundant name servers, either on the organization’s own hosts
` or other hosts that the organization arranges to use.
`
` Clients of the domain system should be able to identify trusted
` name servers they prefer to use before accepting referrals to
` name servers outside of this "trusted" set.
`
` Access to information is more critical than instantaneous
`
`Mockapetris [Page 4]
`
`Petitioner Apple Inc. - Ex. 1032, p. 4
`
`

`
`
`RFC 882 November 1983
` Domain Names - Concepts and Facilities
`
` updates or guarantees of consistency. Hence the update process
` allows updates to percolate out though the users of the domain
` system rather than guaranteeing that all copies are
` simultaneously updated. When updates are unavailable due to
` network or host failure, the usual course is to believe old
` information while continuing efforts to update it. The general
` model is that copies are distributed with timeouts for
` refreshing. The distributor sets the timeout value and the
` recipient of the distribution is responsible for performing the
` refresh. In special situations, very short intervals can be
` specified, or the owner can prohibit copies.
`
` Some users will wish to access the database via datagrams;
` others will prefer virtual circuits. The domain system is
` designed so that simple queries and responses can use either
` style, although refreshing operations need the reliability of
` virtual circuits. The same overall message format is used for
` all communication. The domain system does not assume any
` special properties of the communications system, and hence
` could be used with any datagram or virtual circuit protocol.
`
` In any system that has a distributed database, a particular
` name server may be presented with a query that can only be
` answered by some other server. The two general approaches to
` dealing with this problem are "recursive", in which the first
` server pursues the query for the client at another server, and
` "iterative", in which the server refers the client to another
` server and lets the client pursue the query. Both approaches
` have advantages and disadvantages, but the iterative approach
` is preferred for the datagram style of access. The domain
` system requires implementation of the iterative approach, but
` allows the recursive approach as an option. The optional
` recursive style is discussed in [14], and omitted from further
` discussion in this memo.
`
` The domain system assumes that all data originates in master files
` scattered through the hosts that use the domain system. These
` master files are updated by local system administrators. Master
` files are text files that are read by a local name server, and
` hence become available to users of the domain system. A standard
` format for these files is given in [14].
`
` The standard format allows these files to be exchanged between
` hosts (via FTP, mail, or some other mechanism); this facility is
` useful when an organization wants a domain, but doesn’t want to
` support a name server. The organization can maintain the master
` files locally using a text editor, transfer them to a foreign host
` which runs a name server, and then arrange with the system
` administrator of the name server to get the files loaded.
`
`Mockapetris [Page 5]
`
`Petitioner Apple Inc. - Ex. 1032, p. 5
`
`

`
`
`RFC 882 November 1983
` Domain Names - Concepts and Facilities
`
` Each host’s name servers and resolvers are configured by a local
` system administrator. For a name server, this configuration data
` includes the identity of local master files and instructions on
` which non-local master files are to be loaded from foreign
` servers. The name server uses the master files or copies to load
` its zones. For resolvers, the configuration data identifies the
` name servers which should be the primary sources of information.
`
` The domain system defines procedures for accessing the data and
` for referrals to other name servers. The domain system also
` defines procedures for caching retrieved data and for periodic
` refreshing of data defined by the system administrator.
`
` The system administrators provide:
`
` The definition of zone boundaries
`
` Master files of data
`
` Updates to master files
`
` Statements of the refresh policies desired
`
` The domain system provides:
`
` Standard formats for resource data
`
` Standard methods for querying the database
`
` Standard methods for name servers to refresh local data from
` foreign name servers
`
`DOMAIN NAME SPACE
`
` Name space specifications and terminology
`
` The domain name space is a tree structure. Each node and leaf on
` the tree corresponds to a resource set (which may be empty). Each
` node and leaf has an associated label. Labels are NOT guaranteed
` to be unique, with the exception of the root node, which has a
` null label. The domain name of a node or leaf is the path from
` the root of the tree to the node or leaf. By convention, the
` labels that compose a domain name are read left to right, from the
` most specific (lowest) to the least specific (highest).
`
` Internally, programs that manipulate domain names represent them
` as sequences of labels, where each label is a length octet
` followed by an octet string. Because all domain names end at the
` root, which has a null string for a label, these internal
`
`Mockapetris [Page 6]
`
`Petitioner Apple Inc. - Ex. 1032, p. 6
`
`

`
`
`RFC 882 November 1983
` Domain Names - Concepts and Facilities
`
` representations can use a length byte of zero to terminate a
` domain name. When domain names are printed, labels in a path are
` separated by dots ("."). The root label and its associated dot
` are omitted from printed domain names, but the root can be named
` by a null domain name (" " in this memo).
`
` To simplify implementations, the total number of octets that
` represent label octets and label lengths is limited to 255. Thus
` a printed domain name can be up to 254 characters.
`
` A special label is defined that matches any other label. This
` label is the asterisk or "*". An asterisk matches a single label.
` Thus *.ARPA matches FOO.ARPA, but does not match FOO.BAR.ARPA.
` The asterisk is mainly used to create default resource records at
` the boundary between protocol families, and requires prudence in
` its use.
`
` A domain is identified by a domain name, and consists of that part
` of the domain name space that is at or below the domain name which
` specifies the domain. A domain is a subdomain of another domain
` if it is contained within that domain. This relationship can be
` tested by seeing if the subdomain’s name has the containing
` domain’s name as the right part of its name. For example, A.B.C.D
` is a subdomain of B.C.D, C.D, D, and " ".
`
` This tree structure is intended to parallel the administrative
` organization and delegation of authority. Potentially, each node
` or leaf on the tree can create new subdomains ad infinitum. In
` practice, this delegation can be limited by the administrator of
` the name servers that manage the domain space and resource data.
`
` The following figure shows an example of a domain name space.
`
` |
` +------------------+------------------+
` | | |
` COLORS FLAVORS TRUTH
` | |
` +-----+-----+ |
` | | | NATURAL
` RED BLUE GREEN |
` |
` +---------------+---------------+
` | | |
` CHOCOLATE VANILLA STRAWBERRY
`
` In this example, the root domain has three immediate subdomains:
` COLORS, FLAVORS, and TRUTH. The FLAVORS domain has one immediate
` subdomain named NATURAL.FLAVORS. All of the leaves are also
`
`Mockapetris [Page 7]
`
`Petitioner Apple Inc. - Ex. 1032, p. 7
`
`

`
`
`RFC 882 November 1983
` Domain Names - Concepts and Facilities
`
` domains. This domain tree has the names " "(the root), COLORS,
` RED.COLORS, BLUE.COLORS, GREEN.COLORS, FLAVORS, NATURAL.FLAVORS,
` CHOCOLATE.NATURAL.FLAVORS, VANILLA.NATURAL.FLAVORS,
` STRAWBERRY.NATURAL.FLAVORS, and TRUTH. If we wished to add a new
` domain of ARTIFICIAL under FLAVORS, FLAVORS would typically be the
` administrative entity that would decide; if we wished to create
` CHIP and MOCHA names under CHOCOLATE, CHOCOLATE.NATURAL.FLAVORS
` would typically be the appropriate administrative entity.
`
` Resource set information
`
` A domain name identifies a set of resource information. The set
` of resource information associated with a particular name is
` composed of separate resource records (RRs).
`
` Each resource record has the following major components:
`
` The domain name which identifies resource set that holds this
` record, and hence the "owner" of the information. For example,
` a RR that specifies a host address has a domain name the
` specifies the host having that address. Thus F.ISI.ARPA might
` be the owner of a RR which specified an address field of
` 10.2.0.52. Since name servers typically store their resource
` information in tree structures paralleling the organization of
` the domain space, this information can usually be stored
` implicitly in the database; however it is always included in
` each resource record carried in a message.
`
` Other information used to manage the RR, such as length fields,
` timeouts, etc. This information is omitted in much of this
` memo, but is discussed in [14].
`
` A resource type field that specifies the type of the resource
` in this resource record. Types refer to abstract resources
` such as host addresses or mail delivery agents. The type field
` is two octets long and uses an encoding that is standard
` throughout the domain name system.
`
` A class field identifies the format of the resource data, such
` as the ARPA Internet format (IN) or the Computer Science
` Network format (CSNET), for certain RR types (such as address
` data). Note that while the class may separate different
` protocol families, networks, etc. it does not do so in all
` cases. For example, the IN class uses 32 bit IP addresses
` exclusively, but the CSNET class uses 32 bit IP addresses, X.25
` addresses, and phone numbers. Thus the class field should be
` used as a guide for interpreting the resource data. The class
` field is two octets long and uses an encoding that is standard
` throughout the domain name system.
`
`Mockapetris [Page 8]
`
`Petitioner Apple Inc. - Ex. 1032, p. 8
`
`

`
`
`RFC 882 November 1983
` Domain Names - Concepts and Facilities
`
` Resource data that describes the resource. The format of this
` data can be determined given the type and class fields, but
` always starts with a two octet length field that allows a name
` server or resolver to determine the boundaries of the resource
` data in any transaction, even if it cannot "understand" the
` resource data itself. Thus name servers and resolvers can hold
` and pass on records which they cannot interpret. The format of
` the internal data is restricted only by the maximum length of
` 65535 octets; for example the host address record might specify
` a fixed 32 bit number for one class, and a variable length list
` of addresses in another class.
`
` While the class field in effect partitions the resource data in
` the domain name system into separate parallel sections according
` to class, services can span class boundaries if they use
` compatible resource data formats. For example, the domain name
` system uses compatible formats for structure information, and the
` mail data decouples mail agent identification from details of how
` to contact the agent (e.g. host addresses).
`
` This memo uses the following types in its examples:
`
` A - the host address associated with the domain name
`
` MF - identifies a mail forwarder for the domain
`
` MD - identifies a mail destination for the domain
`
` NS - the authoritative name server for the domain
`
` SOA - identifies the start of a zone of authority
`
` CNAME - identifies the canonical name of an alias
`
` This memo uses the following classes in its examples:
`
` IN - the ARPA Internet system
`
` CS - the CSNET system
`
` The first type of resource record holds a host name to host
` address binding. Its fields are:
`
` +--------+--------+--------+--------------//----------------------+
` |<owner> | A | <class>| <class specific address>information |
` +--------+--------+--------+--------------//----------------------+
`
`Mockapetris [Page 9]
`
`Petitioner Apple Inc. - Ex. 1032, p. 9
`
`

`
`
`RFC 882 November 1983
` Domain Names - Concepts and Facilities
`
` The content of the class specific information varies according to
` the value in the CLASS field; for the ARPA Internet, it is the 32
` bit ARPA Internet address of the host, for the CSNET it might be
` the phone number of the host. For example, F.ISI.ARPA might have
` two A records of the form:
`
` +----------+--------+--------+----------------------------+
` |F.ISI.ARPA| A | IN | 10.2.0.52 |
` +----------+--------+--------+----------------------------+
` and
` +----------+--------+--------+----------------------------+
` |F.ISI.ARPA| A | CS | 213-822-2112 |
` +----------+--------+--------+----------------------------+
`
` Note that the data formats for the A type are class dependent, and
` the Internet address and phone number formats shown above are for
` purposes of illustration only. The actual data formats are
` specified in [14]. For example, CS class data for type A records
` might actually be a list of Internet addresses, phone numbers and
` TELENET addresses.
`
` The mail forwarder (MF) and mail delivery (MD) records have the
` following format:
`
` +--------+--------+--------+----------------------------+
` |<owner> | MD/MF | <class>| <domain name> |
` +--------+--------+--------+----------------------------+
`
` The <domain name> field is a domain name of the host that will
` handle mail; note that this domain name may be completely
` different from the domain name which names the resource record.
` For example, F.ISI.ARPA might have two records of the form:
`
` +----------+--------+--------+----------------------------+
` |F.ISI.ARPA| MD | IN | F.ISI.ARPA |
` +----------+--------+--------+----------------------------+
` and
` +----------+--------+--------+----------------------------+
` |F.ISI.ARPA| MF | IN | B.ISI.ARPA |
` +----------+--------+--------+----------------------------+
`
` These records mean that mail for F.ISI.ARPA can either be
` delivered to the host F.ISI.ARPA or forwarded to B.ISI.ARPA, which
` will accept responsibility for its eventual delivery. In
` principle, an additional name lookup is required to map the domain
` name of the host to the appropriate address, in practice this
` information is usually returned in the response to the mail query.
`
` The SOA and NS types of resource records are used to define limits
`
`Mockapetris [Page 10]
`
`Petitioner Apple Inc. - Ex. 1032, p. 10
`
`

`
`
`RFC 882 November 1983
` Domain Names - Concepts and Facilities
`
` of authority. The domain name given by the owner field of a SOA
` record is the start of a zone; the domain name given by the owner
` field of a NS record identifies a point in the name space where
` authority has been delegated, and hence marks the zone boundary.
` Except in the case where a name server delegates authority to
` itself, the SOA identifies the top limit of authority, and NS
` records define the first name outside of a zone. These resource
` records have a standard format for all of the name space:
`
` +----------+--------+--------+-----------------------------+
` | <owner> | SOA | <class>| <domain name, etc> |
` +----------+--------+--------+-----------------------------+
`
` +----------+--------+--------+-----------------------------+
` | <owner> | NS | <class>| <domain name> |
` +----------+--------+--------+-----------------------------+
`
` The SOA record marks the start of a zone when it is present in a
` database; the NS record both marks the end of a zone started by an
` SOA (if a higher SOA is present) and also points to a name server
` that has a copy of the zone specified by the <owner. field of the
` NS record.
`
` The <domain name, etc> in the SOA record specifies the original
` source of the information in the zone and other information used
` by name servers to organize their activities. SOA records are
` never cached (otherwise they would create false zones); they can
` only be created in special name server maintenance operations.
`
` The NS record says that a name server which is authoritative for
` records of the given CLASS can be found at <domain name>.
`
` Queries
`
` Queries to a name server must include a domain name which
` identifies the target resource set (QNAME), and the type and class
` of desired resource records. The type and class fields in a query
` can include any of the corresponding type and class fields that
` are defined for resource records; in addition, the query type
` (QTYPE) and query class (QCLASS) fields may contain special values
` that match more than one of the corresponding fields in RRs.
`
` For example, the QTYPE field may contain:
`
` MAILA - matches all mail agent RRs (e.g. MD and MF).
`
` * - matches any RR type.
`
`Mockapetris [Page 11]
`
`Petitioner Apple Inc. - Ex. 1032, p. 11
`
`

`
`
`RFC 882 November 1983
` Domain Names - Concepts and Facilities
`
` The QCLASS field may contain:
`
` * - matches any RR class.
`
` Using the query domain name, QTYPE, and QCLASS, the name server
` looks for matching RRs. In addition to relevant records, the name
` server may return RRs that point toward a name server that has the
` desired information or RRs that are expected to be useful in
` interpreting the relevant RRs. For example a name server that
` doesn’t have the requested information may know a name server that
` does; a name server that returns a domain name in a relevant RR
` may also return the RR that binds that domain name to an address.
`
` Note that the QCLASS=* construct requires special interpretation
` regarding authority. Since a name server may not know all of the
` classes available in the domain system, it can never know if it is
` authoritative for all classes. Hence responses to QCLASS=*
` queries can never be authoritative.
`
` Example space
`
` For purposes of exposition, the following name space is used for
` the remainder of this memo:
`
` |
` +------------------+------------------+
` | | |
` DDN ARPA CSNET
` | | |
` +-----+-----+ | +-----+-----+
` | | | | | |
` JCS ARMY NAV