Network Working Group P. Mockapetris Request for Comments: 883 ISI November 1983 DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION +-----------------------------------------------------+ | | | This memo discusses the implementation of domain | | name servers and resolvers, specifies the format of | | transactions, and discusses the use of domain names | | in the context of existing mail systems and other | | network software. | | | | This memo assumes that the reader is familiar with | | RFC 882, "Domain Names - Concepts and Facilities" | | which discusses the basic principles of domain | | names and their use. | | | | The algorithms and internal data structures used in | | this memo are offered as suggestions rather than | | requirements; implementers are free to design their | | own structures so long as the same external | | behavior is achieved. | | | +-----------------------------------------------------+ +-----------------------------------------------+ | | | ***** WARNING ***** | | | | This RFC contains format specifications which | | are preliminary and are included for purposes | | of explanation only. Do not attempt to use | | this information for actual implementations. | | | +-----------------------------------------------+ Mockapetris [Page i] RFC 883 November 1983 Domain Names - Implementation and Specification TABLE OF CONTENTS INTRODUCTION........................................................3 Overview.........................................................3 Implementation components........................................2 Conventions......................................................6 Design philosophy................................................8 NAME SERVER TRANSACTIONS...........................................11 Introduction....................................................11 Query and response transport....................................11 Overall message format..........................................13 The contents of standard queries and responses..................15 Standard query and response example.............................15 The contents of inverse queries and responses...................17 Inverse query and response example..............................18 Completion queries and responses................................19 Completion query and response example...........................22 Recursive Name Service..........................................24 Header section format...........................................26 Question section format.........................................29 Resource record format..........................................30 Domain name representation and compression......................31 Organization of the Shared database.............................33 Query processing................................................36 Inverse query processing........................................37 Completion query processing.....................................38 NAME SERVER MAINTENANCE............................................39 Introduction....................................................39 Conceptual model of maintenance operations......................39 Name server data structures and top level logic.................41 Name server file loading........................................43 Name server file loading example................................45 Name server remote zone transfer................................47 RESOLVER ALGORITHMS................................................50 Operations......................................................50 DOMAIN SUPPORT FOR MAIL............................................52 Introduction....................................................52 Agent binding...................................................53 Mailbox binding.................................................54 Appendix 1 - Domain Name Syntax Specification......................56 Appendix 2 - Field formats and encodings...........................57 TYPE values.....................................................57 QTYPE values....................................................57 CLASS values....................................................58 QCLASS values...................................................58 Standard resource record formats................................59 Appendix 3 - Internet specific field formats and operations........67 REFERENCES and BIBLIOGRAPHY........................................72 INDEX..............................................................73 Mockapetris [Page ii] RFC 883 November 1983 Domain Names - Implementation and Specification INTRODUCTION Overview The goal of domain names is to provide a mechanism for naming resources in such a way that the names are usable in different hosts, networks, protocol families, internets, and administrative organizations. From the user's point of view, domain names are useful as arguments to a local agent, called a resolver, which retrieves information associated with the domain name. Thus a user might ask for the host address or mail information associated with a particular domain name. To enable the user to request a particular type of information, an appropriate query type is passed to the resolver with the domain name. To the user, the domain tree is a single information space. From the resolver's point of view, the database that makes up the domain space is distributed among various name servers. Different parts of the domain space are stored in different name servers, although a particular data item will usually be stored redundantly in two or more name servers. The resolver starts with knowledge of at least one name server. When the resolver processes a user query it asks a known name server for the information; in return, the resolver either receives the desired information or a referral to another name server. Using these referrals, resolvers learn the identities and contents of other name servers. Resolvers are responsible for dealing with the distribution of the domain space and dealing with the effects of name server failure by consulting redundant databases in other servers. Name servers manage two kinds of data. The first kind of data held in sets called zones; each zone is the complete database for a particular subtree of the domain space. This data is called authoritative. A name server periodically checks to make sure that its zones are up to date, and if not obtains a new copy of updated zones from master files stored locally or in another name server. The second kind of data is cached data which was acquired by a local resolver. This data may be incomplete but improves the performance of the retrieval process when non-local data is repeatedly accessed. Cached data is eventually discarded by a timeout mechanism. This functional structure isolates the problems of user interface, failure recovery, and distribution in the resolvers and isolates the database update and refresh problems in the name servers. Mockapetris [Page 1] RFC 883 November 1983 Domain Names - Implementation and Specification Implementation components A host can participate in the domain name system in a number of ways, depending on whether the host runs programs that retrieve information from the domain system, name servers that answer queries from other hosts, or various combinations of both functions. The simplest, and perhaps most typical, configuration is shown below: Local Host | Foreign | +---------+ +----------+ | +--------+ | | user queries | |queries | | | | User |-------------->| |---------|->|Foreign | | Program | | Resolver | | | Name | | |<--------------| |<--------|--| Server | | | user responses| |responses| | | +---------+ +----------+ | +--------+ | A | cache additions | | references | V | | +----------+ | | database | | +----------+ | User programs interact with the domain name space through resolvers; the format of user queries and user responses is specific to the host and its operating system. User queries will typically be operating system calls, and the resolver and its database will be part of the host operating system. Less capable hosts may choose to implement the resolver as a subroutine to be linked in with every program that needs its services. Resolvers answer user queries with information they acquire via queries to foreign name servers, and may also cache or reference domain information in the local database. Note that the resolver may have to make several queries to several different foreign name servers to answer a particular user query, and hence the resolution of a user query may involve several network accesses and an arbitrary amount of time. The queries to foreign name servers and the corresponding responses have a standard format described in this memo, and may be datagrams. Mockapetris [Page 2] RFC 883 November 1983 Domain Names - Implementation and Specification Depending on its capabilities, a name server could be a stand alone program on a dedicated machine or a process or processes on a large timeshared host. A simple configuration might be: Local Host | Foreign | +---------+ | / /| | +---------+ | +----------+ | +--------+ | | | | |responses| | | | | | | Name |---------|->|Foreign | | Master |-------------->| Server | | |Resolver| | files | | | |<--------|--| | | |/ | | queries | +--------+ +---------+ +----------+ | Here the name server acquires information about one or more zones by reading master files from its local file system, and answers queries about those zones that arrive from foreign resolvers. A more sophisticated name server might acquire zones from foreign name servers as well as local master files. This configuration is shown below: Local Host | Foreign | +---------+ | / /| | +---------+ | +----------+ | +--------+ | | | | |responses| | | | | | | Name |---------|->|Foreign | | Master |-------------->| Server | | |Resolver| | files | | | |<--------|--| | | |/ | | queries | +--------+ +---------+ +----------+ | A |maintenance | +--------+ | \------------|->| | | queries | |Foreign | | | | Name | \------------------|--| Server | maintenance responses | +--------+ In this configuration, the name server periodically establishes a virtual circuit to a foreign name server to acquire a copy of a zone or to check that an existing copy has not changed. The messages sent for these maintenance activities follow the same form as queries and responses, but the message sequences are somewhat different. Mockapetris [Page 3] RFC 883 November 1983 Domain Names - Implementation and Specification The information flow in a host that supports all aspects of the domain name system is shown below: Local Host | Foreign | +---------+ +----------+ | +--------+ | | user queries | |queries | | | | User |-------------->| |---------|->|Foreign | | Program | | Resolver | | | Name | | |<--------------| |<--------|--| Server | | | user responses| |responses| | | +---------+ +----------+ | +--------+ | A | cache additions | | references | V | | +----------+ | | Shared | | | database | | +----------+ | A | | +---------+ refreshes | | references | / /| | V | +---------+ | +----------+ | +--------+ | | | | |responses| | | | | | | Name |---------|->|Foreign | | Master |-------------->| Server | | |Resolver| | files | | | |<--------|--| | | |/ | | queries | +--------+ +---------+ +----------+ | A |maintenance | +--------+ | \------------|->| | | queries | |Foreign | | | | Name | \------------------|--| Server | maintenance responses | +--------+ The shared database holds domain space data for the local name server and resolver. The contents of the shared database will typically be a mixture of authoritative data maintained by the periodic refresh operations of the name server and cached data from previous resolver requests. The structure of the domain data and the necessity for synchronization between name servers and resolvers imply the general characteristics of this database, but the actual format is up to the local implementer. This memo suggests a multiple tree format. Mockapetris [Page 4] RFC 883 November 1983 Domain Names - Implementation and Specification This memo divides the implementation discussion into sections: NAME SERVER TRANSACTIONS, which discusses the formats for name servers queries and the corresponding responses. NAME SERVER MAINTENANCE, which discusses strategies, algorithms, and formats for maintaining the data residing in name servers. These services periodically refresh the local copies of zones that originate in other hosts. RESOLVER ALGORITHMS, which discusses the internal structure of resolvers. This section also discusses data base sharing between a name server and a resolver on the same host. DOMAIN SUPPORT FOR MAIL, which discusses the use of the domain system to support mail transfer. Mockapetris [Page 5] RFC 883 November 1983 Domain Names - Implementation and Specification Conventions The domain system has several conventions dealing with low-level, but fundamental, issues. While the implementer is free to violate these conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in ALL behavior observed from other hosts. ********** Data Transmission Order ********** The order of transmission of the header and data described in this document is resolved to the octet level. Whenever a diagram shows a group of octets, the order of transmission of those octets is the normal order in which they are read in English. For example, in the following diagram the octets are transmitted in the order they are numbered. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Transmission Order of Bytes Whenever an octet represents a numeric quantity the left most bit in the diagram is the high order or most significant bit. That is, the bit labeled 0 is the most significant bit. For example, the following diagram represents the value 170 (decimal). 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1 0 1 0 1 0 1 0| +-+-+-+-+-+-+-+-+ Significance of Bits Similarly, whenever a multi-octet field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted the most significant octet is transmitted first. Mockapetris [Page 6] RFC 883 November 1983 Domain Names - Implementation and Specification ********** Character Case ********** All comparisons between character strings (e.g. labels, domain names, etc.) are done in a case-insensitive manner. When data enters the domain system, its original case should be preserved whenever possible. In certain circumstances this cannot be done. For example, if two domain names x.y and X.Y are entered into the domain database, they are interpreted as the same name, and hence may have a single representation. The basic rule is that case can be discarded only when data is used to define structure in a database, and two names are identical when compared in a case insensitive manner. Loss of case sensitive data must be minimized. Thus while data for x.y and X.Y may both be stored under x.y, data for a.x and B.X can be stored as a.x and B.x, but not A.x, A.X, b.x, or b.X. In general, this prevents the first component of a domain name from loss of case information. Systems administrators who enter data into the domain database should take care to represent the data they supply to the domain system in a case-consistent manner if their system is case-sensitive. The data distribution system in the domain system will ensure that consistent representations are preserved. Mockapetris [Page 7] RFC 883 November 1983 Domain Names - Implementation and Specification Design philosophy The design presented in this memo attempts to provide a base which will be suitable for several existing networks. An equally important goal is to provide these services within a framework that is capable of adjustment to fit the evolution of services in early clients as well as to accommodate new networks. Since it is impossible to predict the course of these developments, the domain system attempts to provide for evolution in the form of an extensible framework. This section describes the areas in which we expect to see immediate evolution. DEFINING THE DATABASE This memo defines methods for partitioning the database and data for host names, host addresses, gateway information, and mail support. Experience with this system will provide guidance for future additions. While the present system allows for many new RR types, classes, etc., we feel that it is more important to get the basic services in operation than to cover an exhaustive set of information. Hence we have limited the data types to those we felt were essential, and would caution designers to avoid implementations which are based on the number of existing types and classes. Extensibility in this area is very important. While the domain system provides techniques for partitioning the database, policies for administrating the orderly connection of separate domains and guidelines for constructing the data that makes up a particular domain will be equally important to the success of the system. Unfortunately, we feel that experience with prototype systems will be necessary before this question can be properly addressed. Thus while this memo has minimal discussion of these issues, it is a critical area for development. TYING TOGETHER INTERNETS Although it is very difficult to characterize the types of networks, protocols, and applications that will be clients of the domain system, it is very obvious that some of these applications will cross the boundaries of network and protocol. At the very least, mail is such a service. Attempts to unify two such systems must deal with two major problems: 1. Differing formats for environment sensitive data. For example, Mockapetris [Page 8] RFC 883 November 1983 Domain Names - Implementation and Specification network addresses vary in format, and it is unreasonable to expect to enforce consistent conventions. 2. Connectivity may require intermediaries. For example, it is a frequent occurence that mail is sent between hosts that share no common protocol. The domain system acknowledges that these are very difficult problems, and attempts to deal with both problems through its CLASS mechanism: 1. The CLASS field in RRs allows data to be tagged so that all programs in the domain system can identify the format in use. 2. The CLASS field allows the requestor to identify the format of data which can be understood by the requestor. 3. The CLASS field guides the search for the requested data. The last point is central to our approach. When a query crosses protocol boundaries, it must be guided though agents capable of performing whatever translation is required. For example, when a mailer wants to identify the location of a mailbox in a portion of the domain system that doesn't have a compatible protocol, the query must be guided to a name server that can cross the boundary itself or form one link in a chain that can span the differences. If query and response transport were the only problem, then this sort of problem could be dealt with in the name servers themselves. However, the applications that will use domain service have similar problems. For example, mail may need to be directed through mail gateways, and the characteristics of one of the environments may not permit frequent connectivity between name servers in all environments. These problems suggest that connectivity will be achieved through a variety of measures: Translation name servers that act as relays between different protocols. Translation application servers that translate application level transactions. Default database entries that route traffic through application level forwarders in ways that depend on the class of the requestor. While this approach seems best given our current understanding of Mockapetris [Page 9] RFC 883 November 1983 Domain Names - Implementation and Specification the problem, we realize that the approach of using resource data that transcends class may be appropriate in future designs or applications. By not defining class to be directly related to protocol, network, etc., we feel that such services could be added by defining a new "universal" class, while the present use of class will provide immediate service. This problem requires more thought and experience before solutions can be discovered. The concepts of CLASS, recursive servers and other mechanisms are intended as tools for acquiring experience and not as final solutions. Mockapetris [Page 10] RFC 883 November 1983 Domain Names - Implementation and Specification NAME SERVER TRANSACTIONS Introduction The primary purpose of name servers is to receive queries from resolvers and return responses. The overall model of this service is that a program (typically a resolver) asks the name server questions (queries) and gets responses that either answer the question or refer the questioner to another name server. Other functions related to name server database maintenance use similar procedures and formats and are discussed in a section later in this memo. There are three kinds of queries presently defined: 1. Standard queries that ask for a specified resource attached to a given domain name. 2. Inverse queries that specify a resource and ask for a domain name that possesses that resource. 3. Completion queries that specify a partial domain name and a target domain and ask that the partial domain name be completed with a domain name close to the target domain. This memo uses an unqualified reference to queries to refer to either all queries or standard queries when the context is clear. Query and response transport Name servers and resolvers use a single message format for all communications. The message format consists of a variable-length octet string which includes binary values. The messages used in the domain system are designed so that they can be carried using either datagrams or virtual circuits. To accommodate the datagram style, all responses carry the query as part of the response. While the specification allows datagrams to be used in any context, some activities are ill suited to datagram use. For example, maintenance transactions and recursive queries typically require the error control of virtual circuits. Thus datagram use should be restricted to simple queries. The domain system assumes that a datagram service provides: 1. A non-reliable (i.e. best effort) method of transporting a message of up to 512 octets. Mockapetris [Page 11] RFC 883 November 1983 Domain Names - Implementation and Specification Hence datagram messages are limited to 512 octets. If a datagram message would exceed 512 octets, it is truncated and a truncation flag is set in its header. 2. A message size that gives the number of octets in the datagram. The main implications for programs accessing name servers via datagrams are: 1. Datagrams should not be used for maintenance transactions and recursive queries. 2. Since datagrams may be lost, the originator of a query must perform error recovery (such as retransmissions) as appropriate. 3. Since network or host delay may cause retransmission when a datagram has not been lost, the originator of a query must be ready to deal with duplicate responses. The domain system assumes that a virtual circuit service provides: 1. A reliable method of transmitting a message of up to 65535 octets. 2. A message size that gives the number of octets in the message. If the virtual circuit service does not provide for message boundary detection or limits transmission size to less than 65535 octets, then messages are prefaced with an unsigned 16 bit length field and broken up into separate transmissions as required. The length field is only prefaced on the first message. This technique is used for TCP virtual circuits. 3. Multiple messages may be sent over a virtual circuit. 4. A method for closing a virtual circuit. 5. A method for detecting that the other party has requested that the virtual circuit be closed. The main implications for programs accessing name servers via virtual circuits are: 1. Either end of a virtual circuit may initiate a close when there is no activity in progress. The other end should comply. Mockapetris [Page 12] RFC 883 November 1983 Domain Names - Implementation and Specification The decision to initiate a close is a matter of individual site policy; some name servers may leave a virtual circuit open for an indeterminate period following a query to allow for subsequent queries; other name servers may choose to initiate a close following the completion of the first query on a virtual circuit. Of course, name servers should not close the virtual circuit in the midst of a multiple message stream used for zone transfer. 2. Since network delay may cause one end to erroneously believe that no activity is in progress, a program which receives a virtual circuit close while a query is in progress should close the virtual circuit and resubmit the query on a new virtual circuit. All messages may use a compression scheme to reduce the space consumed by repetitive domain names. The use of the compression scheme is optional for the sender of a message, but all receivers must be capable of decoding compressed domain names. Overall message format All messages sent by the domain system are divided into 5 sections (some of which are empty in certain cases) shown below: +---------------------+ | Header | +---------------------+ | Question | the question for the name server +---------------------+ | Answer | answering resource records (RRs) +---------------------+ | Authority | RRs pointing toward an authority +---------------------+ | Additional | RRs holding pertinent information +---------------------+ The header section is always present. The header includes fields that specify which of the remaining sections are present, and also specify whether the message is a query, inverse query, completion query, or response. The question section contains fields that describe a question to a name server. These fields are a query type (QTYPE), a query class (QCLASS), and a query domain name (QNAME). The last three sections have the same format: a possibly empty list of concatenated resource records (RRs). The answer section contains RRs that answer the question; the authority section Mockapetris [Page 13] RFC 883 November 1983 Domain Names - Implementation and Specification contains RRs that point toward an authoritative name server; the additional records section contains RRs which relate to the query, but are not strictly answers for the question. The next two sections of this memo illustrate the use of these message sections through examples; a detailed discussion of data formats follows the examples. Mockapetris [Page 14] RFC 883 November 1983 Domain Names - Implementation and Specification The contents of standard queries and responses When a name server processes a standard query, it first determines whether it is an authority for the domain name specified in the query. If the name server is an authority, it returns either: 1. the specified resource information 2. an indication that the specified name does not exist 3. an indication that the requested resource information does not exist If the name server is not an authority for the specified name, it returns whatever relevant resource information it has along with resource records that the requesting resolver can use to locate an authoritative name server. Standard query and response example The overall structure of a query for retrieving information for Internet mail for domain F.ISI.ARPA is shown below: +-----------------------------------------+ Header | OPCODE=QUERY, ID=2304 | +-----------------------------------------+ Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA | +-----------------------------------------+ Answer | | +-----------------------------------------+ Authority | | +-----------------------------------------+ Additional | | +-----------------------------------------+ The header includes an opcode field that specifies that this datagram is a query, and an ID field that will be used to associate replies with the original query. (Some additional header fields have been omitted for clarity.) The question section specifies that the type of the query is for mail agent information, that only ARPA Internet information is to be considered, and that the domain name of interest is F.ISI.ARPA. The remaining sections are empty, and would not use any octets in a real query. Mockapetris [Page 15] RFC 883 November 1983 Domain Names - Implementation and Specification One possible response to this query might be: +-----------------------------------------+ Header | OPCODE=RESPONSE, ID=2304 | +-----------------------------------------+ Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA | +-----------------------------------------+ Answer | | +-----------------------------------------+ Authority | ARPA NS IN A.ISI.ARPA | | ------- | | ARPA NS IN F.ISI.ARPA | +-----------------------------------------+ Additional | F.ISI.ARPA A IN 10.2.0.52 | | ------- | | A.ISI.ARPA A IN 10.1.0.22 | +-----------------------------------------+ This type of response would be returned by a name server that was not an authority for the domain name F.ISI.ARPA. The header field specifies that the datagram is a response to a query with an ID of 2304. The question section is copied from the question section in the query datagram. The answer section is empty because the name server did not have any information that would answer the query. (Name servers may happen to have cached information even if they are not authoritative for the query.) The best that this name server could do was to pass back information for the domain ARPA. The authority section specifies two name servers for the domain ARPA using the Internet family: A.ISI.ARPA and F.ISI.ARPA. Note that it is merely a coincidence that F.ISI.ARPA is a name server for ARPA as well as the subject of the query. In this case, the name server included in the additional records section the Internet addresses for the two hosts specified in the authority section. Such additional data is almost always available. Given this response, the process that originally sent the query might resend the query to the name server on A.ISI.ARPA, with a new ID of 2305. Mockapetris [Page 16] RFC 883 November 1983 Domain Names - Implementation and Specification The name server on A.ISI.ARPA might return a response: +-----------------------------------------+ Header | OPCODE=RESPONSE, ID=2305 | +-----------------------------------------+ Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA | +-----------------------------------------+ Answer | F.ISI.ARPA MD IN F.ISI.ARPA | | ------- | | F.ISI.ARPA MF IN A.ISI.ARPA | +-----------------------------------------+ Authority | | +-----------------------------------------+ Additional | F.ISI.ARPA A IN 10.2.0.52 | | ------- | | A.ISI.ARPA A IN 10.1.0.22 | +-----------------------------------------+ This query was directed to an authoritative name server, and hence the response includes an answer but no authority records. In this case, the answer section specifies that mail for F.ISI.ARPA can either be delivered to F.ISI.ARPA or forwarded to A.ISI.ARPA. The additional records section specifies the Internet addresses of these hosts. The contents of inverse queries and responses Inverse queries reverse the mappings performed by standard query operations; while a standard query maps a domain name to a resource, an inverse query maps a resource to a domain name. For example, a standard query might bind a domain name to a host address; the corresponding inverse query binds the host address to a domain name. Inverse query mappings are not guaranteed to be unique or complete because the domain system does not have any internal mechanism for determining authority from resource records that parallels the capability for determining authority as a function of domain name. In general, resolvers will be configured to direct inverse queries to a name server which is known to have the desired information. Name servers are not required to support any form of inverse queries; it is anticipated that most name servers will support address to domain name conversions, but no other inverse mappings. If a name server receives an inverse query that it does not support, it returns an error response with the "Not Implemented" error set in the header. While inverse query support is optional, all name servers must be at least able to return the error response. Mockapetris [Page 17] RFC 883 November 1983 Domain Names - Implementation and Specification When a name server processes an inverse query, it either returns: 1. zero, one, or multiple domain names for the specified resource 2. an error code indicating that the name server doesn't support inverse mapping of the specified resource type. Inverse query and response example The overall structure of an inverse query for retrieving the domain name that corresponds to Internet address 10.2.0.52 is shown below: +-----------------------------------------+ Header | OPCODE=IQUERY, ID=997 | +-----------------------------------------+ Question | | +-----------------------------------------+ Answer | A IN 10.2.0.52 | +-----------------------------------------+ Authority | | +-----------------------------------------+ Additional | | +-----------------------------------------+ This query asks for a question whose answer is the Internet style address 10.2.0.52. Since the owner name is not known, any domain name can be used as a placeholder (and is ignored). The response to this query might be: +-----------------------------------------+ Header | OPCODE=RESPONSE, ID=997 | +-----------------------------------------+ Question | QTYPE=A, QCLASS=IN, QNAME=F.ISI.ARPA | +-----------------------------------------+ Answer | F.ISI.ARPA A IN 10.2.0.52 | +-----------------------------------------+ Authority | | +-----------------------------------------+ Additional | | +-----------------------------------------+ Note that the QTYPE in a response to an inverse query is the same as the TYPE field in the answer section of the inverse query. Responses to inverse queries may contain multiple questions when the inverse is not unique. Mockapetris [Page 18] RFC 883 November 1983 Domain Names - Implementation and Specification Completion queries and responses Completion queries ask a name server to complete a partial domain name and return a set of RRs whose domain names meet a specified set of criteria for "closeness" to the partial input. This type of query can provide a local shorthand for domain names or command completion similar to that in TOPS-20. Implementation of completion query processing is optional in a name server. However, a name server must return a "Not Implemented" (NI) error response if it does not support completion. The arguments in a completion query specify: 1. A type in QTYPE that specifies the type of the desired name. The type is used to restrict the type of RRs which will match the partial input so that completion queries can be used for mailbox names, host names, or any other type of RR in the domain system without concern for matches to the wrong type of resource. 2. A class in QCLASS which specifies the desired class of the RR. 3. A partial domain name that gives the input to be completed. All returned RRs will begin with the partial string. The search process first looks for names which qualify under the assumption that the partial string ends with a full label ("whole label match"); if this search fails, the search continues under the assumption that the last label in the partial sting may be an incomplete label ("partial label match"). For example, if the partial string "Smith" was used in a mailbox completion, it would match Smith@ISI.ARPA in preference to Smithsonian@ISI.ARPA. The partial name is supplied by the user through the user program that is using domain services. For example, if the user program is a mail handler, the string might be "Mockap" which the user intends as a shorthand for the mailbox Mockapetris@ISI.ARPA; if the user program is TELNET, the user might specify "F" for F.ISI.ARPA. In order to make parsing of messages consistent, the partial name is supplied in domain name format (i.e. a sequence of labels terminated with a zero length octet). However, the trailing root label is ignored during matching. 4. A target domain name which specifies the domain which is to be examined for matches. This name is specified in the additional Mockapetris [Page 19] RFC 883 November 1983 Domain Names - Implementation and Specification section using a NULL RR. All returned names will end with the target name. The user program which constructs the query uses the target name to restrict the search. For example, user programs running at ISI might restrict completion to names that end in ISI.ARPA; user programs running at MIT might restrict completion to the domain MIT.ARPA. The target domain name is also used by the resolver to determine the name server which should be used to process the query. In general, queries should be directed to a name server that is authoritative for the target domain name. User programs which wish to provide completion for a more than one target can issue multiple completion queries, each directed at a different target. Selection of the target name and the number of searches will depend on the goals of the user program. 5. An opcode for the query. The two types of completion queries are "Completion Query - Multiple", or CQUERYM, which asks for all RRs which could complete the specified input, and "Completion Query - Unique", or CQUERYU, which asks for the "best" completion. CQUERYM is used by user programs which want to know if ambiguities exist or wants to do its own determinations as to the best choice of the available candidates. CQUERYU is used by user programs which either do not wish to deal with multiple choices or are willing to use the closeness criteria used by CQUERYU to select the best match. When a name server receives either completion query, it first looks for RRs that begin (on the left) with the same labels as are found in QNAME (with the root deleted), and which match the QTYPE and QCLASS. This search is called "whole label" matching. If one or more hits are found the name server either returns all of the hits (CQUERYM) or uses the closeness criteria described below to eliminate all but one of the matches (CQUERYU). If the whole label match fails to find any candidates, then the name server assumes that the rightmost label of QNAME (after root deletion) is not a complete label, and looks for candidates that would match if characters were added (on the right) to the rightmost label of QNAME. If one or more hits are found the name server either returns all of the hits (CQUERYM) or uses the closeness criteria described below to eliminate all but one of the matches (CQUERYU). Mockapetris [Page 20] RFC 883 November 1983 Domain Names - Implementation and Specification If a CQUERYU query encounters multiple hits, it uses the following sequence of rules to discard multiple hits: 1. Discard candidates that have more labels than others. Since all candidates start with the partial name and end with the target name, this means that we select those entries that require the fewest number of added labels. For example, a host search with a target of "ISI.ARPA" and a partial name of "A" will select A.ISI.ARPA in preference to A.IBM-PCS.ISI.ARPA. 2. If partial label matching was used, discard those labels which required more characters to be added. For example, a mailbox search for partial "X" and target "ISI.ARPA" would prefer XX@ISI.ARPA to XYZZY@ISI.ARPA. If multiple hits are still present, return all hits. Completion query mappings are not guaranteed to be unique or complete because the domain system does not have any internal mechanism for determining authority from a partial domain name that parallels the capability for determining authority as a function of a complete domain name. In general, resolvers will be configured to direct completion queries to a name server which is known to have the desired information. When a name server processes a completion query, it either returns: 1. An answer giving zero, one, or more possible completions. 2. an error response with Not Implemented (NI) set. Mockapetris [Page 21] RFC 883 November 1983 Domain Names - Implementation and Specification Completion query and response example Suppose that the completion service was used by a TELNET program to allow a user to specify a partial domain name for the desired host. Thus a user might ask to be connected to "B". Assuming that the query originated from an ISI machine, the query might look like: +-----------------------------------------+ Header | OPCODE=CQUERYU, ID=409 | +-----------------------------------------+ Question | QTYPE=A, QCLASS=IN, QNAME=B | +-----------------------------------------+ Answer | | +-----------------------------------------+ Authority | | +-----------------------------------------+ Additional | ISI.ARPA NULL IN | +-----------------------------------------+ The partial name in the query is "B", the mappings of interest are ARPA Internet address records, and the target domain is ISI.ARPA. Note that NULL is a special type of NULL resource record that is used as a placeholder and has no significance; NULL RRs obey the standard format but have no other function. The response to this completion query might be: +-----------------------------------------+ Header | OPCODE=RESPONSE, ID=409 | +-----------------------------------------+ Question | QTYPE=A, QCLASS=IN, QNAME=B | +-----------------------------------------+ Answer | B.ISI.ARPA A IN 10.3.0.52 | +-----------------------------------------+ Authority | | +-----------------------------------------+ Additional | ISI.ARPA NULL IN | +-----------------------------------------+ This response has completed B to mean B.ISI.ARPA. Mockapetris [Page 22] RFC 883 November 1983 Domain Names - Implementation and Specification Another query might be: +-----------------------------------------+ Header | OPCODE=CQUERYM, ID=410 | +-----------------------------------------+ Question | QTYPE=A, QCLASS=IN, QNAME=B | +-----------------------------------------+ Answer | | +-----------------------------------------+ Authority | | +-----------------------------------------+ Additional | ARPA NULL IN | +-----------------------------------------+ This query is similar to the previous one, but specifies a target of ARPA rather than ISI.ARPA. It also allows multiple matches. In this case the same name server might return: +-----------------------------------------+ Header | OPCODE=RESPONSE, ID=410 | +-----------------------------------------+ Question | QTYPE=A, QCLASS=IN, QNAME=B | +-----------------------------------------+ Answer | B.ISI.ARPA A IN 10.3.0.52 | | - | | B.BBN.ARPA A IN 10.0.0.49 | | - | | B.BBNCC.ARPA A IN 8.1.0.2 | +-----------------------------------------+ Authority | | +-----------------------------------------+ Additional | ARPA NULL IN | +-----------------------------------------+ This response contains three answers, B.ISI.ARPA, B.BBN.ARPA, and B.BBNCC.ARPA. Mockapetris [Page 23] RFC 883 November 1983 Domain Names - Implementation and Specification Recursive Name Service Recursive service is an optional feature of name servers. When a name server receives a query regarding a part of the name space which is not in one of the name server's zones, the standard response is a message that refers the requestor to another name server. By iterating on these referrals, the requestor eventually is directed to a name server that has the required information. Name servers may also implement recursive service. In this type of service, a name server either answers immediately based on local zone information, or pursues the query for the requestor and returns the eventual result back to the original requestor. A name server that supports recursive service sets the Recursion Available (RA) bit in all responses it generates. A requestor asks for recursive service by setting the Recursion Desired (RD) bit in queries. In some situations where recursive service is the only path to the desired information (see below), the name server may go recursive even if RD is zero. If a query requests recursion (RD set), but the name server does not support recursion, and the query needs recursive service for an answer, the name server returns a "Not Implemented" (NI) error code. If the query can be answered without recursion since the name server is authoritative for the query, it ignores the RD bit. Because of the difficulty in selecting appropriate timeouts and error handling, recursive service is best suited to virtual circuits, although it is allowed for datagrams. Recursive service is valuable in several special situations: In a system of small personal computers clustered around one or more large hosts supporting name servers, the recursive approach minimizes the amount of code in the resolvers in the personal computers. Such a design moves complexity out of the resolver into the name server, and may be appropriate for such systems. Name servers on the boundaries of different networks may wish to offer recursive service to create connectivity between different networks. Such name servers may wish to provide recursive service regardless of the setting of RD. Name servers that translate between domain name service and some other name service may wish to adopt the recursive style. Implicit recursion may be valuable here as well. Mockapetris [Page 24] RFC 883 November 1983 Domain Names - Implementation and Specification These concepts are still under development. Mockapetris [Page 25] RFC 883 November 1983 Domain Names - Implementation and Specification Header section format +-----------------------------------------------+ | | | ***** WARNING ***** | | | | The following format is preliminary and is | | included for purposes of explanation only. In | | particular, the size and position of the | | OPCODE, RCODE fields and the number and | | meaning of the single bit fields are subject | | to change. | | | +-----------------------------------------------+ The header contains the following fields: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ID - A 16 bit identifier assigned by the program that generates any kind of query. This identifier is copied into all replies and can be used by the requestor to relate replies to outstanding questions. QR - A one bit field that specifies whether this message is a query (0), or a resp