rfc883.txt

RFC 相关的技术文档

      The header includes an opcode field that specifies that this
      datagram is a query, and an ID field that will be used to
      associate replies with the original query.  (Some additional
      header fields have been omitted for clarity.)  The question
      section specifies that the type of the query is for mail agent
      information, that only ARPA Internet information is to be
      considered, and that the domain name of interest is F.ISI.ARPA.
      The remaining sections are empty, and would not use any octets in
      a real query.





Mockapetris                                                    [Page 15]


RFC 883                                                    November 1983
                         Domain Names - Implementation and Specification


      One possible response to this query might be:

                          +-----------------------------------------+
            Header        |        OPCODE=RESPONSE, ID=2304         |
                          +-----------------------------------------+
           Question       |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA |
                          +-----------------------------------------+
            Answer        |                 <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.







Mockapetris                                                    [Page 16]


RFC 883                                                    November 1983
                         Domain Names - Implementation and Specification


      The name server on A.ISI.ARPA might return a response:

                          +-----------------------------------------+
            Header        |        OPCODE=RESPONSE, ID=2305         |
                          +-----------------------------------------+
           Question       |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA |
                          +-----------------------------------------+
            Answer        |       F.ISI.ARPA MD IN F.ISI.ARPA       |
                          |                 -------                 |
                          |       F.ISI.ARPA MF IN A.ISI.ARPA       |
                          +-----------------------------------------+
           Authority      |                 <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.


Mockapetris                                                    [Page 17]


RFC 883                                                    November 1983
                         Domain Names - Implementation and Specification


      When a name server processes an inverse query, it either returns:

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

         2. an error code indicating that the name server doesn't
            support inverse mapping of the specified resource type.

   Inverse query and response example

      The overall structure of an inverse query for retrieving the
      domain name that corresponds to Internet address 10.2.0.52 is
      shown below:

                          +-----------------------------------------+
            Header        |          OPCODE=IQUERY, ID=997          |
                          +-----------------------------------------+
           Question       |                 <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.




Mockapetris                                                    [Page 18]


RFC 883                                                    November 1983
                         Domain Names - Implementation and Specification


   Completion queries and responses

      Completion queries ask a name server to complete a partial domain
      name and return a set of RRs whose domain names meet a specified
      set of criteria for "closeness" to the partial input.  This type
      of query can provide a local shorthand for domain names or command
      completion similar to that in TOPS-20.

      Implementation of completion query processing is optional in a
      name server.  However, a name server must return a "Not
      Implemented" (NI) error response if it does not support
      completion.

      The arguments in a completion query specify:

      1. A type in QTYPE that specifies the type of the desired name.
         The type is used to restrict the type of RRs which will match
         the partial input so that completion queries can be used for
         mailbox names, host names, or any other type of RR in the
         domain system without concern for matches to the wrong type of
         resource.

      2. A class in QCLASS which specifies the desired class of the RR.

      3. A partial domain name that gives the input to be completed.
         All returned RRs will begin with the partial string.  The
         search process first looks for names which qualify under the
         assumption that the partial string ends with a full label
         ("whole label match"); if this search fails, the search
         continues under the assumption that the last label in the
         partial sting may be an incomplete label ("partial label
         match").  For example, if the partial string "Smith" was used
         in a mailbox completion, it would match [e-mail] in
         preference to [e-mail].

         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
         [e-mail]; if the user program is TELNET, the user
         might specify "F" for F.ISI.ARPA.

         In order to make parsing of messages consistent, the partial
         name is supplied in domain name format (i.e. a sequence of
         labels terminated with a zero length octet).  However, the
         trailing root label is ignored during matching.

      4. A target domain name which specifies the domain which is to be
         examined for matches.  This name is specified in the additional


Mockapetris                                                    [Page 19]


RFC 883                                                    November 1983
                         Domain Names - Implementation and Specification


         section using a NULL RR.  All returned names will end with the
         target name.

         The user program which constructs the query uses the target
         name to restrict the search.  For example, user programs
         running at ISI might restrict completion to names that end in
         ISI.ARPA; user programs running at MIT might restrict
         completion to the domain MIT.ARPA.

         The target domain name is also used by the resolver to
         determine the name server which should be used to process the
         query.  In general, queries should be directed to a name server
         that is authoritative for the target domain name.  User
         programs which wish to provide completion for a more than one
         target can issue multiple completion queries, each directed at
         a different target.  Selection of the target name and the
         number of searches will depend on the goals of the user
         program.

      5. An opcode for the query.  The two types of completion queries
         are "Completion Query - Multiple", or CQUERYM, which asks for
         all RRs which could complete the specified input, and
         "Completion Query - Unique", or CQUERYU, which asks for the
         "best" completion.

         CQUERYM is used by user programs which want to know if
         ambiguities exist or wants to do its own determinations as to
         the best choice of the available candidates.

         CQUERYU is used by user programs which either do not wish to
         deal with multiple choices or are willing to use the closeness
         criteria used by CQUERYU to select the best match.

      When a name server receives either completion query, it first
      looks for RRs that begin (on the left) with the same labels as are
      found in QNAME (with the root deleted), and which match the QTYPE
      and QCLASS.  This search is called "whole label" matching.  If one
      or more hits are found the name server either returns all of the
      hits (CQUERYM) or uses the closeness criteria described below to
      eliminate all but one of the matches (CQUERYU).

      If the whole label match fails to find any candidates, then the
      name server assumes that the rightmost label of QNAME (after root
      deletion) is not a complete label, and looks for candidates that
      would match if characters were added (on the right) to the
      rightmost label of QNAME.  If one or more hits are found the name
      server either returns all of the hits (CQUERYM) or uses the
      closeness criteria described below to eliminate all but one of the
      matches (CQUERYU).


Mockapetris                                                    [Page 20]


RFC 883                                                    November 1983
                         Domain Names - Implementation and Specification


      If a CQUERYU query encounters multiple hits, it uses the following
      sequence of rules to discard multiple hits:

      1. Discard candidates that have more labels than others.  Since
         all candidates start with the partial name and end with the
         target name, this means that we select those entries that
         require the fewest number of added labels.  For example, a host
         search with a target of "ISI.ARPA" and a partial name of "A"
         will select A.ISI.ARPA in preference to A.IBM-PCS.ISI.ARPA.

      2. If partial label matching was used, discard those labels which