MOCKAPETRIS at USC-ISIF -- 26 May 1983 -- namedroppers at SRI-NIC ----------------------------------------------------------------- Network Working Group P. Mockapetris Request for Comments: DRAFT ISI May 1983 DOMAIN NAMES - CONCEPTS and FACILITIES VERY ROUGH DRAFT of 26 May 83 2:49PM +-----------------------------------------------------+ | | | This memo discusses the domain style names, their | | use for mail and Internet host address references, | | and the operation of name servers which store | | information bound to domain names. This memo | | presents the specification for the domain name | | space and its operation, but does not deal with the | | specifics of formats, timeouts, etc. That | | information is presented in separate RFCs. | | | | Nothing in this memo is to be taken as final policy | | or official protocol specification. It is hoped | | this memo will stimulate discussion and lead to the | | eventual adoption of standards for the Internet. | | | +-----------------------------------------------------+ INTRODUCTION The need for domain names As applications grow to span multiple hosts, then networks, and finally internets, these applications must also span multiple administrative boundaries and related methods of operation (protocols, data formats, etc). The number of resources (for example mailboxes), the number of locations for resources, and the diversity of such an environment cause formidable problems when we wish to create consistent methods for referencing particular resources that are similar but scattered throughout the environment. The Internet illustrates the size-related problems; the Internet is a large system and is likely to grow much larger. The need to have a mapping between host names (e.g., USC-ISIF) and internet addresses (e.g., 10.2.0.52) is beginning to stress the existing mechanisms. Currently all the hosts in the Internet are registered with the Network Information Center (NIC) and listed in a global table (available as the file HOSTS.TXT on the SRI-NIC host) [1]. The size of this table, and especially the frequency of updates to the table are near the limit of manageability. What is needed is a distributed database that performs the same function, and hence avoids the problems caused by a centralized database. Mockapetris [Page 1] RFC DRAFT May 1983 Domain Names - Concepts and Facilities The problem for computer mail is more severe. While mail system implementers long ago recognized the impossibility of centralizing mailbox names, they have also created an increasingly large and irregular set of methods for identifying the location of a mailbox. Some of these methods involve the use of routes and forwarding hosts as part of the mail destination address, and consequently force the mail user to know multiple address formats, the capabilities of various forwarders, and ad hoc tricks for passing address specifications through intermediaries. These problems have common characteristics that suggest the nature of any solution: The basic need is for a consistent name space which will be used for referring to resources. In order to avoid the problems caused by ad hoc encodings, names should not attempt to contain addresses, routes, or similar information as part of the name per se. The sheer size of the database and frequency of updates suggest that it must be maintained in a distributed manner, perhaps with local caching to improve performance. Approaches that attempt to collect a consistent copy of the entire database will become more and more expensive and difficult, and hence should be avoided. The same principle holds for the structure of the name space, and in particular mechanisms for the creating and deleting names; these should also be distributed. The costs of implementing such a facility dictate that it be generally useful, and not restricted to a single application. We should be able to use names to retrieve host addresses, mailbox data, and other as yet undetermined information. Beacuse we want the name space to be useful in dissimilar networks, it is unlikely that all users of names will be able to agree on the set of resources or resource information that names will be used to retrieve. Hence names refer to a set of resources, and queries contain resource identifiers. The only standard type of information that we expect to see throughout the name space is structuring information for the name space itself. Elements of the solution The propsed solution has three major components: The DOMAIN NAME SPACE, which is a specification for a tree structured name space. Conceptually, each node and leaf of the domain name space tree names a set of information, and query Mockapetris [Page 2] RFC DRAFT May 1983 Domain Names - Concepts and Facilities 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, one service uses domain names to identify Internet hosts, and queries for that service return Internet host addresses. However, to preserve the generality of the domain mechanism, domain names do not have a one-to-one correspondance with host names, host addresses, or any other type of information. Furthurmore, the address query mechanism allows other classes of addresses (e.g. phone numbers, Ethernet addresses) to use the same support. NAME SERVERS are repositories for 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 an AUTHORITY for these parts of the name space. Queries to name servers as well as the responses name servers return are designed to be suitable for datagrams. RESOLVERS are programs that extract information from name servers in response to user requests. Resolvers must be able to access at least one name server and use that name server's information to answer a query directly, or discover an authoritative name server. A resolver will typically be a system routine that is directly accessible to user programs; hence no protocol is necessary. DOMAIN NAME SPACE Name space specifications and terminology The domain name space is a tree structure. Each node and leaf on the tree corresponds to a resource set (which may be empty). Each node and leaf has an associated label. Labels are NOT guaranteed to be unique, with the exception of the root node, which has a null label. The domain name of a node or leaf is the path from the root of the tree to the node or leaf. By convention, the labels that compose a domain name are read left to right, from the most specific (lowest) to the least specific (highest); labels in a path are separated by dots ("."). The root label and its associated dot are omitted from domain names, but the root can be named by a null domain name (" " in this memo). A special label is defined that matches any other label. This Mockapetris [Page 3] RFC DRAFT May 1983 Domain Names - Concepts and Facilities 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 for resource records at the boundary between protocol families, and requires prudence in its use. A domain is identified by a domain name, and consists of that part of the domain name space that is at or below the domain name which specifies the domain. A domain is a subdomain of another domain if it is contained within that domain. This relationship can be tested by seeing if the subdomain's name has the containing domain's name as the left part of its name. For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ". This tree structure is intended to parallel the administrative organization and delegation of authority. Potentially, each node or leaf on the tree can create new subdomains ad infinitum. In practice, this delegation can be limited by the name servers that store the domain space and resource data. The following figure shows an example domain name space. | +------------------+------------------+ | | | COLORS FLAVORS TRUTH | | +-----+-----+ | | | | NATURAL RED BLUE GREEN | | +---------------+---------------+ | | | CHOCOLATE VANILLA STRAWBERRY In this example, the root domain has three immediate subdomains: COLORS, FLAVORS, and TRUTH. The FLAVORS domain has one immediate subdomain named NATURAL.FLAVORS. All of the leaves are also domains. This domain tree has the names " "(the root), COLORS, RED.COLORS, BLUE.COLORS, GREEN.COLORS, FLAVORS, NATURAL.FLAVORS, CHOCOLATE.NATURAL.FLAVORS, VANILLA.NATURAL.FLAVORS, STRAWBERRY.NATURAL.FLAVORS, and TRUTH. If we wished to add a new domain of ARTIFICIAL under FLAVORS, FLAVORS would typically be the administrative entity that would decide; if we wished to create CHIP and MOCHA names under CHOCOLATE, CHOCOLATE.NATURAL.FLAVORS would typically be the appropriate administrative entity. Mockapetris [Page 4] RFC DRAFT May 1983 Domain Names - Concepts and Facilities Resource set information A domain name identifies a set of resource information. The set of resource information associated with a particular name is composed of separate resource records. Resource records have type and class fields that are standard throughout the domain name system, although some systems that use domain names may implement or understand only a few types and classes. Types refer to abstract functions such as mail routing or host name to address conversion; classes refer to protocol families or methods of operation such as the Internet protocols or CSNET mail system. Resouces records can only be interpreted with the knowledge of the domain in which they reside. This memo uses the following types: A - the host address associated with the domain name MF - identifies a mail forwarder for the domain MD - identifies a mail destination for the domain NS - the authoritative name server for the domain * - any type except NS This memo uses the following classes: IN - the Internet system CS - the CSNET system * - any other class The first type of resource record holds a host name to host address binding. Its fields are: --------+--------+--------------//----------------------+ | A | CLASS | class specific address information | +--------+--------+--------------//----------------------+ Mockapetris [Page 5] RFC DRAFT May 1983 Domain Names - Concepts and Facilities The content of the class specific information varies according to the value in the CLASS field; for the Internet, it is the 32 bit Internet address of the host, for the CSNET it might be the phone number of the host. For example, F.ISI.ARPA might have two A records of the form: +--------+--------+--------------------------------------+ | A | IN | 10.2.0.52 | +--------+--------+--------------------------------------+ and +--------+--------+--------------------------------------+ | A | CS | (213)-822-2112 | +--------+--------+--------------------------------------+ The mail forwarder (MF) and mail delivery (MD) records have the following format: --------+--------+--------------------------------------+ | MD/MF | CLASS | | +--------+--------+--------------------------------------+ The field is a domain name of the host that will handle mail; note that this domain name may be completely different from the domain name which names the resource record. For example, F.ISI.ARPA might have two records of the form: +--------+--------+--------------------------------------+ | MD | IN | F.ISI.ARPA | +--------+--------+--------------------------------------+ and +--------+--------+--------------------------------------+ | MF | IN | B.ISI.ARPA | +--------+--------+--------------------------------------+ These records mean that mail for F.ISI.ARPA can either be delivered to the host F.ISI.ARPA or forwarded to B.ISI.ARPA, which will acccept responsibility for its eventual delivery. In principle, an additional name lookup is required to map the domain name of the host to the appropriate address, in practice this information is usually returned in the response to the mail query. The last type of resource record is the authoritative name server for the domain name. This resource record has a standard format for all of the name space: +--------+--------+--------+-----------------------------+ | NS | TYPE | CLASS | | +--------+--------+--------+-----------------------------+ Mockapetris [Page 6] RFC DRAFT May 1983 Domain Names - Concepts and Facilities This record says that a name server which is cognizant of records of the given TYPE and CLASS can be found at . Queries Queries to a name server must include a domain name which identifies the target resource set, and the class and type of desired resource records. The type and class fields in a query can include any of the corresponding type and class fields that are defined for resource records. In addition, the type field in a query may contain the following special type: MAIL - returns both MD and MF types. May also return A records for the domain names identified in the returned MD and MF records. The name server will look for all resource records for the specified domain name that have the proper type and class. If the name server has delegated authority to a subservient name server, it may simply return the domain name of the subservient name server. Example space For purposes of exposition, the following name space is used for 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 7] RFC DRAFT May 1983 Domain Names - Concepts and Facilities NAME SERVERS Introduction Name servers store a distributed database consisting of the structure of the domain name space, the resource sets associated with domain names, and other information used to coordinate actions between name servers. In general, a name server will be an authority for all or part of a particular domain. When presented with a query for a domain name over which it has authority, a name server returns the desired resource information or an indication that the query refers to a domain name or resource that does not exist. If a name server is presented with a query for a domain name that is not within its authority, it may have the desired information, but it will also return a response that points toward an authoritative name server. If a name server is not an authority for a query, it can never return a negative response. There is no requirement that a name server for a domain reside in a host which is in the same domain, although this will usually be the case. There is also no restriction on the number of name servers that can have authority over a particular domain; most domains will have redundant authoritative name servers. Name server functions are designed to allow for very simple implementations of name servers. The simplest name server has a static set of information and uses datagrams to receive queries and return responses. More sophisticated name server implementations can improve the performance of their clients by caching information from other domains. Although this information can be acquired in a number of ways, the normal method is to store the information acquired by a resolver when the resolver consults other name servers. In a sophisticated host, the resolver and name server will coordinate their actions and use a shared database. This cooperation requires the incorporation of a time-to-live (TTL) field in all resource records. Caching is discussed in the resolver section of this memo; this section is devoted to the actions of a name servers that don't cache. In order to free simple name servers of the requirement of managing these timeouts, simple name servers should only contain resource records that are expected to remain constant over very long periods or resource records for which the name server is an authority. In the following discussion, the TTL field is assumed Mockapetris [Page 8] RFC DRAFT May 1983 Domain Names - Concepts and Facilities to be stored in the resource record but is omitted in descriptions of databases and responses in the interest of clarity. Authority and administrative control of domains Although we want to have the potential of delegating the priviledges of name space management at every node, we don't want such delegation to be required. Hence we introduce the concept of authority. Authority is vested in name servers. A name server has authority over all of its domain until it delegates authority for a subdomain to some other name server. Any administrative entity that wishes to establish its own domain must provide a name server, and have that server accepted by the parent name server (i.e. the name server that has authority over the place in the domain name space that will hold the new domain). While the principles of authority allow acceptance to be at the discretion of parent name servers, the following criteria are used by the root, and are recommended to all name servers because they are responsible for their children's actions: 1. It must register with the central 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 avoid name conflicts and to make the domain related information available to other domains. The central administrator may have further requirements, and a domain is not registered until the central administrator agrees that all requirements are met. There must be a responsible person associated with each domain to be a contact point for questions about the domain, to verify and update the domain related information, and to resolve any problems (e.g., protocol violations) with hosts in the domain. The domain must provide redundant (i.e., two or more) name servers to provide the name to address resolution service. These name servers must be accessible from outside the domain (as well as inside) and must resolve names for at least all the hosts in the domain. Name server logic The processing steps that a name server performs in responding to Mockapetris [Page 9] RFC DRAFT May 1983 Domain Names - Concepts and Facilities a query are conceptually simple, although implementations may have internal databases that are quite complex. For purposes of explanation, we assume that the query consists of a type QTYPE, a class QCLASS, and a domain name QNAME; we assume that the name server stores COUNT resource records in array RR(i) and that DNAME(i) is the domain name for RR[i]. We also use right(name,n) to denote the rightmost n components of a domain name, and ord(name) to denote the number of components in name. For example, right(B.ISI.ARPA,2) equals ISI.ARPA and right(anything,0) is the null string. The name server code could be represented as the following sequence of steps: 1. Initialize the output datagram buffer to empty, set name_found and record_found to false. 2. Find the authoritative name server or servers for QNAME. The method is to look for all RR that have a RNAME=QNAME and a type of NS. If no records are found, look for NS records for QNAME less its leftmost component. Keep removing components until a NS is found. The code might look like: for i=ord(QNAME) step -1 to 0 do begin for j=1 to COUNT ; look for authorities do if right(QNAME,i)=RNAME[j] and type(RN[j])=NS then add j to authorities list; if authorities is not empty then go to step 3 end This algorithm relies on the fact that the resource record set will contain NS records for all name servers to which this name server has delegated authority. The delegatees will have longer names, and hence will be found first. This scheme also allows a name server to be authoritative for an arbitrary number of disjoint regions of the domain name space. Note that the search will always terminate because each name server is required to have a pointer to an authoritative name server for the root. 3. See if the RR array contains any records which match QNAME. If any are found, set name_found to true. If any of the records have types that match QTYPE and classes that match QCLASS as well, put them in the output datagram, and set record_found to true. Mockapetris [Page 10] RFC DRAFT May 1983 Domain Names - Concepts and Facilities 4. If the authority list includes this name server, go to step 5. Note that this test must include all names which this server is known by. Otherwise, copy the resource records specified by the authorities list into the output datagram and go to step 6. 5. Since this name server is an authority for the QNAME, if the output datagram is empty, then either QNAME doesn't exist or there is no compatible resource for QNAME. Use name_found and record_found to separate these cases and return either the "Domain name does not exist" or "No such resource" error messages. If the output datagram is not empty, no action is required. 6. If the output datagram contains any MD or MF records, look to see if there are A records for the domain names contained in the records (not the domain names which were used to refer to the MD and MF records themselves). If so, append these A records to the output datagram. This procedure is optional. 7. Send the output datagram. Processing is complete. The effect of this algorithm is to return the information pertinent to the query first, followed by a list of name servers that are "closer" to the domain name than the server that answered the query. If the name server is authoritative, then the name server list is not copied and a failure may be returned. The process that sent the query, typically a resolver, may receive an answer that is simply a list of name servers and has no information that is directly relevant to the query. In this case it can resend the query to one of the returned names. This will eventually lead to an authoritative name server or reach an impass when a name server for the proper class cannot be found. Mockapetris [Page 11] RFC DRAFT May 1983 Domain Names - Concepts and Facilities A scenario In our sample domain space, suppose we wanted separate administrative control for the root, DDN, ARPA, CSNET, MIT and ISI domains. We might allocate name servers as follows: |(B.ISI.ARPA) +------------------+------------------+ | | | 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 in parentheses at the point in the domain tree at which is assumes control. Thus the root name server is on B.ISI.ARPA, the DDN name server is on JCS.DDN, the CSNET domain server is on ARPA.UDEL, etc. In an actual system, all domains should have redundant name servers, but in this example only the ARPA domain has redundant servers A.ISI.ARPA and F.ISI.ARPA. The F.ISI.ARPA name server has authority over the ARPA domain, but delegates authority over the MIT.ARPA domain to the name server on AI.MIT.ARPA. The A.ISI.ARPA name server also has authority over the ARPA domain, but delgates both the ISI.ARPA and MIT.ARPA domains to other name servers. Mockapetris [Page 12] RFC DRAFT May 1983 Domain Names - Concepts and Facilities B.ISI.ARPA Name server for " " B.ISI.ARPA has the root name server. Its database would have to contain: Domain Resource Record " " NS * * B.ISI.ARPA DDN NS * * JCS.DDN ARPA NS * * F.ISI.ARPA CSNET NS * CS UDEL.CSNET CSNET NS * IN UDEL.ARPA 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 NS record for the root is necessary so that the name server knows that it is authoritative for the root domain. The other four NS records denote delegation of authority. In this case, there are two name servers specified for CSNET; UDEL.ARPA for Internet style queries, and UDEL.CSNET for CSNET style queries. These two names may or may not refer to the same name server; from this information it is impossible to tell. If this server given a query for information about any domain name other than the root, it would return the appropriate NS resource record together with the address record that corresponds to the domain name in the returned record. Mockapetris [Page 13] RFC DRAFT May 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 ARPA NS * IN F.ISI.ARPA ARPA NS * IN A.ISI.ARPA MIT.ARPA NS * IN AI.MIT.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 MD IN F.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 Suppose this name server received a query of the form QNAME=A.ISI.ARPA, QTYPE=A, and QCLASS=IN. In the NS search in step 2 of our algorithm, the name server would match to the ISI.ARPA NS record (there is no NS record for A.ISI.ARPA), and then discover that this record points back to this name server. 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=MAIL, CLASS=*. In this case the name server would again determine that it was an authority, and would look for records for domain B.ISI.ARPA that match. Assuming that the name server follows the optional A record inclusion mentioned in step 7 of the name server algorithm, the returned datagram would include: Mockapetris [Page 14] RFC DRAFT May 1983 Domain Names - Concepts and Facilities 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=MAIL, 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. UDEL.ARPA Name server for CSNET The name server for CSNET deals with mail forwarding between the Internet and CSNET systems. The answers it gives for mail queries depend on the CLASS field of the query. In this example, the CSNET domain doesn't attempt to handle Internet address requests, although a similar mechanism might be used if it were appropriate. The name server has the following resource records: " " NS * IN B.ISI.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 MD A (302)-555-0000 UCI.CSNET MD A (714)-555-0000 Suppose this name server received a query of the form QNAME=UCI.CSNET, QTYPE=MAIL, and QCLASS=IN. In the NS search in step 2 of our algorithm, the name server would match to the CSNET NS record, and then discover that this record points back to this name server. Hence it would know that it was an authority for this query. It would then find the MF record for *.CSNET, and return a datagram containing this record and the IN type A record for UDEL.ARPA. Note that the UCI.CSNET MD record is not returned because its CLASS field does not match the query. If this name server received a query of the form QNAME=UCI.CSNET, Mockapetris [Page 15] RFC DRAFT May 1983 Domain Names - Concepts and Facilities QTYPE=MAIL, and QCLASS=CS, the name server would return the UCI.CSNET MD and A records. Note that although this scheme allows for forwarding of all mail addressed as X.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, *.*.*.CSNET, etc, a more tasteful solution would be to introduce a cleverer pattern matching algorithm in the CSNET name server. While we anticipate that the clever server approach would be used (and might even return MF records with labels instead of *), the single label match for * allows subdomains that are parts of both systems to short-circuit the forwarding function without requiring all name servers to be clever. 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 know all of the domain names of the host on which it resides. 3. It must have resource records for all name servers to which it has delegated authority. 4. It must have complete resource information for all domain names for which it is the authority. 5. It must answer datagram queries. 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 use datagrams and have a response time that is essentially equal to network delay plus a Mockapetris [Page 16] RFC DRAFT May 1983 Domain Names - Concepts and Facilities 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 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 require to prevent loops. 3. The resolver must be able to try alternate name servers when a name server doesn't respond. 4. 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. 5. The resolver must be capable of chaining through multiple name servers to get to an authoritative name server for any query. It must recover from lost datagrams 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 Mockapetris [Page 17] RFC DRAFT May 1983 Domain Names - Concepts and Facilities 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 periodicallly 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 not decrement the TTL fields of records for which the assocaited name server is an authority. Resolvers and completion Some 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. The following algorithm is recommeded for systems that implement completion in the interest of providing a consistent user interface throughout the domain system. However, the user should note that partial arguments will in general complete differently when run on different hosts, and that consistency throughout the systems that use the domain space is not guaranteed. The algorithm assumes access to the database of a name server that is at least authoritative for the domain of the host on which the completion request is made. 1. Collect all names which begin with the same characters as the partial, and which also have the desired resource type and class. For example, if we are completing a host name for Internet TELNET, only type A records with class IN will be considered. If there are none, go to step 4. If there are more than one, go to step 2. Otherwise complete the name. 2. Compare the collected names against the full name of the host on which the completion is performed. Find the name or names that have the most labels in common on the left end. Discard Mockapetris [Page 18] RFC DRAFT May 1983 Domain Names - Concepts and Facilities all others. If only one name remains, use it to complete the partial string. Otherwise go to step 3. 3. Find the name in the collected set that has the fewest number of labels in its name. Discard all names that have more labels. If only one name remains, use it to complete the partial. If more than one name remains, pick the name that has the fewest characters, and use it to complete the partial. 4. If this step is reached, the partial cannot be completed within the present database. If the resolver has access to a superior database, it can use it and begin over at step 1. Otherwise, return an unable to complete indication. Mockapetris [Page 19] RFC DRAFT May 1983 Domain Names - Concepts and Facilities Appendix 1 - Domain Name Syntax Specification The syntax of domain names is given by the following BNF rules. ::= | " " ::=