sources-request@genrad.UUCP (03/06/85)
[ I let this article go through without splitting it up because I didn't ]
[ realize that it was over 64K long. Unfortunately, at least one site ]
[ truncated it at the 64K border, and so the tail end was lost. I am ]
[ re-posting the end of the article (page 21 and up) with the introductory ]
[ page at the beginning. Anyone who wants the entire article, and didn't ]
[ get it the first time, should be able to patch the two peices together ]
[ ]
[ - John Nelson (moderator mod.sources) ]
From: joe@fluke (Joe Kelsey)
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. |
| |
+-----------------------------------------------------+
RFC 882 November 1983
Domain Names - Concepts and Facilities
B.ISI.ARPA Name server for " "
B.ISI.ARPA has the root name server for the IN class. Its
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 server
knows that it is authoritative for the root domain for class IN.
The contents of the SOA resource record point back to A.ISI.ARPA
and denote that the master data for the zone of authority is
originally from this host. The first three NS records denote
delegation of authority. The NS root entry for the B.ISI.ARPA
name server is necessary so that this name server knows about
itself, and can respond correctly to a query for NS information
about the root (for which it is an authority). The root entry for
class CS denotes that UDEL.CSNET is the authoritative name server
for the CS class root. UDEL.CSNET and UDEL.ARPA may or may not
refer to the same name server; from this information it is
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 the
previous algorithm) by determining that it was not an authority
for F.ISI.ARPA. The test would note that it had authority at " ",
but would also note that the authority was delegated at ARPA and
never reestablished via another SOA. Thus the response would
return the NS record for the domain ARPA.
Any queries presented to this server with QCLASS=CS would result
in the UDEL.CSNET NS record being returned in the response.
Mockapetris [Page 21]
RFC 882 November 1983
Domain Names - Concepts and Facilities
F.ISI.ARPA Name server for ARPA and ISI.ARPA
In the same domain space, the F.ISI.ARPA database for the domains
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 name
server is authoritative for the domain ARPA, and that the master
file for this authority is stored on B.ISI.ARPA. This zone
extends to ISI.ARPA, where the database delegates authority back
to this name server in another zone, and doesn't include the
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 CS
class. It has a pointer to the root server for CS data which
could be use to resolve CS class queries.
Suppose this name server received a query of the form
QNAME=A.ISI.ARPA, QTYPE=A, and QCLASS=IN. The authority search
RFC 882 November 1983
Domain Names - Concepts and Facilities
would notice the NS record for " ", its SOA at ARPA, a delegation
at ISI.ARPA, and the reassumption of authority at ISI.ARPA. Hence
it would know that it was an authority for this query. It would
then find the A record for A.ISI.ARPA, and return a datagram
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 be
authoritative because of the "*" value of QCLASS, and would look
for records for domain B.ISI.ARPA that match. Assuming that the
name server performs the additional record inclusion mentioned in
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, the
name server would discover that AI.MIT.ARPA was the authoritative
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 from
the MIT.ARPA domain name server residing on AI.MIT.ARPA.
Mockapetris [Page 23]
RFC 882 November 1983
Domain Names - Concepts and Facilities
UDEL.ARPA and UDEL.CSNET name server
In the previous discussion of the sample domain, we stated that
UDEL.CSNET and UDEL.ARPA might be the same name server. In this
example, we assume that this is the case. As such, the name
server is an authority for the root for class CS, and an authority
for the CSNET domain for class IN.
This name server deals with mail forwarding between the ARPA
Internet and CSNET systems. Its RRs illustrate one approach to
solving this problem. The name server has the following resource
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 form
QNAME=UCI.CSNET, QTYPE=MAILA, and QCLASS=IN. The name server
would discover it was authoritative for the CSNET domain under
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 mail
addressed as <anything>.CSNET, it doesn't help with names that
have more than two components, e.g. A.B.CSNET. Although this
problem could be "fixed" by a series of MF entries for *.*.CSNET,
Mockapetris [Page 24]
RFC 882 November 1983
Domain Names - Concepts and Facilities
*.*.*.CSNET, etc, a more tasteful solution would be to introduce a
cleverer pattern matching algorithm in the CSNET name server.
Summary of requirements for name servers
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 domain
names for which it is the authority.
3. It must periodically refresh authoritative information from
a master file or name server which holds the master.
4. If it caches information it must also handle TTL management
for that information.
5. It must answer simple queries.
Inverse queries
Name servers may also support inverse queries that map a
particular resource to a domain name or domain names that have
that resource. For example, while a query might map a domain name
to a host address, the corresponding inverse query might map the
address back to the domain name.
Implementation of this service is optional in a name server, but
all name servers must at least be able to understand an inverse
query message and return an error response.
The domain system cannot guarantee the completeness or uniqueness
of inverse queries because the domain system is organized by
domain name rather than by host address or any other resource
type. In general, a resolver or other program that wishes to
guarantee that an inverse query will work must use a name server
that is known to have the appropriate data, or ask all name
servers in a domain of interest.
For example, if a resolver wishes to perform an inverse query for
an arbitrary host on the ARPA Internet, it must consult a set of
name servers sufficient to know that all IN data was considered.
In practice, a single inverse query to a name server that has a
fairly comprehensive database should satisfy the vast majority of
inverse queries.
A detailed discussion of inverse queries is contained in [14].
Mockapetris [Page 25]
RFC 882 November 1983
Domain Names - Concepts and Facilities
Completion services
Some existing systems provide the ability to complete partial
specifications of arguments. The general principle is that the
user types the first few characters of the argument and then hits
an escape character to prompt the system to complete the rest.
Some completion systems require that the user type enough of the
argument to be unique; others do not.
Other systems allow the user to specify one argument and ask the
system to fill in other arguments. For example, many mail systems
allow the user to specify a username without a host for local mail
delivery.
The domain system defines name server completion transactions that
perform the analogous service for the domain system.
Implementation of this service is optional in a name server, but
all name servers must at least be able to understand a completion
request and return an error response.
When a resolver wishes to request a completion, it sends a name
server a message that sets QNAME to the partial string, QTYPE to
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 the
resource. In completion requests, QNAME must still have a null
label to terminate the name, but its presence is ignored. Note
that a completion request is not a query, but shares some of the
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 completion
for a resource whose name begins with "B" and is "close" to
ISI.ARPA. This might be a typical shorthand used in the ISI
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 a
"whole label" match. When the name server receives the request
mentioned above, it looks at all records that are of type A, class
IN, and whose domain name starts (on the left) with the labels of
QNAME, in this case, "B". If multiple records match, the name
server selects those whose domain names match (from the right) the
most labels of the preferred domain name. If there are still
multiple candidates, the name server selects the records that have
the shortest (in terms of octets in the name) domain name. If
several records remain, then the name server returns them all.
If no records are found in the previous algorithm, the name server
assumes that the rightmost label in QNAME is not complete, and
Mockapetris [Page 26]
RFC 882 November 1983
Domain Names - Concepts and Facilities
looks for records that match but require addition of characters to
the rightmost label of QNAME. For example, the previous search
would not match BB.ARPA to B, but this search would. If multiple
hits are found, the same discarding strategy is followed.
A detailed discussion of completion can be found in [14].
RESOLVERS
Introduction
Resolvers are programs that interface user programs to domain name
servers. In the simplest case, a resolver receives a request from
a user program (e.g. mail programs, TELNET, FTP) in the form of a
subroutine call, system call etc., and returns the desired
information in a form compatible with the local host's data
formats.
Because a resolver may need to consult several name servers, the
amount of time that a resolver will take to complete can vary.
This variance is part of the justification for the split between
name servers and resolvers; name servers may use datagrams and
have a response time that is essentially equal to network delay
plus a short service time, while resolvers may take an essentially
indeterminate amount of time.
We expect to see two types of resolvers: simple resolvers that can
chain through multiple name servers when required, and more
complicated resolvers that cache resource records for use in
future queries.
Simple resolvers
A simple resolver needs the following capabilities:
1. It must know how to access a name server, and should know the
authoritative name server for the host that it services.
2. It must know the protocol capabilities for its clients so that
it can set the class fields of the queries it sends to return
information that is useful to its clients. If the resolver
serves a client that has multiple protocol capabilities, it
should be able to support the preferences of the client.
The resolver for a multiple protocol client can either collect
information for all classes using the * class value, or iterate
on the classes supported by the client. Note that in either
case, the resolver must understand the preferences of the host.
For example, the host that supports both CSNET and ARPA
Mockapetris [Page 27]
RFC 882 November 1983
Domain Names - Concepts and Facilities
Internet protocols might prefer mail delivery (MD) to mail
forwarding (MF), regardless of protocol, or might prefer one
protocol regardless of whether MD or MF is required. Care is
required to prevent loops.
3. The resolver must be capable of chaining through multiple name
servers to get to an authoritative name server for any query.
The resolver should guard against loops in referrals; a simple
policy is to discard referrals that don't match more of the
query name than the referring name server, and also to avoid
querying the same name server twice (This test should be done
using addresses of name servers instead of domain names to
avoid problems when a name server has multiple domain names or
errors are present in aliases).
4. The resolver must be able to try alternate name servers when a
name server doesn't respond.
5. The resolver must be able to communicate different failure
conditions to its client. These failure conditions include
unknown domain name, unknown resource for a know domain name,
and inability to access any of the authoritative name servers
for a domain.
6. If the resolver uses datagrams for queries, it must recover
from lost and duplicate datagrams.
Resolvers with cache management
Caching provides a tool for improving the performance of name
service, but also is a potential source of incorrect results. For
example, a database might cache information that is later changed
in the authoritative name servers. While this problem can't be
eliminated without eliminating caching, it can be reduced to an
infrequent problem through the use of timeouts.
When name servers return resource records, each record has an
associated time-to-live (TTL) field. This field is expressed in
seconds, and has 16 bits of significance.
When a resolver caches a returned resource record it must also
remember the TTL field. The resolver must discard the record when
the equivalent amount of time has passed. If the resolver shares
a database with a name server, it must decrement the TTL field of
imported records periodically rather than simply deleting the
record. This strategy is necessary to avoid exporting a resource
record whose TTL field doesn't reflect the amount of time that the
resource record has been cached. Of course, the resolver should
Mockapetris [Page 28]
RFC 882 November 1983
Domain Names - Concepts and Facilities
not decrement the TTL fields of records for which the associated
name server is an authority.
Mockapetris [Page 29]
RFC 882 November 1983
Domain Names - Concepts and Facilities
Appendix 1 - Domain Name Syntax Specification
The preferred syntax of domain names is given by the following BNF
rules. Adherence to this syntax will result in fewer problems with
many applications that use domain names (e.g., mail, TELNET). Note
that some applications described in [14] use domain names containing
binary information and hence do not follow this syntax.
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <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.
The labels must follow the rules for ARPANET host names. They must
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 ARPA
Internet:
F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPA
Mockapetris [Page 30]
RFC 882 November 1983
Domain Names - Concepts and Facilities
REFERENCES and BIBLIOGRAPHY
[1] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD Internet
Host Table Specification", RFC 810, Network Information Center,
SRI International, March 1982.
[2] J. Postel, "Computer Mail Meeting Notes", RFC 805,
USC/Information Sciences Institute, February 1982.
[3] Z. Su, and J. Postel, "The Domain Naming Convention for Internet
User Applications", RFC 819, Network Information Center, SRI
International, August 1982.
[4] Z. Su, "A Distributed System for Internet Name Service",
RFC 830, Network Information Center, SRI International,
October 1982.
[5] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC 812, Network
Information Center, SRI International, March 1982.
[6] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET Name
Server", Computer Networks, vol 6, nr 3, July 1982.
[7] K. Harrenstien, "NAME/FINGER", RFC 742, Network Information
Center, SRI International, December 1977.
[8] J. Postel, "Internet Name Server", IEN 116, USC/Information
Sciences Institute, August 1979.
[9] K. Harrenstien, V. White, and E. Feinler, "Hostnames Server",
RFC 811, Network Information Center, SRI International,
March 1982.
[10] J. Postel, "Transmission Control Protocol", RFC 793,
USC/Information Sciences Institute, September 1981.
[11] J. Postel, "User Datagram Protocol", RFC 768, USC/Information
Sciences Institute, August 1980.
[12] J. Postel, "Simple Mail Transfer Protocol", RFC 821,
USC/Information Sciences Institute, August 1980.
[13] J. Reynolds, and J. Postel, "Assigned Numbers", RFC 870,
USC/Information Sciences Institute, October 1983.
[14] P. Mockapetris, "Domain Names - Implementation and
Specification", RFC 883, USC/Information Sciences Institute,
November 1983.
Mockapetris [Page 31]