Network Working Group
`Request for Comments: 1034
`Obsoletes: RFCs 882, 883, 973
`
`P. Mockapetris
`I81
`November 1987
`
`DOMAIN NAMES - CONCEPTS AND FACILITIES
`
`1. STATUS OF THIS MEMO
`
`This RFC is an introduction to the Domain Name System (DNS), and omits
`many details which can be found in a companion RFC,
`"Domain Names
`—
`Implementation and Specification" [RFC~1035]. That RFC assumes that the
`reader is familiar with the concepts discussed in this memo.
`
`A subset of DNS functions and data types constitute an official
`protocol.
`The official protocol
`includes standard queries and their
`responses and most of the Internet class data formats (e.g., host
`addresses).
`
`the domain system is intentionally extensible. Researchers are
`However,
`continuously proposing,
`implementing and experimenting with new data
`types, query types, classes,
`functions, etc.
`Thus while the components
`of the official protocol are expected to stay essentially unchanged and
`operate as a production service, experimental behavior should always be
`expected in extensions beyond the official protocol. Experimental or
`obsolete features are clearly marked in these RFCs, and such information
`should be used with caution.
`
`The reader is especially cautioned not to depend on the values which
`-appear in examples to be current or complete, since their purpose is
`primarily pedagogical. Distribution of this memo is unlimited.
`
`2.
`
`INTRODUCTION
`
`their use for Internet mail and
`This RFC introduces domain style names,
`host address support, and the protocols and servers used to implement
`domain name facilities.
`
`2.1. The history of domain names
`
`The impetus for the development of the domain system was growth in the
`Internet:
`
`— Host name to address mappings were maintained by the Network
`Information Center
`(NIC)
`in a single file (HOSTS,TXT) which
`was FTPed by all hosts [RFC-952, RFC—953].
`The total network
`
`Mockapetris
`
`_
`
`[Page 1]
`
`Page 1 of 56
`
`Verizon Exhibit 1014
`
`

`
`RFC 1034
`
`‘
`
`Domain Concepts and Facilities
`
`November 1987
`
`bandwidth consumed in distributing a new version by this
`scheme is proportional to the square of the number of hosts in
`the network, and even when multiple levels of FTP are used,
`the outgoing FTP load on the NIC host is considerable.
`Explosive growth in the number of hosts didn't bode well for
`the future.
`
`The
`— The network population was also changing in character.
`timeshared hosts that made up the original ARPANET were being
`replaced with local networks of workstations. Local
`organizations were administering their own names and
`addresses, but had to wait for the NIC to change HOSTS.TXT to
`make changes visible to the Internet at large. Organizations
`also wanted some local structure on the name space.
`
`— The applications on the Internet were getting more
`sophisticated and creating a need for general purpose name
`service.
`
`ideas about name spaces and their management
`The result was several
`[IEN—ll6, RFC-799, RFC—819, RFC—830].
`The proposals varied, but a
`common thread was the idea of a hierarchical name space, with the
`hierarchy roughly corresponding to organizational structure, and names
`using "."
`as the character to mark the boundary between hierarchy
`levels.
`A design using a distributed database and generalized resources
`was described in [RFC—882, RFC—883]. Based on experience with several
`implementations,
`the system evolved into the scheme described in this
`memo.
`
`The terms "domain" or "domain name" are used in many contexts beyond the
`DNS described here. Very often,
`the term domain name is used to refer
`to a name with structure indicated by dots, but no relation to the DNS.
`This is particularly true in mail addressing [Quarterman 86].
`
`2.2. DNS design goals
`
`The design goals of the DNS influence its structure.
`
`They are:
`
`— The primary goal is 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 be required to
`contain network identifiers, 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
`
`Mockapetris
`
`/
`
`’
`
`[Page 2]
`
`Page 2 of 56
`
`

`
`RFC 1034
`
`Domain Concepts and Facilities
`
`November 1987
`
`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
`Where there tradeoffs between the cost of acquiring data,
`speed of updates, and the accuracy of caches,
`the source of
`the data should control the tradeoff.
`
`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. All
`data associated with a name is tagged with a type, and queries
`can be limited to a single type.
`
`in dissimilar
`Because we want the name space to be useful
`networks and applications, we provide the ability to use the
`same name space with different protocol families or
`management.
`For example, host address formats differ between
`protocols,
`though all protocols have the notion of address.
`The DNS tags all data with a class as well as the type, so
`that we can allow parallel use of different formats for data
`of type address.
`
`We want name server transactions to be independent of the
`communications system that carries them.
`Some systems may
`wish to use datagrams for 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.
`
`The system should be useful across a wide spectrum of host
`capabilities. Both personal computers and large timeshared
`hosts should be able to use the system,
`though perhaps in
`different ways.
`
`2.3.
`
`Assumptions about usage
`
`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
`
`Mockapetris
`
`[Page 3]
`
`Page 3 of 56
`
`

`
`RFC 1034
`
`Domain Concepts and Facilities
`
`November 1987
`
`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 seconds or 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
`
`updates or guarantees of consistency. Hence the update
`process allows updates to percolate out through 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.
`
`- 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.
`
`Mockapetris
`
`«
`
`[Page 4]
`
`Page 4 of 56
`
`

`
`RFC 1034
`
`Domain Concepts and Facilities
`
`November 1987
`
`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
`through the name servers to users of the domain system.
`The user
`programs access name servers through standard programs called resolvers.
`
`The standard format of master files allows them 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.
`
`Each host's name servers and resolvers are configured by a local system
`administrator [RFC-1033].
`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.
`
`Mockapetris
`
`[Page 5]
`
`Page 5 of 56 V
`
`

`
`RFC 1034
`
`Domain Concepts and Facilities
`
`November 1987
`
`2.4. Elements of the DNS
`
`The DNS has three major components:
`A
`— The DOMAIN NAME SPACE and R7‘SOURC7‘ RTCORDS, which are
`specifications for a tree structured name space and data
`associated with the names. 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 Internet
`uses some of its domain names to identify hosts; queries for
`address resources return Internet host addresses.
`
`— 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; a name server is said to be an AUTHORITY for
`these parts of the name space. Authoritative information is
`organized into units called ZONES, and these zones can be
`automatically distributed to the name servers which provide
`redundant service for the data in a zone.
`
`— RESOLVERS are programs that extract information from name
`servers in response to client 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:
`
`the domain system is accessed
`— From the user's point of view,
`through a simple procedure or OS call to a local resolver.
`The domain space consists of a single tree and the user can
`request information from any section of the tree.
`
`the domain system is
`~ From the resolver’s point of view,
`composed of an unknown number of name servers.
`Each name
`
`Mockapetris
`
`[Page 6]
`
`Page 6 of 56
`
`

`
`RFC 1034
`
`Domain Concepts and Facilities
`
`November 1987
`
`server has one or more pieces of the whole domain tree's data,
`but the resolver views each of these databases as essentially
`static.
`
`the domain system consists
`— From a name server's point of view,
`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.
`
`implementations may couple these
`In the interests of performance,
`functions.
`.For example, a resolver on the same machine as a name server
`might share a database consisting of the the zones managed by the name
`server and the cache managed by the resolver.
`
`3. DOMAIN NAME SPACE and RESOURCE RECORDS
`
`3.1. Name space specifications and terminology
`
`Each node and leaf on the
`The domain name space is a tree structure.
`Lree corresponds to a resource set
`(which may be empty).
`The domain
`system makes no distinctions between the uses of the interior nodes and
`leaves, and this memo uses the term "node" to refer to both.
`
`Each node has a label, which is zero to 63 octets in length. Brother
`nodes may not have the same label, although the same label can be used
`for nodes which are not brothers. One label is reserved, and that is
`
`the null (i.e., zero length)
`
`label used for the root.
`
`The domain name of a node is the list of the labels on the path from the
`node to the root of the tree.
`By convention,
`the labels that compose a
`domain name are printed or read left to right,
`from the most specific
`(lowest, farthest from the root)
`to the least specific (highest, closest
`to the root).
`
`Internally, programs that manipulate domain names should 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 representations can use a length
`byte of zero to terminate a domain name.
`
`By convention, domain names can be stored with arbitrary case, but
`domain name comparisons for all present domain functions are done in a
`case~insensitive manner, assuming an ASCII character set, and a high
`order zero bit. This means that you are free to create a node with
`label
`"A" or a node with label "a", but not both as brothers; you could
`refer to either using "a" or "A". When you receive a domain name or
`
`Mockapetris
`
`-
`
`[Page 7]
`
`Page 7 of 56
`
`

`
`RFC 1034
`
`Domain Concepts and Facilities
`
`November 1987
`
`The rationale for this choice is
`label, you should preserve its case.
`that we may someday need to add full binary domain names for new
`services; existing services would not be changed.
`
`the length of each label is
`When a user needs to type a domain name,
`omitted and the labels are separated by dots (".").
`Since a complete
`domain name ends with the root label,
`this leads to a printed form which
`ends in a dot. We use this property to distinguish between:
`
`~ a character string which represents a complete domain name
`(often called "absolute").
`For example, "poneria.ISI.EDU."
`
`~ a character string that represents the starting labels of’a
`domain name which is incomplete, and should be completed by
`local software using knowledge of the local domain (often
`called "relative").
`For example, "poneria" used in the
`ISI.EDU domain.
`
`Relative names are either taken relative to a well known origin, or to a
`list of domains used as a search list. Relative names appear mostly at
`the user interface, where their interpretation varies from.
`implementation to implementation, and in master files, where they are
`relative to a single origin domain name.
`The most common interpretation
`uses the root "." as either the single,origin or as one of the members
`of the search list, so a multi—label relative name is often one where
`the trailing dot has been omitted to save typing.
`
`the total number of octets that represent a
`‘To simplify implementations,
`domain name (i.e.,
`the sum of all label octets and label lengths)
`is
`limited to 255.
`
`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 ends with the containing domain’s name.
`For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".
`
`3.2. Administrative guidelines on use
`
`the DNS technical specifications do not mandate a
`As a matter of policy,
`particular tree structure or rules for selecting labels; its goal is to
`be as general as possible, so that it can be used to build arbitrary
`applications.
`In particular,
`the system was designed so that the name
`space did not have to be organized along the lines of network
`boundaries, name servers, etc.
`The rationale for this is not that the
`name space should have no implied semantics, but rather that the choice
`of implied semantics should be left open to be used.for the problem at
`
`Mockapetris
`
`[Page 8]
`
`Page 8 of 56
`
`

`
`RFC 1034
`
`Domain Concepts and Facilities
`
`November 1987
`
`hand, and that different parts of the tree can have different implied
`semantics.
`For example,
`the IN—ADDR.ARPA domain is organized and
`distributed by network and host address because its role is to translate
`from network or host numbers to names; NetBIOS domains
`[RFC—1001, RFC~
`1002] are flat because that is appropriate for that application.
`
`there are some guidelines that apply to the "normal" parts of
`However,
`the name space used for hosts, mailboxes, etc.,
`that will make the name
`space more uniform, provide for growth, and minimize problems as
`software is converted from the older host table.
`The political
`decisions about the top levels of the tree originated in RFC~920.
`Current policy for the top levels is discussed in [RFC—lO32]. MILN
`conversion issues are covered in [RFC—lO31].
`
`LU ‘-3
`
`Lower domains which will eventually be broken into multiple zones should
`provide branching at the top of the domain so that the eventual
`decomposition can be done without renaming. Node labels which use
`special characters,
`leading digits, etc., are likely to break older
`software which depends on more restrictive choices.
`
`3.3. Technical guidelines on use
`
`Before the DNS can be used to hold naming information for some kind of
`object,
`two needs must be met:
`
`— A convention for mapping between object names and domain
`names. This describes how information about an object is
`accessed.
`
`— RR types and data formats for describing the object.
`
`the
`These rules can be quite simple or fairly complex. Very often,
`designer must take into account existing formats and plan for upward
`compatibility for existing usage. Multiple mappings or levels of
`mapping may be required.
`
`the mapping depends on the existing syntax for host names
`For hosts,
`which is a subset of the usual text representation for domain names,
`together with RR formats for describing host addresses, etc. Because we
`need a reliable inverse mapping from address to host name, a special
`mapping for addresses into the IN~ADDR.ARPA domain is also defined.
`
`The usual mail
`the mapping is slightly more complex.
`For mailboxes,
`address <local—part>@<mail—domain> is mapped into a domain name by
`converting <local—part> into a single label
`(regardles of dots it
`contains), converting <mail~domain> into a domain name using the usual
`text format for domain names
`(dots denote label breaks), and
`concatenating the two to form a single domain name.
`Thus the mailbox
`
`Mockapetris
`
`[Page 9]
`
`Page 9 of 56
`
`

`
`RFC 1034
`
`Domain Concepts and Facilities
`
`November 1987
`
`HOS”MAST3R@SRI—NIC.ARPA is represented as a domain name by
`HOS"MAST3R.SRI—NIC.ARPA.
`An appreciation for the reasons behind this
`design also must
`take into account the scheme for mail exchanges
`[RFC-
`974
`
`The typical user is not concerned with defining these rules, but should
`understand that they usually are the result of numerous compromises
`between desires for upward compatibility with old usage,
`interactions
`between different object definitions, and the inevitable urge to add new
`features when defining the rules.
`The way the DNS is used to support
`some object is often more crucial than the restrictions inherent in the
`DNS.
`
`3.4. Example name space
`
`_The following figure shows a part of the current domain name space, and
`is used in many examples in this RFC. Note that the tree is a very
`small subset of the actual name space.
`
`+ — ~ ~ ~ — — — — — ~ ~ — ~ ~ — — — — — ——+ — — — — — — — ~ — - — — — - - — ~—+
`
`I
`MIL
`
`I
`EDU
`
`I
`ARPA
`
`I
`I
`+-————+————~+
`I
`I
`I
`BRL NOSC DARPA
`
`I
`I
`|
`I
`|
`I.
`+ — — — — — - —~+ ~ - - — — — — ~ — — — — ~ — ~ — ——+ — — — — — — — — — - - — — ~—+ — ~ — - ~ - ——+
`
`I.
`I
`+ — — — — ~—+———-—+———~—+
`I
`I
`I
`IN—ADDR
`SRI—NIC
`ACC
`
`I
`UCI
`
`I
`MIT
`I
`I
`+»~—+———+
`I
`I
`LCS ACHILLES
`
`I
`UDEL
`
`I
`I
`ISI
`I
`I
`I
`+~—+—————+—--——+ ------ ——+
`
`I
`YALE
`
`I
`XX
`
`I
`A
`
`I
`C
`
`I
`I
`I
`VAXA VENERA Mockapetris
`
`the root domain has three immediate subdomains: MIL,
`In this example,
`The LCS.MIT.EDU domain has one immediate subdomain named
`EDU, and ARPA.
`Xx.Lcs.MIT.3DU. All of the leaves are also domains.
`‘
`
`3.5. Preferred name syntax
`
`The DNS specifications attempt
`
`to be as general as possible in the rules
`
`Mockapetris
`
`V
`
`[Page 10]
`
`Page 10 of 56
`
`

`
`RFC 1034
`
`Domain Concepts and Facilities
`
`November 1987
`
`The idea is that the name of any
`for constructing domain names.
`existing object can be expressed as a domain name with minimal changes.
`However, when assigning a domain name for an object,
`the prudent user
`will select a name which satisfies both the rules of the domain system
`and any existing rules for the object, whether these rules are published
`or implied by existing programs.
`
`the user should satisfy both the
`For example, when naming a mail domain,
`rules of this memo and those in RFC—822. When creating a new host name,
`the old rules for HOSTS.TXT should be followed. This avoids problems
`when old software is converted to use domain names.
`
`The following syntax will result in fewer problems with many
`applications that use domain names (e.g., mail, TELNET).
`
`<domain> ::= <subdomain> I
`
`"
`
`"
`
`<subdomain> ::= <label> I <subdomain> "." <label>
`
`<label> ::= <letter> [
`
`[ <ldh—str> ] <let—dig> ]
`
`<ldh~str> ::= <let~dig~hyp> | <let~dig—hyp> <ldh—str>
`
`<let—dig—hypa ::= <let—dig> | "-"
`
`<let—dig> ::= <letter> I <digit>
`
`<letter> ::= any one of the 52 alphabetic characters A through Z in
`upper case and a through z in lower case
`
`<digit> ::= any one of the ten digits 0 through 9
`
`Note that while upper and lower case letters are allowed in domain
`names, no significance is attached to the case. That is,
`two names with
`the same spelling but different case are to be treated as if identical.
`
`They must
`The labels must follow the rules for ARPANET host names.
`start with a letter, end with a letter or digit, and have as interior
`characters only letters, digits, and hyphen. There are also some
`restrictions on the length. Labels must be 63 characters or less.
`
`For example,
`
`the following strings identify hosts in the Internet:
`
`A. ISI . EDU XX . LCS .MIT . EDU
`
`SRI—NIC.ARPA
`
`3.6. Resource Records
`
`A domain name identifies a node.
`
`Each node has a set of resource
`
`Mockapetris
`
`[Page 11]
`
`Page 11 of 56
`
`

`
`RFC 1034
`
`Domain Concepts and Facilities
`
`November l987
`
`The set of resource information
`information, which may be empty.
`associated with a particular name is composed of separate resource
`records (RRs).
`The order of RRS in a set is not significant, and need
`not be preserved by name servers, resolvers, or other parts of the DNS.
`
`When we talk about a specific RR, we assume it has the following:
`
`owner
`
`type
`
`which is the domain name where the RR is found.
`
`which is an encoded 16 bit value that specifies the type
`of the resource in this resource record. "Types refer to
`abstract,resources.
`
`This memo uses the following types:
`
`A
`
`CNAME
`
`HINFO
`
`MX
`
`a host address
`
`identifies the canonical name of an
`alias
`
`identifies the CPU and OS used by a host
`
`identifies a mail exchange for the
`domain.
`See [RFC—974 for details.
`
`N8
`the authoritative name server for the domain
`
`PTR
`
`a pointer to another part of the domain name space
`
`SOA
`identifies the start of a zone of authority]
`
`class
`
`which is an encoded 16 bit value which identifies a
`protocol family or instance of a protocol.
`
`This memo uses the following classes:
`
`IN
`
`CH
`
`the Internet system
`
`the Chaos system
`
`TTL
`
`which is the time to live of the RR. This field is a 32
`bit integer in units of seconds, an is primarily used by
`resolvers when they cache RRs.
`The TTL describes how
`long a RR can be cached before it should be discarded.
`
`Mockapetris
`
`[Page 12]
`
`Page 12 of 56
`
`

`
`RFC 1034
`
`Domain Concepts and Facilities
`
`November 1987
`
`RDATA
`
`which is the type and sometimes class dependent data
`which describes the resource:
`
`A
`
`‘ ?or the IN class, a 32 bit IP address
`
`CNAME
`
`MX
`
`NS
`
`PTR
`
`SOA
`
`Tor the CH class, a domain name followed
`by a 16 bit octal Chaos address.
`
`a domain name.
`
`a 16 bit preference value (lower is
`better) followed by a host name willing
`to act as a mail exchange for the owner
`domain.
`
`a host name.
`
`a domain name.
`
`several fields.
`
`The owner name is often implicit, rather than forming an integral part
`of the RR.
`For example, many name servers internally form tree or hash
`structures for the name space, and chain RRs off nodes.
`The remaining
`RR parts are the fixed header
`(type, class, TTL) which is consistent for
`all RRs, and a variable part
`(RDATA)
`that fits the needs of the resource
`being described.
`
`The meaning of the TTL field is a time limit on how long an RR can be
`kept
`in a cache. This limit does not apply to authoritative data in
`zones; it is also timed out, but by the refreshing policies for the
`zone.
`The TTL is assigned by the administrator for the zone where the
`data originates. While short TTLs can be used to minimize caching, and
`a zero TTL prohibits caching,
`the realities of Internet performance
`suggest that these times should be on the order of days for the typical
`host.
`If a change can be anticipated,
`the TTL can be reduced prior to
`the change to minimize inconsistency during the change, and then
`increased back to its former value following the change.
`
`The data in the RDATA section of RRs is carried as a combination of
`binary strings and domain names.
`The domain names are frequently used
`as "pointers" to other data in the DNS.
`
`3.6.1. Textual expression of RRs
`
`RRs are represented in binary form in the packets of the DNS protocol,
`and are usually represented in highly encoded form when stored in a name
`server or resolver.
`In this memo, we adopt a style similar to that used
`
`Mockapetris
`
`[Page 13]
`
`Page 13 of 56
`
`

`
`RFC 1034
`
`Domain Concepts and Facilities
`
`November 1987
`
`In this format,
`in master files in order to show the contents of RRs.
`most RRs are shown on a single line, although continuation lines are
`possible using parentheses.
`
`If a line begins with
`The start of the line gives the owner of the RR.
`a blank,
`then the owner is assumed to be the same as that of the
`previous RR. Blank lines are often included for readability.
`
`type, and class of the RR. Class
`Following the owner, we list the TTL,
`and type use the mnemonics defined above, and TTL is an integer before
`the type field.
`In order to avoid ambiguity in parsing,
`type and class
`mnemonics are disjoint, TTLs are integers, and the type mnemonic is
`always last. The IN class and TTL values are often omitted from examples
`in the interests of clarity.
`
`The resource data or RDATA section of the RR are given using knowledge
`of the typical representation for the data.
`
`For example, we might show the RRs carried in a message as:
`
`ISI.EDU.
`
`MX
`MX
`VENERA.ISI.EDU. A
`‘
`A
`VAXA.ISI.EDU.
`A
`A
`
`10 VENERA.ISI.EDU.
`10 VAXA.ISI.EDU.
`l28.9.0.32
`10.l.O.52
`lO.2.0.27
`l28.9.0.33
`
`The MX RRs have an RDATA section which consists of a 16 bit number
`followed by a domain name.
`The address RRs use a standard IP address
`format to contain a 32 bit internet address.
`
`This example shows six RRs, with two RRs at each of three domain names.
`
`Similarly we might see:
`
`XX.LCS.MIT.EDU.
`
`IN
`CH
`
`A
`A
`
`l0.0.0.44
`MIT.EDU. 2420
`
`This example shows two addresses for XX.LCS.MIT.EDU, each of a different
`class.
`
`3.6.2. Aliases and canonical names
`
`In existing systems, hosts and other resources often have several names
`that identify the same resource»
`For example,
`the names C.ISI.EDU and
`USC—ISIC.ARPA_both identify the same host. Similarly,
`in the case of
`mailboxes, many organizations provide many names that actually go to the
`same mailbox; for example Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU,
`
`Mockapetris
`
`[Page 14]
`
`Page 14 of 56
`
`

`
`RFC 1034
`
`Domain Concepts and Facilities
`
`November 1987
`
`and PVM@ISI.EDU all go to the same mailbox (although the mechanism
`behind this is somewhat complicated).
`
`Most of these systems have a notion that one of the equivalent set of
`names is the canonical or primary name and all others are aliases.
`
`The domain system provides such a feature using the canonical name
`(CNAM3) RR.
`A CNAME RR identifies its owner name as an alias, and
`specifies the corresponding canonical name in the RDATA section of the
`RR.
`If a CNAME RR is present at a node, no other data should be
`present;
`this ensures that the data for a canonical name and its aliases
`cannot be different. This rule also insures that a cached CNAME can be
`used without checking with an authoritative server for other RR types.
`
`CNAME RRs cause special action in DNS software. When a name server
`fails to find a desired RR in the resource set associated with the
`domain name, it checks to see if the resource set consists of a CNAME
`record with a matching class.
`If so,
`the name server includes the CNAME
`record in the response and restarts the query at the domain name
`specified in the data field of the CNAME record.
`The one exception to
`this rule is that queries which match the CNAME type are not restarted.
`
`For example, suppose a name server was processing a query with for USC~
`ISIC.ARPA, asking for type A information, and had the following resource
`records:
`
`USC—ISIC.ARPA
`
`C.ISI.EDU
`
`IN
`
`IN
`
`CNAME
`
`C.ISI.EDU
`
`A
`
`10.0.0.52
`
`Both of these RRs would be returned in the response to the type A query,
`while a type CNAME or * query should return just the CNAME.
`
`Domain names in RRs which point at another name should always point at
`the primary name and not the alias. This avoids extra indirections in
`accessing information.
`For example,
`the address to name RR for the
`above host should be:
`
`52.0.0.lO.IN—ADDR.ARPA IN
`
`PTR
`
`C.ISI.EDU
`
`Of course, by the robustness
`rather than pointing at USC—ISIC.ARPA.
`principle, domain software should not fail when presented with CNAME
`chains or loops; CNAME chains should be followed and CNAME loops
`signalled as an error.
`
`3.7. Queries
`
`Queries are messages which may be sent
`
`to a name server to provoke a
`
`Mockapetris
`
`.
`
`[Page 15]
`
`Page 15 of 56
`
`

`
`RFC 1034
`
`Domain Concepts and Facilities
`
`November 1987
`
`In the Internet, queries are carried in UDP datagrams or over
`response.
`TCP connections.
`The response by the name server either answers the
`question posed in the query, refers the requester to another set of name
`servers, or signals some error condition.
`
`the user does not generate queries directly, but instead
`In general,
`makes a request to a resolve