As per Relevance of the word resource, we have this rfc below:
Network Working Group P.
Request for Comments: 882
November 1983
DOMAIN NAMES - CONCEPTS and
+-----------------------------------------------------+
| |
| 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. |
| |
+-----------------------------------------------------+
The need for domain
As applications grow to span multiple hosts, then networks,
finally internets, these applications must also span
administrative boundaries and related methods of
(protocols, data formats, etc). The number of resources (
example mailboxes), the number of locations for resources, and
diversity of such an environment cause formidable problems when
wish to create consistent methods for referencing
resources that are similar but scattered throughout
environment
The ARPA Internet illustrates the size-related problems; it is
large system and is likely to grow much larger. The need to
a mapping between host names (e.g., USC-ISIF) and ARPA
addresses (e.g., 10.2.0.52) is beginning to stress the
mechanisms. Currently hosts in the ARPA Internet are
with the Network Information Center (NIC) and listed in a
table (available as the file HOSTS.TXT on the SRI-
host) [1]. The size of this table, and especially the
of updates to the table are near the limit of manageability.
is needed is a distributed database that performs the
function, and hence avoids the problems caused by a
database
The problem for computer mail is more severe. While mail
implementers long ago recognized the impossibility of
Mockapetris [Page 1]
RFC 882 November 1983
Domain Names - Concepts and
mailbox names, they have also created an increasingly large
irregular set of methods for identifying the location of
mailbox. Some of these methods involve the use of routes
forwarding hosts as part of the mail destination address,
consequently force the mail user to know multiple address formats
the capabilities of various forwarders, and ad hoc tricks
passing address specifications through intermediaries
These problems have common characteristics that suggest the
of any solution
The basic need is for a consistent name space which will
used for referring to resources. In order to avoid
problems caused by ad hoc encodings, names should not
addresses, routes, or similar information as part of the name
The sheer size of the database and frequency of updates
that it must be maintained in a distributed manner, with
caching to improve performance. Approaches that attempt
collect a consistent copy of the entire database will
more and more expensive and difficult, and hence should
avoided. The same principle holds for the structure of
name space, and in particular mechanisms for creating
deleting names; these should also be distributed
The costs of implementing such a facility dictate that it
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
networks, it is unlikely that all users of domain names will
able to agree on the set of resources or resource
that names will be used to retrieve. Hence names refer to
set of resources, and queries contain resource identifiers
The only standard types of information that we expect to
throughout the name space is structuring information for
name space itself, and resources that are described
domain names and no nonstandard data
We also want the name server transactions to be independent
the communications system that carries them. Some systems
wish to use datagrams for simple queries and responses,
only establish virtual circuits for transactions that need
reliability (e.g. database updates, long transactions);
systems will use virtual circuits exclusively
Mockapetris [Page 2]
RFC 882 November 1983
Domain Names - Concepts and
Elements of the
The proposed solution has three major components
The DOMAIN NAME SPACE, which is a specification for a
structured name space. Conceptually, each node and leaf of
domain name space tree names a set of information, and
operations are attempts to extract specific types
information from a particular set. A query names the
name of interest and describes the type of resource
that is desired. For example, the ARPA Internet uses some
its domain names to identify hosts; queries for
resources return ARPA Internet host addresses. However,
preserve the generality of the domain mechanism, domain
are not required to have a one-to-one correspondence with
names, host addresses, or any other type of information
NAME SERVERS are server programs which hold information
the domain tree's structure and set information. A name
may cache structure or set information about any part of
domain tree, but in general a particular name server
complete information about a subset of the domain space,
pointers to other name servers that can be used to lead
information from any part of the domain tree. Name
know the parts of the domain tree for which they have
information; these parts are called ZONEs; a name server is
AUTHORITY for these parts of the name space
RESOLVERS are programs that extract information from
servers in response to user requests. Resolvers must be
to access at least one name server and use that name server'
information to answer a query directly, or pursue the
using referrals to other name servers. A resolver
typically be a system routine that is directly accessible
user programs; hence no protocol is necessary between
resolver and the user program
These three components roughly correspond to the three layers
views of the domain system
From the user's point of view, the domain system is
through simple procedure or OS calls to resolvers. The
space consists of a single tree and the user can
information from any section of the tree
From the resolver's point of view, the domain system
composed of an unknown number of name servers. Each
server has one or more pieces of the whole domain tree's data
Mockapetris [Page 3]
RFC 882 November 1983
Domain Names - Concepts and
but the resolver views each of these databases as
static
From a name server's point of view, the domain system
of separate sets of local information called zones. The
server has local copies of some of the zones. The name
must periodically refresh its zones from master copies in
files or foreign name servers. The name server
concurrently process queries that arrive from resolvers
the local zones
In the interests of performance, these layers blur a bit.
example, resolvers on the same machine as a name server may
a database and may also introduce foreign information for use
later queries. This cached information is treated
from the authoritative data in zones
Database
The organization of the domain system derives from
assumptions about the needs and usage patterns of its
community and is designed to avoid many of the the
problems found in general purpose database systems
The assumptions are
The size of the total database will initially be
to the number of hosts using the system, but will
grow to be proportional to the number of users on those
as mailboxes and other information are added to the
system
Most of the data in the system will change very slowly (e.g.,
mailbox bindings, host addresses), but that the system
be able to deal with subsets that change more rapidly (on
order of minutes).
The administrative boundaries used to distribute
for the database will usually correspond to organizations
have one or more hosts. Each organization that
responsibility for a particular set of domains will
redundant name servers, either on the organization's own
or other hosts that the organization arranges to use
Clients of the domain system should be able to identify
name servers they prefer to use before accepting referrals
name servers outside of this "trusted" set
Access to information is more critical than
Mockapetris [Page 4]
RFC 882 November 1983
Domain Names - Concepts and
updates or guarantees of consistency. Hence the update
allows updates to percolate out though the users of the
system rather than guaranteeing that all copies
simultaneously updated. When updates are unavailable due
network or host failure, the usual course is to believe
information while continuing efforts to update it. The
model is that copies are distributed with timeouts
refreshing. The distributor sets the timeout value and
recipient of the distribution is responsible for performing
refresh. In special situations, very short intervals can
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
designed so that simple queries and responses can use
style, although refreshing operations need the reliability
virtual circuits. The same overall message format is used
all communication. The domain system does not assume
special properties of the communications system, and
could be used with any datagram or virtual circuit protocol
In any system that has a distributed database, a
name server may be presented with a query that can only
answered by some other server. The two general approaches
dealing with this problem are "recursive", in which the
server pursues the query for the client at another server,
"iterative", in which the server refers the client to
server and lets the client pursue the query. Both
have advantages and disadvantages, but the iterative
is preferred for the datagram style of access. The
system requires implementation of the iterative approach,
allows the recursive approach as an option. The
recursive style is discussed in [14], and omitted from
discussion in this memo
The domain system assumes that all data originates in master
scattered through the hosts that use the domain system.
master files are updated by local system administrators.
files are text files that are read by a local name server,
hence become available to users of the domain system. A
format for these files is given in [14].
The standard format allows these files to be exchanged
hosts (via FTP, mail, or some other mechanism); this facility
useful when an organization wants a domain, but doesn't want
support a name server. The organization can maintain the
files locally using a text editor, transfer them to a foreign
which runs a name server, and then arrange with the
administrator of the name server to get the files loaded
Mockapetris [Page 5]
RFC 882 November 1983
Domain Names - Concepts and
Each host's name servers and resolvers are configured by a
system administrator. For a name server, this configuration
includes the identity of local master files and instructions
which non-local master files are to be loaded from
servers. The name server uses the master files or copies to
its zones. For resolvers, the configuration data identifies
name servers which should be the primary sources of information
The domain system defines procedures for accessing the data
for referrals to other name servers. The domain system
defines procedures for caching retrieved data and for
refreshing of data defined by the system administrator
The system administrators provide
The definition of zone
Master files of
Updates to master
Statements of the refresh policies
The domain system provides
Standard formats for resource
Standard methods for querying the
Standard methods for name servers to refresh local data
foreign name
DOMAIN NAME
Name space specifications and
The domain name space is a tree structure. Each node and leaf
the tree corresponds to a resource set (which may be empty).
node and leaf has an associated label. Labels are NOT
to be unique, with the exception of the root node, which has
null label. The domain name of a node or leaf is the path
the root of the tree to the node or leaf. By convention,
labels that compose a domain name are read left to right, from
most specific (lowest) to the least specific (highest).
Internally, programs that manipulate domain names represent
as sequences of labels, where each label is a length
followed by an octet string. Because all domain names end at
root, which has a null string for a label, these
Mockapetris [Page 6]
RFC 882 November 1983
Domain Names - Concepts and
representations can use a length byte of zero to terminate
domain name. When domain names are printed, labels in a path
separated by dots ("."). The root label and its associated
are omitted from printed domain names, but the root can be
by a null domain name (" " in this memo).
To simplify implementations, the total number of octets
represent label octets and label lengths is limited to 255.
a printed domain name can be up to 254 characters
A special label is defined that matches any other label.
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
the boundary between protocol families, and requires prudence
its use
A domain is identified by a domain name, and consists of that
of the domain name space that is at or below the domain name
specifies the domain. A domain is a subdomain of another
if it is contained within that domain. This relationship can
tested by seeing if the subdomain's name has the
domain's name as the right part of its name. For example, A.B.C.
is a subdomain of B.C.D, C.D, D, and " ".
This tree structure is intended to parallel the
organization and delegation of authority. Potentially, each
or leaf on the tree can create new subdomains ad infinitum.
practice, this delegation can be limited by the administrator
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
subdomain named NATURAL.FLAVORS. All of the leaves are
Mockapetris [Page 7]
RFC 882 November 1983
Domain Names - Concepts and
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
domain of ARTIFICIAL under FLAVORS, FLAVORS would typically be
administrative entity that would decide; if we wished to
CHIP and MOCHA names under CHOCOLATE, CHOCOLATE.NATURAL.
would typically be the appropriate administrative entity
Resource set
A domain name identifies a set of resource information. The
of resource information associated with a particular name
composed of separate resource records (RRs).
Each resource record has the following major components
The domain name which identifies resource set that holds
record, and hence the "owner" of the information. For example
a RR that specifies a host address has a domain name
specifies the host having that address. Thus F.ISI.ARPA
be the owner of a RR which specified an address field
10.2.0.52. Since name servers typically store their
information in tree structures paralleling the organization
the domain space, this information can usually be
implicitly in the database; however it is always included
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
memo, but is discussed in [14].
A resource type field that specifies the type of the
in this resource record. Types refer to abstract
such as host addresses or mail delivery agents. The type
is two octets long and uses an encoding that is
throughout the domain name system
A class field identifies the format of the resource data,
as the ARPA Internet format (IN) or the Computer
Network format (CSNET), for certain RR types (such as
data). Note that while the class may separate
protocol families, networks, etc. it does not do so in
cases. For example, the IN class uses 32 bit IP
exclusively, but the CSNET class uses 32 bit IP addresses, X.25
addresses, and phone numbers. Thus the class field should
used as a guide for interpreting the resource data. The
field is two octets long and uses an encoding that is
throughout the domain name system
Mockapetris [Page 8]
RFC 882 November 1983
Domain Names - Concepts and
Resource data that describes the resource. The format of
data can be determined given the type and class fields,
always starts with a two octet length field that allows a
server or resolver to determine the boundaries of the
data in any transaction, even if it cannot "understand"
resource data itself. Thus name servers and resolvers can
and pass on records which they cannot interpret. The format
the internal data is restricted only by the maximum length
65535 octets; for example the host address record might
a fixed 32 bit number for one class, and a variable length
of addresses in another class
While the class field in effect partitions the resource data
the domain name system into separate parallel sections
to class, services can span class boundaries if they
compatible resource data formats. For example, the domain
system uses compatible formats for structure information, and
mail data decouples mail agent identification from details of
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
MF - identifies a mail forwarder for the
MD - identifies a mail destination for the
NS - the authoritative name server for the
SOA - identifies the start of a zone of
CNAME - identifies the canonical name of an
This memo uses the following classes in its examples
IN - the ARPA Internet
CS - the CSNET
The first type of resource record holds a host name to
address binding. Its fields are
+--------+--------+--------+--------------//----------------------+
| | A | | specific address>information |
+--------+--------+--------+--------------//----------------------+
Mockapetris [Page 9]
RFC 882 November 1983
Domain Names - Concepts and
The content of the class specific information varies according
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
the phone number of the host. For example, F.ISI.ARPA might
two A records of the form
+----------+--------+--------+----------------------------+
|F.ISI.ARPA| A | IN | 10.2.0.52 |
+----------+--------+--------+----------------------------+
+----------+--------+--------+----------------------------+
|F.ISI.ARPA| A | CS | 213-822-2112 |
+----------+--------+--------+----------------------------+
Note that the data formats for the A type are class dependent,
the Internet address and phone number formats shown above are
purposes of illustration only. The actual data formats
specified in [14]. For example, CS class data for type A
might actually be a list of Internet addresses, phone numbers
TELENET addresses
The mail forwarder (MF) and mail delivery (MD) records have
following format
+--------+--------+--------+----------------------------+
| | MD/MF | | |
+--------+--------+--------+----------------------------+
The field is a domain name of the host that
handle mail; note that this domain name may be
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 |
+----------+--------+--------+----------------------------+
+----------+--------+--------+----------------------------+
|F.ISI.ARPA| MF | IN | B.ISI.ARPA |
+----------+--------+--------+----------------------------+
These records mean that mail for F.ISI.ARPA can either
delivered to the host F.ISI.ARPA or forwarded to B.ISI.ARPA,
will accept responsibility for its eventual delivery.
principle, an additional name lookup is required to map the
name of the host to the appropriate address, in practice
information is usually returned in the response to the mail query
The SOA and NS types of resource records are used to define
Mockapetris [Page 10]
RFC 882 November 1983
Domain Names - Concepts and
of authority. The domain name given by the owner field of a
record is the start of a zone; the domain name given by the
field of a NS record identifies a point in the name space
authority has been delegated, and hence marks the zone boundary
Except in the case where a name server delegates authority
itself, the SOA identifies the top limit of authority, and
records define the first name outside of a zone. These
records have a standard format for all of the name space
+----------+--------+--------+-----------------------------+
| | SOA | | |
+----------+--------+--------+-----------------------------+
+----------+--------+--------+-----------------------------+
| | NS | | |
+----------+--------+--------+-----------------------------+
The SOA record marks the start of a zone when it is present in
database; the NS record both marks the end of a zone started by
SOA (if a higher SOA is present) and also points to a name
that has a copy of the zone specified by the
NS record
The in the SOA record specifies the
source of the information in the zone and other information
by name servers to organize their activities. SOA records
never cached (otherwise they would create false zones); they
only be created in special name server maintenance operations
The NS record says that a name server which is authoritative
records of the given CLASS can be found at .
Queries to a name server must include a domain name
identifies the target resource set (QNAME), and the type and
of desired resource records. The type and class fields in a
can include any of the corresponding type and class fields
are defined for resource records; in addition, the query
(QTYPE) and query class (QCLASS) fields may contain special
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]
RFC 882 November 1983
Domain Names - Concepts and
The QCLASS field may contain
* - matches any RR class
Using the query domain name, QTYPE, and QCLASS, the name
looks for matching RRs. In addition to relevant records, the
server may return RRs that point toward a name server that has
desired information or RRs that are expected to be useful
interpreting the relevant RRs. For example a name server
doesn't have the requested information may know a name server
does; a name server that returns a domain name in a relevant
may also return the RR that binds that domain name to an address
Note that the QCLASS=* construct requires special
regarding authority. Since a name server may not know all of
classes available in the domain system, it can never know if it
authoritative for all classes. Hence responses to QCLASS=*
queries can never be authoritative
Example
For purposes of exposition, the following name space is used
the remainder of this memo
|
+------------------+------------------+
| | |
DDN ARPA CSNET
| | |
+-----+-----+ | +-----+-----+
| | | | | |
JCS ARMY NAVY | UDEL UCI
|
+--------+---------------+---------------+--------+
| | | | |
DTI MIT ISI UDEL NBS
| |
+---+---+ +---+---+
| | | | |
DMS AI A B F
Mockapetris [Page 12]
RFC 882 November 1983
Domain Names - Concepts and
NAME
Name servers store a distributed database consisting of
structure of the domain name space, the resource sets
with domain names, and other information used to
actions between name servers
In general, a name server will be an authority for all or part
a particular domain. The region covered by this authority
called a zone. Name servers may be responsible for
authoritative data, and hence have no zones, or may have
zones. When a name server has multiple zones, the zones may
no common borders or zones may be contiguous
While administrators should not construct overlapping zones,
name servers must defend against overlapping zones, overlapping
regarded as a non-fatal flaw in the database. Hence the
taken to protect against it are omitted for the remainder of
memo. A detailed discussion can be found in [14].
When presented with a query for a domain name over which it
authority, a name server returns the desired resource
or an indication that the query refers to a domain name
resource that does not exist. If a name server is presented
a query for a domain name that is not within its authority, it
have the desired information, but it will also return a
that points toward an authoritative name server. If a name
is not an authority for a query, it can never return a
response
There is no requirement that a name server for a domain reside
a host which has a name in the same domain, although this
usually be the case. There is also no restriction on the
of name servers that can have authority over a particular domain
most domains will have redundant authoritative name servers.
assumption is that different authoritative copies are identical
even though inconsistencies are possible as updates are made
Name server functions are designed to allow for very
implementations of name servers. The simplest name server has
static set of information and uses datagrams to receive
and return responses
More sophisticated name server implementations can improve
performance of their clients by caching information from
domains. Although this information can be acquired in a number
ways, the normal method is to store the information acquired by
Mockapetris [Page 13]
RFC 882 November 1983
Domain Names - Concepts and
resolver when the resolver consults other name servers. In
sophisticated host, the resolver and name server will
their actions and use a shared database. This
requires the incorporation of a time-to-live (TTL) field in
cached resource records. Caching is discussed in the
section of this memo; this section is devoted to the actions of
name servers that don't cache
In order to free simple name servers of the requirement
managing these timeouts, simple name servers should only
resource records that are expected to remain constant over
long periods or resource records for which the name server is
authority. In the following discussion, the TTL field is
to be stored in the resource record but is omitted in
of databases and responses in the interest of clarity
Authority and administrative control of
Although we want to have the potential of delegating
privileges of name space management at every node, we don't
such delegation to be required
Hence we introduce the concept of authority. Authority is
in name servers. A name server has authority over all of
domain until it delegates authority for a subdomain to some
name server
Any administrative entity that wishes to establish its own
must provide a name server, and have that server accepted by
parent name server (i.e. the name server that has authority
the place in the domain name space that will hold the new domain).
While the principles of authority allow acceptance to be at
discretion of parent name servers, the following criteria are
by the root, and are recommended to all name servers because
are responsible for their children's actions
1. It must register with the parent administrator of domains
2. It must identify a responsible person
3. In must provide redundant name servers
The domain name must be registered with the administrator to
name conflicts and to make the domain related
available to other domains. The central administrator may
further requirements, and a domain is not registered until
central administrator agrees that all requirements are met
There must be a responsible person associated with each domain
Mockapetris [Page 14]
RFC 882 November 1983
Domain Names - Concepts and
be a contact point for questions about the domain, to verify
update the domain related information, and to resolve any
(e.g., protocol violations) with hosts in the domain
The domain must provide redundant (i.e., two or more) name
to provide the name to address resolution service. These
servers must be accessible from outside the domain (as well
inside) and must resolve names for at least all the hosts in
domain
Once the central administrator is satisfied, he will
the existence to the appropriate administrators of other
so that they can incorporate NS records for the new name
into their databases
Name server
The processing steps that a name server performs in responding
a query are conceptually simple, although implementations may
internal databases that are quite complex
For purposes of explanation, we assume that the query consists
a type QTYPE, a class QCLASS, and a domain name QNAME; we
that the name server stores its RRs in sets where each set has
of the RRs for a particular domain. Note that this
structure and the following algorithms are meant to illustrate
possible implementation, rather than a specification of how
servers must be implemented
The following notation is used
ord(DOMAIN-NAME) returns the number of labels in DOMAIN-NAME
findset(DOMAIN-NAME) returns a pointer to the set of stored
for DOMAIN-NAME, or NULL if there is no
information
set(POINTER) refers to a set located previously
findset, where POINTER is the value
by findset
relevant(QTYPE,TYPE) returns true if a RR of the specified TYPE
relevant to the specified QTYPE.
example, relevant(MAILA,MF) is true
relevant(MAILA,NS) is false
right(NAME,NUMBER) returns a domain name that is the
NUMBER labels in the string NAME
Mockapetris [Page 15]
RFC 882 November 1983
Domain Names - Concepts and
copy(RR) copies the resource record specified by
into the response
The name server code could be represented as the
sequence of steps
{ find out whether the database makes this server
authoritative for the domain name specified by QNAME }
for i:=0 to ord(QNAME) { sequence through all nodes in QNAME }
do begin
ptr:=findset(right(QNAME,i));
if ptr<>NULL
then { there is domain data for this domain name }
begin
for all RRs in set(ptr)
do if type(RR)=NS and class(RR)=QCLASS
then begin
auth=false;
NSptr:=ptr
end;
for all RRs in set(ptr)
do if type(RR)=SOA and class(RR)=QCLASS
then auth:=true
end
end;
end;
{ copy out authority search results }
if auth
then { if authority check for domain found }
if ptr=null
then return(Name error)
else
else { if not authority, copy NS RRs }
for all RRs in set(nsptr)
do if (type(RR)=NS and class(RR)=QCLASS)
or
(QCLASS=*)
then copy(RR);
{ Copy all RRs that answer the question }
for all RRs in set(ptr)
do if class(RR)=QCLASS and relevant(QTYPE,type(RR))
then copy(RR);
The first section of the code (delimited by the for loop over
Mockapetris [Page 16]
RFC 882 November 1983
Domain Names - Concepts and
of the subnodes of QNAME) discovers whether the name server
authoritative for the domain specified by QNAME. It
through all containing domains of QNAME, starting at the root.
it encounters a SOA it knows that the name server is
unless it finds a lower NS RR which delegates authority. If
name server is authoritative, it sets auth=true; if the
server is not authoritative, it sets NSptr to point to the
which contains the NS RR closest to the domain specified by QNAME
The second section of the code reflects the result of
authority search into the response. If the name server
authoritative, the code checks to see that the domain specified
QNAME exists; if not, a name error is returned. If the
server is not authoritative, the code copies the RRs for a
name server into the response
The last section of the code copies all relevant RRs into
response
Note that this code is not meant as an actual implementation
is incomplete in several aspects. For example, it doesn't
with providing additional information, wildcards, QCLASS=*,
with overlapping zones. The first two of these issues are
with in the following discussions, the remaining issues
discussed in [14].
Additional
When a resolver returns information to a user program,
returned information will often lead to a second query.
example, if a mailer asks a resolver for the appropriate
agent for a particular domain name, the name server queried by
resolver returns a domain name that identifies the agent.
general, we would expect that the mailer would then request
domain name to address binding for the mail agent, and a new
server query would result
To avoid this duplication of effort, name servers
additional information with a response which satisfies
anticipated query. This information is kept in a separate
of the response. Name servers are required to complete
appropriate additional information if such information
available, but the requestor should not depend on the presence
the information since the name server may not have it. If
resolver caches the additional information, it can respond to
second query without an additional network transaction
The appropriate information is defined in [14], but
Mockapetris [Page 17]
RFC 882 November 1983
Domain Names - Concepts and
consists of host to address bindings for domain names in
RRs
Aliases and canonical
In existing systems, hosts and other resources often have
names that identify the same resource. For example, under
ARPA Internet naming support, USC-ISIF and ISIF both identify
same host. Similarly, in the case of mailboxes,
organizations provide many names that actually go to the
mailbox; for example Mockapetris@ISIF, Mockapetris@ISIB, etc.,
go to the same mailbox (although the mechanism behind this
somewhat complicated).
Most of these systems have a notion that one of the equivalent
of names is the canonical name and all others are aliases
The domain system provides a similar feature using the
name (CNAME) RR. When a name server fails to find a desired RR
a set associated with some domain name, it checks to see if
resource set contains a CNAME record with a matching class.
so, the name server includes the CNAME record in the response,
continues the query at the domain name specified in the data
of the CNAME record
Suppose a name server was processing a query with QNAME=ISIF.ARPA
QTYPE=A, and QCLASS=IN, and had the following resource records
ISIF.ARPA CNAME IN F.ISI.ARPA
F.ISI.ARPA A IN 10.2.0.52
Both of these RRs would be returned in the response
In the above example, because ISIF.ARPA has no RRs other than
CNAME RR, the resources associated with ISIF.ARPA will appear
be exactly those associated with F.ISI.ARPA for the IN CLASS
Since the CNAME is effective only when the search fails, a
can also be used to construct defaults. For example, suppose
name server had the following set of RRs
F.ISI.ARPA A IN 10.2.0.52
F.ISI.ARPA MD IN F.ISI.ARPA
XXXX.ARPA CNAME IN F.ISI.ARPA
XXXX.ARPA MF IN A.ISI.ARPA
Using this database, type A queries for XXXX.ARPA would return
XXXX.ARPA CNAME RR and the F.ISI.ARPA A RR, but MAILA or
queries to XXXX.ARPA would return the XXXX.ARPA MF RR without
information from F.ISI.ARPA. This structure might be used to
Mockapetris [Page 18]
RFC 882 November 1983
Domain Names - Concepts and
mail addressed to XXXX.ARPA to A.ISI.ARPA and to direct TELNET
XXXX.ARPA to F.ISI.ARPA
In certain cases, an administrator may wish to associate
resource information for all or part of a domain. For example
the CSNET domain administrator may wish to establish IN class
forwarding for all hosts in the CSNET domain without
capability. In such a case, the domain system provides a
label "*" that matches any other label. Note that "*"
only a single label, and not zero or more than one label.
also that the "*" is distinct from the "*" values for QCLASS
QTYPE
The semantics of "*" depend upon whether it appears in a
domain name (QNAME) or in a RR in a database
When an "*" is used in a QNAME, it can only match a "*" in
resource record
When "*" appears in a RR in a database, it can never
an existing exact match. For example, if a name
received a query for the domain UDEL.CSNET, and had
RRs for both UDEL.CSNET and *.CSNET, the UDEL.CSNET RRs
be used and the *.CSNET RRs would be ignored. If a query
the same database specified FOO.CSNET, the *.CSNET RR would
used, but the corresponding labels from the QNAME would
the "*". Thus the FOO.CSNET query would match the *.CSNET
and return a RR for FOO.CSNET rather than *.CSNET
RRs containing "*" labels are copied exactly when zones
transfered via name server maintenance operations
These semantics are easily implemented by having the name
first search for an exact match for a query, and then
the leftmost label with a "*" and trying again, repeating
process until all labels became "*" or the search succeeded
TYPE=* in RRs is prohibited. If it were to be allowed,
requestor would have no way of interpreting the data in the
because this data is type dependent
CLASS=* is also prohibited. Similar effects can be achieved
QCLASS=*, and allowing both QCLASS=* and CLASS=* leads
complexities without apparent benefit
Mockapetris [Page 19]
RFC 882 November 1983
Domain Names - Concepts and
A
In our sample domain space, suppose we wanted
administrative control for the root, DDN, ARPA, CSNET, MIT and
domains. We might allocate name servers as follows
|(B.ISI.ARPA)
|(UDEL.CSNET)
+------------------+------------------+
| | |
DDN ARPA CSNET
|(JCS.DDN) |(F.ISI.ARPA) |(UDEL.ARPA
+-----+-----+ |(A.ISI.ARPA)+-----+-----+
| | | | | |
JCS ARMY NAVY | UDEL UCI
|
+--------+---------------+---------------+--------+
| | | | |
DTI MIT ISI UDEL NBS
|(AI.MIT.ARPA) |(F.ISI.ARPA)
+---+---+ +---+---+
| | | | |
DMS AI A B F
In this example the authoritative name server is shown
parentheses at the point in the domain tree at which is
control
Thus the root name servers are on B.ISI.ARPA and UDEL.CSNET,
DDN name server is on JCS.DDN, the CSNET domain server is
UDEL.ARPA, etc
In an actual system, all domains should have redundant
servers, but in this example only the ARPA domain has
servers A.ISI.ARPA and F.ISI.ARPA. (The B.ISI.ARPA and UDEL.
name servers happen to be not redundant because they
different classes.) The F.ISI.ARPA name server has authority
the ARPA domain, but delegates authority over the MIT.ARPA
to the name server on AI.MIT.ARPA. The A.ISI.ARPA name
also has authority over the ARPA domain, but delegates both
ISI.ARPA and MIT.ARPA domains to other name servers
Mockapetris [Page 20]
RFC 882 November 1983
Domain Names - Concepts and
B.ISI.ARPA Name server for " "
B.ISI.ARPA has the root name server for the IN class.
database might contain
Domain Resource Record
" " SOA IN A.ISI.ARPA
DDN NS IN JCS.DDN
ARPA NS IN F.ISI.ARPA
CSNET NS IN UDEL.ARPA
" " NS IN B.ISI.ARPA
" " NS CS UDEL.CSNET
JCS.DDN A IN 9.0.0.1
F.ISI.ARPA A IN 10.2.0.52
UDEL.CSNET A CS 302-555-0000
UDEL.ARPA A IN 10.0.0.96
The SOA record for the root is necessary so that the name
knows that it is authoritative for the root domain for class IN
The contents of the SOA resource record point back to A.ISI.
and denote that the master data for the zone of authority
originally from this host. The first three NS records
delegation of authority. The NS root entry for the B.ISI.
name server is necessary so that this name server knows
itself, and can respond correctly to a query for NS
about the root (for which it is an authority). The root entry
class CS denotes that UDEL.CSNET is the authoritative name
for the CS class root. UDEL.CSNET and UDEL.ARPA may or may
refer to the same name server; from this information it
impossible to tell
If this name server was sent a query specifying QTYPE=MAILA
QCLASS=IN, QNAME=F.ISI.ARPA, it would begin processing (using
previous algorithm) by determining that it was not an
for F.ISI.ARPA. The test would note that it had authority at " ",
but would also note that the authority was delegated at ARPA
never reestablished via another SOA. Thus the response
return the NS record for the domain ARPA
Any queries presented to this server with QCLASS=CS would
in the UDEL.CSNET NS record being returned in the response
Mockapetris [Page 21]
RFC 882 November 1983
Domain Names - Concepts and
F.ISI.ARPA Name server for ARPA and ISI.
In the same domain space, the F.ISI.ARPA database for the
ARPA and ISI.ARPA might be
Domain Resource Record
" " NS IN B.ISI.ARPA
" " NS CS CSNET.UDEL
ARPA SOA IN B.ISI.ARPA
ARPA NS IN A.ISI.ARPA
ARPA NS IN F.ISI.ARPA
MIT.ARPA NS IN AI.MIT.ARPA
ISI.ARPA SOA IN F.ISI.ARPA
ISI.ARPA NS IN F.ISI.ARPA
A.ISI.ARPA MD IN A.ISI.ARPA
ISI.ARPA MD IN F.ISI.ARPA
A.ISI.ARPA MF IN F.ISI.ARPA
B.ISI.ARPA MD IN B.ISI.ARPA
B.ISI.ARPA MF IN F.ISI.ARPA
F.ISI.ARPA MD IN F.ISI.ARPA
F.ISI.ARPA MF IN A.ISI.ARPA
DTI.ARPA MD IN DTI.ARPA
NBS.ARPA MD IN NBS.ARPA
UDEL.ARPA MD IN UDEL.ARPA
A.ISI.ARPA A IN 10.1.0.32
F.ISI.ARPA A IN 10.2.0.52
B.ISI.ARPA A IN 10.3.0.52
DTI.ARPA A IN 10.0.0.12
AI.MIT.ARPA A IN 10.2.0.6
DMS.MIT.ARPA A IN 10.1.0.6
NBS.ARPA A IN 10.0.0.19
UDEL.ARPA A IN 10.0.0.96
For the IN class, the SOA RR for ARPA denotes that this
server is authoritative for the domain ARPA, and that the
file for this authority is stored on B.ISI.ARPA. This
extends to ISI.ARPA, where the database delegates authority
to this name server in another zone, and doesn't include
domain MIT.ARPA, which is served by a name server on AI.MIT.ARPA
This name server is not authoritative for any data in the
class. It has a pointer to the root server for CS data
could be use to resolve CS class queries
Suppose this name server received a query of the
QNAME=A.ISI.ARPA, QTYPE=A, and QCLASS=IN. The authority
Mockapetris [Page 22]
RFC 882 November 1983
Domain Names - Concepts and
would notice the NS record for " ", its SOA at ARPA, a
at ISI.ARPA, and the reassumption of authority at ISI.ARPA.
it would know that it was an authority for this query. It
then find the A record for A.ISI.ARPA, and return a
containing this record
Another query might be QNAME=B.ISI.ARPA, QTYPE=MAILA, QCLASS=*.
In this case the name server would know that it cannot
authoritative because of the "*" value of QCLASS, and would
for records for domain B.ISI.ARPA that match. Assuming that
name server performs the additional record inclusion mentioned
the name server algorithm, the returned datagram would include
ISI.ARPA NS IN F.ISI.ARPA
" " NS CS UDEL.CSNET
B.ISI.ARPA MD IN B.ISI.ARPA
B.ISI.ARPA MF IN F.ISI.ARPA
B.ISI.ARPA A IN 10.3.0.52
F.ISI.ARPA A IN 10.2.0.52
If the query were QNAME=DMS.MIT.ARPA, QTYPE=MAILA, QCLASS=IN,
name server would discover that AI.MIT.ARPA was the
name server and return the following
MIT.ARPA NS IN AI.MIT.ARPA
AI.MIT.ARPA A IN 10.2.0.6
In this case, the requestor is directed to seek information
the MIT.ARPA domain name server residing on AI.MIT.ARPA
Mockapetris [Page 23]
RFC 882 November 1983
Domain Names - Concepts and
UDEL.ARPA and UDEL.CSNET name
In the previous discussion of the sample domain, we stated
UDEL.CSNET and UDEL.ARPA might be the same name server. In
example, we assume that this is the case. As such, the
server is an authority for the root for class CS, and an
for the CSNET domain for class IN
This name server deals with mail forwarding between the
Internet and CSNET systems. Its RRs illustrate one approach
solving this problem. The name server has the following
records
" " SOA CS UDEL.CSNET
" " NS CS UDEL.CSNET
" " NS IN B.ISI.ARPA
CSNET SOA IN UDEL.ARPA
CSNET NS IN UDEL.ARPA
ARPA NS IN A.ISI.ARPA
*.CSNET MF IN UDEL.ARPA
UDEL.CSNET MD CS UDEL.CSNET
UCI.CSNET MD CS UCI.CSNET
UDEL.ARPA MD IN UDEL.ARPA
B.ISI.ARPA A IN 10.3.0.52
UDEL.ARPA A IN 10.0.0.96
UDEL.CSNET A CS 302-555-0000
UCI.CSNET A CS 714-555-0000
Suppose this name server received a query of the
QNAME=UCI.CSNET, QTYPE=MAILA, and QCLASS=IN. The name
would discover it was authoritative for the CSNET domain
class IN, but would find no explicit mail data for UCI.CSNET
However, using the *.CSNET record, it would construct a reply
UCI.CSNET MF IN UDEL.ARPA
UDEL.ARPA A IN 10.0.0.96
If this name server received a query of the form QNAME=UCI.CSNET
QTYPE=MAILA, and QCLASS=CS, the name server would return
UCI.CSNET MD CS UCI.CSNET
UCI.CSNET A CS 714-555-0000
Note that although this scheme allows for forwarding of all
addressed as .CSNET, it doesn't help with names
have more than two components, e.g. A.B.CSNET. Although
problem could be "fixed" by a series of MF entries for *.*.CSNET
Mockapetris [Page 24]
RFC 882 November 1983
Domain Names - Concepts and
*.*.*.CSNET, etc, a more tasteful solution would be to introduce
cleverer pattern matching algorithm in the CSNET name server
Summary of requirements for name
The requirements for a name server are as follows
1. It must be recognized by its parent
2. It must have complete resource information for all
names for which it is the authority
3. It must periodically refresh authoritative information
a master file or name server which holds the master
4. If it caches information it must also handle TTL
for that information
5. It must answer simple queries
Inverse
Name servers may also support inverse queries that map
particular resource to a domain name or domain names that
that resource. For example, while a query might map a domain
to a host address, the corresponding inverse query might map
address back to the domain name
Implementation of this service is optional in a name server,
all name servers must at least be able to understand an
query message and return an error response
The domain system cannot guarantee the completeness or
of inverse queries because the domain system is organized
domain name rather than by host address or any other
type. In general, a resolver or other program that wishes
guarantee that an inverse query will work must use a name
that is known to have the appropriate data, or ask all
servers in a domain of interest
For example, if a resolver wishes to perform an inverse query
an arbitrary host on the ARPA Internet, it must consult a set
name servers sufficient to know that all IN data was considered
In practice, a single inverse query to a name server that has
fairly comprehensive database should satisfy the vast majority
inverse queries
A detailed discussion of inverse queries is contained in [14].
Mockapetris [Page 25]
RFC 882 November 1983
Domain Names - Concepts and
Completion
Some existing systems provide the ability to complete
specifications of arguments. The general principle is that
user types the first few characters of the argument and then
an escape character to prompt the system to complete the rest
Some completion systems require that the user type enough of
argument to be unique; others do not
Other systems allow the user to specify one argument and ask
system to fill in other arguments. For example, many mail
allow the user to specify a username without a host for local
delivery
The domain system defines name server completion transactions
perform the analogous service for the domain system
Implementation of this service is optional in a name server,
all name servers must at least be able to understand a
request and return an error response
When a resolver wishes to request a completion, it sends a
server a message that sets QNAME to the partial string, QTYPE
the type of resource desired, and QCLASS to the desired class
The completion request also includes a RR for the target domain
The target domain RR identifies the preferred location of
resource. In completion requests, QNAME must still have a
label to terminate the name, but its presence is ignored.
that a completion request is not a query, but shares some of
same field formats
For example, a completion request might contain QTYPE=A, QNAME=B
QCLASS=IN and a RR for ISI.ARPA. This request asks for
for a resource whose name begins with "B" and is "close"
ISI.ARPA. This might be a typical shorthand used in the
community which uses "B" as a way of referring to B.ISI.ARPA
The first step in processing a completion request is to look for
"whole label" match. When the name server receives the
mentioned above, it looks at all records that are of type A,
IN, and whose domain name starts (on the left) with the labels
QNAME, in this case, "B". If multiple records match, the
server selects those whose domain names match (from the right)
most labels of the preferred domain name. If there are
multiple candidates, the name server selects the records that
the shortest (in terms of octets in the name) domain name.
several records remain, then the name server returns them all
If no records are found in the previous algorithm, the name
assumes that the rightmost label in QNAME is not complete,
Mockapetris [Page 26]
RFC 882 November 1983
Domain Names - Concepts and
looks for records that match but require addition of characters
the rightmost label of QNAME. For example, the previous
would not match BB.ARPA to B, but this search would. If
hits are found, the same discarding strategy is followed
A detailed discussion of completion can be found in [14].
Resolvers are programs that interface user programs to domain
servers. In the simplest case, a resolver receives a request
a user program (e.g. mail programs, TELNET, FTP) in the form of
subroutine call, system call etc., and returns the
information in a form compatible with the local host's
formats
Because a resolver may need to consult several name servers,
amount of time that a resolver will take to complete can vary
This variance is part of the justification for the split
name servers and resolvers; name servers may use datagrams
have a response time that is essentially equal to network
plus a short service time, while resolvers may take an
indeterminate amount of time
We expect to see two types of resolvers: simple resolvers that
chain through multiple name servers when required, and
complicated resolvers that cache resource records for use
future queries
Simple
A simple resolver needs the following capabilities
1. It must know how to access a name server, and should know
authoritative name server for the host that it services
2. It must know the protocol capabilities for its clients so
it can set the class fields of the queries it sends to
information that is useful to its clients. If the
serves a client that has multiple protocol capabilities,
should be able to support the preferences of the client
The resolver for a multiple protocol client can either
information for all classes using the * class value, or
on the classes supported by the client. Note that in
case, the resolver must understand the preferences of the host
For example, the host that supports both CSNET and
Mockapetris [Page 27]
RFC 882 November 1983
Domain Names - Concepts and
Internet protocols might prefer mail delivery (MD) to
forwarding (MF), regardless of protocol, or might prefer
protocol regardless of whether MD or MF is required. Care
required to prevent loops
3. The resolver must be capable of chaining through multiple
servers to get to an authoritative name server for any query
The resolver should guard against loops in referrals; a
policy is to discard referrals that don't match more of
query name than the referring name server, and also to
querying the same name server twice (This test should be
using addresses of name servers instead of domain names
avoid problems when a name server has multiple domain names
errors are present in aliases).
4. The resolver must be able to try alternate name servers when
name server doesn't respond
5. The resolver must be able to communicate different
conditions to its client. These failure conditions
unknown domain name, unknown resource for a know domain name
and inability to access any of the authoritative name
for a domain
6. If the resolver uses datagrams for queries, it must
from lost and duplicate datagrams
Resolvers with cache
Caching provides a tool for improving the performance of
service, but also is a potential source of incorrect results.
example, a database might cache information that is later
in the authoritative name servers. While this problem can't
eliminated without eliminating caching, it can be reduced to
infrequent problem through the use of timeouts
When name servers return resource records, each record has
associated time-to-live (TTL) field. This field is expressed
seconds, and has 16 bits of significance
When a resolver caches a returned resource record it must
remember the TTL field. The resolver must discard the record
the equivalent amount of time has passed. If the resolver
a database with a name server, it must decrement the TTL field
imported records periodically rather than simply deleting
record. This strategy is necessary to avoid exporting a
record whose TTL field doesn't reflect the amount of time that
resource record has been cached. Of course, the resolver
Mockapetris [Page 28]
RFC 882 November 1983
Domain Names - Concepts and
not decrement the TTL fields of records for which the
name server is an authority
Mockapetris [Page 29]
RFC 882 