RFC 0883
Domain names: Implementation specification
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. | | | +-----------------------------------------------+
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
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.
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.
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.
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.
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.
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.
********** 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.
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,
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
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.
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.
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.
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
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.
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 | <empty> |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | <empty> |
+-----------------------------------------+
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.
One possible response to this query might be:
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=2304 |
+-----------------------------------------+
Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA |
+-----------------------------------------+
Answer | <empty> |
+-----------------------------------------+
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.
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 | <empty> |
+-----------------------------------------+
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.
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 | <empty> |
+-----------------------------------------+
Answer | <anyname> A IN 10.2.0.52 |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | <empty> |
+-----------------------------------------+
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 | <empty> |
+-----------------------------------------+
Additional | <empty> |
+-----------------------------------------+
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.
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
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).
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.
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 | <empty> |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
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 | <empty> |
+-----------------------------------------+
Additional | ISI.ARPA NULL IN |
+-----------------------------------------+
This response has completed B to mean B.ISI.ARPA.
(next page on part 2)
