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.



 

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