Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 0883

Domain names: Implementation specification

Pages: 74
Obsoleted by:  10341035
Updated by:  0973
Part 1 of 3 – Pages 1 to 24
None   None   Next

ToP   noToC   RFC0883 - Page 1
Network Working Group                                     P. Mockapetris
Request for Comments:  883                                           ISI
                                                           November 1983

        |                                                     |
        | 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.  |
           |                                               |
ToP   noToC   RFC0883 - Page 2
      Implementation components........................................2
      Design philosophy................................................8
   NAME SERVER TRANSACTIONS...........................................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
      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
   DOMAIN SUPPORT FOR MAIL............................................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
ToP   noToC   RFC0883 - Page 3


      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

      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.
ToP   noToC   RFC0883 - Page 4
   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.
ToP   noToC   RFC0883 - Page 5
      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.
ToP   noToC   RFC0883 - Page 6
      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.
ToP   noToC   RFC0883 - Page 7
      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.
ToP   noToC   RFC0883 - Page 8

      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.
ToP   noToC   RFC0883 - Page 9
                  ********** 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.
ToP   noToC   RFC0883 - Page 10
   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.


      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.


      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

      1. Differing formats for environment sensitive data.  For example,
ToP   noToC   RFC0883 - Page 11
         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

         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

      While this approach seems best given our current understanding of
ToP   noToC   RFC0883 - Page 12
      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.
ToP   noToC   RFC0883 - Page 13


      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.
ToP   noToC   RFC0883 - Page 14
            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

      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

         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

         2. A message size that gives the number of octets in the

            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
ToP   noToC   RFC0883 - Page 15
            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
ToP   noToC   RFC0883 - Page 16
      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.
ToP   noToC   RFC0883 - Page 17
   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

      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.
ToP   noToC   RFC0883 - Page 18
      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        |
                          |                 -------                 |
                          |        A.ISI.ARPA A IN        |

      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

      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.
ToP   noToC   RFC0883 - Page 19
      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        |
                          |                 -------                 |
                          |        A.ISI.ARPA A IN        |

      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
ToP   noToC   RFC0883 - Page 20
      When a name server processes an inverse query, it either returns:

         1. zero, one, or multiple domain names for the specified

         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 is
      shown below:

            Header        |          OPCODE=IQUERY, ID=997          |
           Question       |                 <empty>                 |
            Answer        |        <anyname> A IN         |
           Authority      |                 <empty>                 |
          Additional      |                 <empty>                 |

      This query asks for a question whose answer is the Internet style
      address  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         |
           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.
ToP   noToC   RFC0883 - Page 21
   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

      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

      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
ToP   noToC   RFC0883 - Page 22
         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

      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).
ToP   noToC   RFC0883 - Page 23
      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

      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

         1. An answer giving zero, one, or more possible completions.

         2. an error response with Not Implemented (NI) set.
ToP   noToC   RFC0883 - Page 24
   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        |
           Authority      |                 <empty>                 |
          Additional      |             ISI.ARPA NULL IN            |

      This response has completed B to mean B.ISI.ARPA.

(next page on part 2)

Next Section