rfc883.txt

RFC 相关的技术文档

      protocol, network, etc., we feel that such services could be added
      by defining a new "universal" class, while the present use of
      class will provide immediate service.

      This problem requires more thought and experience before solutions
      can be discovered.  The concepts of CLASS, recursive servers and
      other mechanisms are intended as tools for acquiring experience
      and not as final solutions.








































Mockapetris                                                    [Page 10]


RFC 883                                                    November 1983
                         Domain Names - Implementation and Specification


NAME SERVER TRANSACTIONS

   Introduction

      The primary purpose of name servers is to receive queries from
      resolvers and return responses.  The overall model of this service
      is that a program (typically a resolver) asks the name server
      questions (queries) and gets responses that either answer the
      question or refer the questioner to another name server.  Other
      functions related to name server database maintenance use similar
      procedures and formats and are discussed in a section later in
      this memo.

      There are three kinds of queries presently defined:

         1. Standard queries that ask for a specified resource attached
            to a given domain name.

         2. Inverse queries that specify a resource and ask for a domain
            name that possesses that resource.

         3. Completion queries that specify a partial domain name and a
            target domain and ask that the partial domain name be
            completed with a domain name close to the target domain.

      This memo uses an unqualified reference to queries to refer to
      either all queries or standard queries when the context is clear.

   Query and response transport

      Name servers and resolvers use a single message format for all
      communications.  The message format consists of a variable-length
      octet string which includes binary values.

      The messages used in the domain system are designed so that they
      can be carried using either datagrams or virtual circuits.  To
      accommodate the datagram style, all responses carry the query as
      part of the response.

      While the specification allows datagrams to be used in any
      context, some activities are ill suited to datagram use.  For
      example, maintenance transactions and recursive queries typically
      require the error control of virtual circuits.  Thus datagram use
      should be restricted to simple queries.

      The domain system assumes that a datagram service provides:

         1. A non-reliable (i.e. best effort) method of transporting a
            message of up to 512 octets.


Mockapetris                                                    [Page 11]


RFC 883                                                    November 1983
                         Domain Names - Implementation and Specification


            Hence datagram messages are limited to 512 octets.  If a
            datagram message would exceed 512 octets, it is truncated
            and a truncation flag is set in its header.

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

      The main implications for programs accessing name servers via
      datagrams are:

         1. Datagrams should not be used for maintenance transactions
            and recursive queries.

         2. Since datagrams may be lost, the originator of a query must
            perform error recovery (such as retransmissions) as
            appropriate.

         3. Since network or host delay may cause retransmission when a
            datagram has not been lost, the originator of a query must
            be ready to deal with duplicate responses.

      The domain system assumes that a virtual circuit service provides:

         1. A reliable method of transmitting a message of up to 65535
            octets.

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

            If the virtual circuit service does not provide for message
            boundary detection or limits transmission size to less than
            65535 octets, then messages are prefaced with an unsigned 16
            bit length field and broken up into separate transmissions
            as required.  The length field is only prefaced on the first
            message.  This technique is used for TCP virtual circuits.

         3. Multiple messages may be sent over a virtual circuit.

         4. A method for closing a virtual circuit.

         5. A method for detecting that the other party has requested
            that the virtual circuit be closed.

      The main implications for programs accessing name servers via
      virtual circuits are:

         1. Either end of a virtual circuit may initiate a close when
            there is no activity in progress.  The other end should
            comply.


Mockapetris                                                    [Page 12]


RFC 883                                                    November 1983
                         Domain Names - Implementation and Specification


            The decision to initiate a close is a matter of individual
            site policy; some name servers may leave a virtual circuit
            open for an indeterminate period following a query to allow
            for subsequent queries; other name servers may choose to
            initiate a close following the completion of the first query
            on a virtual circuit.  Of course, name servers should not
            close the virtual circuit in the midst of a multiple message
            stream used for zone transfer.

         2. Since network delay may cause one end to erroneously believe
            that no activity is in progress, a program which receives a
            virtual circuit close while a query is in progress should
            close the virtual circuit and resubmit the query on a new
            virtual circuit.

      All messages may use a compression scheme to reduce the space
      consumed by repetitive domain names.  The use of the compression
      scheme is optional for the sender of a message, but all receivers
      must be capable of decoding compressed domain names.

   Overall message format

      All messages sent by the domain system are divided into 5 sections
      (some of which are empty in certain cases) shown below:

       +---------------------+                                   
       |        Header       |                                   
       +---------------------+                                   
       |       Question      | the question for the name server  
       +---------------------+                                   
       |        Answer       | answering resource records (RRs)  
       +---------------------+                                   
       |      Authority      | RRs pointing toward an authority  
       +---------------------+                                   
       |      Additional     | RRs holding pertinent information 
       +---------------------+                                   

      The header section is always present.  The header includes fields
      that specify which of the remaining sections are present, and also
      specify whether the message is a query, inverse query, completion
      query, or response.

      The question section contains fields that describe a question to a
      name server.  These fields are a query type (QTYPE), a query class
      (QCLASS), and a query domain name (QNAME).

      The last three sections have the same format: a possibly empty
      list of concatenated resource records (RRs).  The answer section
      contains RRs that answer the question; the authority section


Mockapetris                                                    [Page 13]


RFC 883                                                    November 1983
                         Domain Names - Implementation and Specification


      contains RRs that point toward an authoritative name server; the
      additional records section contains RRs which relate to the query,
      but are not strictly answers for the question.

      The next two sections of this memo illustrate the use of these
      message sections through examples; a detailed discussion of data
      formats follows the examples.












































Mockapetris                                                    [Page 14]


RFC 883                                                    November 1983
                         Domain Names - Implementation and Specification


   The contents of standard queries and responses

      When a name server processes a standard query, it first determines
      whether it is an authority for the domain name specified in the
      query.

      If the name server is an authority, it returns either:

         1. the specified resource information

         2. an indication that the specified name does not exist

         3. an indication that the requested resource information does
            not exist

      If the name server is not an authority for the specified name, it
      returns whatever relevant resource information it has along with
      resource records that the requesting resolver can use to locate an
      authoritative name server.

   Standard query and response example

      The overall structure of a query for retrieving information for
      Internet mail for domain F.ISI.ARPA is shown below:

                          +-----------------------------------------+
            Header        |          OPCODE=QUERY, ID=2304          |
                          +-----------------------------------------+
           Question       |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA |
                          +-----------------------------------------+
            Answer        |                 <empty>                 |
                          +-----------------------------------------+
           Authority      |                 <empty>                 |
                          +-----------------------------------------+
          Additional      |                 <empty>                 |
                          +-----------------------------------------+