draft-daigle-napstr-04.txt

bind 9.3结合mysql数据库

A.2 First Well Known Rule

   The "First Well Known Rule" is identity -- that is, the output of the
   rule is the Application Unique String, the domain label for which the
   authoritative server for a particular service is sought.

A.3 Expected Output

   The expected output of this Application is the information necessary
   to connect to authoritative server(s) (host, port, protocol) for an
   application service within a given a given domain.

A.4 Flags

   This DDDS Application uses only 2 of the Flags defined for the
   URI/URN Resolution Application ([8]): "S" and "A".  No other Flags
   are valid.

   Both are for terminal lookups.  This means that the Rule is the last
   one and that the flag determines what the next stage should be.  The



Daigle & Newton          Expires August 15, 2004               [Page 17]

Internet-Draft           draft-daigle-napstr-04            February 2004


   "S" flag means that the output of this Rule is a domain label for
   which one or more SRV [5] records exist.  "A" means that the output
   of the Rule is a domain name and should be used to lookup address
   records for that domain.

   Consistent with the DDDS algorithm, if the Flag string is empty the
   next lookup is for another NAPTR record (for the replacement target).

A.5 Service Parameters

   Service Parameters for this Application take the form of a string of
   characters that follow this ABNF ([3]):

      service-parms = [ [app-service] *(":" app-protocol)]
      app-service   = experimental-service  / iana-registered-service
      app-protocol  = experimental-protocol / iana-registered-protocol
      experimental-service      = "x-" 1*30ALPHANUMSYM
      experimental-protocol     = "x-" 1*30ALPHANUMSYM
      iana-registered-service   = ALPHA *31ALPHANUMSYM
      iana-registered-protocol  = ALPHA *31ALPHANUM
      ALPHA         =  %x41-5A / %x61-7A   ; A-Z / a-z
      DIGIT         =  %x30-39 ; 0-9
      SYM           =  %x2B / %x2D / %x2E  ; "+" / "-" / "."
      ALPHANUMSYM   =  ALPHA / DIGIT / SYM
      ; The app-service and app-protocol tags are limited to 32
      ; characters and must start with an alphabetic character.
      ; The service-parms are considered case-insensitive.

   Thus, the Service Parameters may consist of an empty string, just an
   app-service, or an app-service with one or more app-protocol
   specifications separated by the ":" symbol.

   Note that this is similar to, but not the same as the syntax used in
   the URI DDDS application ([8]).  The DDDS DNS database requires each
   DDDS application to define the syntax of allowable service strings.
   The syntax here is expanded to allow the characters that are valid in
   any URI scheme name (see [1]).  Since "+" (the separator used in the
   RFC3404 service parameter string) is an allowed character for URI
   scheme names, ":" is chosen as the separator here.

A.5.1 Application Services

   The "app-service" must be a registered service [this will be an IANA
   registry; this is not the IANA port registry, because we want to
   define services for which there is no single protocol, and we don't
   want to use up port space for nothing].





Daigle & Newton          Expires August 15, 2004               [Page 18]

Internet-Draft           draft-daigle-napstr-04            February 2004


A.5.2 Application Protocols

   The protocol identifiers that are valid for the "app-protocol"
   production are any standard, registered protocols [IANA registry
   again -- is this the list of well known/registered ports?].

A.6 Valid Rules

   Only substitution Rules are permitted for this application.  That is,
   no regular expressions are allowed.

A.7 Valid Databases

   At present only one DDDS Database is specified for this Application.
   [7] specifies a DDDS Database that uses the NAPTR DNS resource record
   to contain the rewrite rules.  The Keys for this database are encoded
   as domain-names.

   The First Well Known Rule produces a domain name, and this is the Key
   that is used for the first lookup -- the NAPTR records for that
   domain are requested.

   DNS servers MAY interpret Flag values and use that information to
   include appropriate NAPTR, SRV or A records in the Additional
   Information portion of the DNS packet.  Clients are encouraged to
   check for additional information but are not required to do so.  See
   the Additional Information Processing section of [7] for more
   information on NAPTR records and the Additional Information section
   of a DNS response packet.

Appendix B. Pseudo pseudocode for S-NAPTR

B.1 Finding the first (best) target

   Assuming the client supports 1 protocol for a particular application
   service, the following pseudocode outlines the expected process to
   find the first (best) target for the client, using S-NAPTR.


    target = [initial domain]
    naptr-done = false

    while (not naptr-done)
     {
      NAPTR-RRset = [DNSlookup of NAPTR RRs for target]
      [sort NAPTR-RRset by ORDER, and PREF within each ORDER]
      rr-done = false
      cur-rr = [first NAPTR RR]



Daigle & Newton          Expires August 15, 2004               [Page 19]

Internet-Draft           draft-daigle-napstr-04            February 2004


      while (not rr-done)
         if ([SERVICE field of cur-rr contains desired application
              service and application protocol])
            rr-done = true
            target= [REPLACEMENT target of NAPTR RR]
         else
            cur-rr = [next rr in list]

         if (not empty [FLAG in cur-rr])
            naptr-done = true
     }

    port = -1

    if ([FLAG in cur-rr is "S"])
     {
      SRV-RRset = [DNSlookup of SRV RRs for target]
      [sort SRV-RRset based on PREF]
      target = [target of first RR of SRV-RRset]
      port = [port in first RR of SRV-RRset]
     }

    ; now, whether it was an "S" or an "A" in the NAPTR, we
    ; have the target for an A record lookup

    host = [DNSlookup of target]

    return (host, port)



B.2 Finding subsequent targets

   The pseudocode in Appendix B is crafted to find the first, most
   preferred, host-port pair for a particular application service an
   protocol.  If, for any reason, that host-port pair did not work
   (connection refused, application-level error), the client is expected
   to try the next host-port in the S-NAPTR tree.

   The pseudocode above does not permit retries -- once complete, it
   sheds all context of where in the S-NAPTR tree it finished.
   Therefore, client software writers could

   o  entwine the application-specific protocol with the DNS lookup and
      RRset processing described in the pseudocode and continue the S-
      NAPTR processing if the application code fails to connect to a
      located host-port pair;




Daigle & Newton          Expires August 15, 2004               [Page 20]

Internet-Draft           draft-daigle-napstr-04            February 2004


   o  use callbacks for the S-NAPTR processing;

   o  use an S-NAPTR resolution routine that finds *all* valid servers
      for the required application service and protocol from the
      originating domain, and provides them in sorted order for the
      application to try in order.













































Daigle & Newton          Expires August 15, 2004               [Page 21]

Internet-Draft           draft-daigle-napstr-04            February 2004


Full Copyright Statement

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Daigle & Newton          Expires August 15, 2004               [Page 22]