draft-daigle-napstr-04.txt

bind 9.3结合mysql数据库

   required for the client to reach the final server for a "ProtB"
   service for IM for the thinkingcat.example domain is as follows:


   Client   NS for                NS for
            thinkingcat.example   example.com    backup.im.example.com
                |                     |                  |
     1 -------->|                     |                  |
     2 <--------|                     |                  |
     3 ------------------------------>|                  |
     4 <------------------------------|                  |
     5 ------------------------------>|                  |
     6 <------------------------------|                  |
     7 ------------------------------>|                  |
     8 <------------------------------|                  |
     9 ------------------------------------------------->|
    10 <-------------------------------------------------|
    11 ------------------------------------------------->|
    12 <-------------------------------------------------|
   (...)



   1.  the name server (NS) for thinkingcat.example is reached with a
        request for all NAPTR records

   2.  the server responds with the NAPTR records shown in Section 4.3.

   3.  the second NAPTR record matches the desired criteria; that has an
        "s" flag and a replacement fields of "_ProtB._tcp.example.com".
        So, the client looks up SRV records for that target, ultimately
        making the request of the NS for example.com.

   4.  the response includes the SRV records listed in Section 4.3.

   5.  the client attempts to reach the server with the lowest PREF in
        the SRV list -- looking up the A record for the SRV record's
        target (bigiron.example.com).

   6.  the example.com NS responds with an error message -- no such
        machine!

   7.  the client attempts to reach the second server in the SRV list,
        and looks up the A record for backup.im.example.com

   8.  the client gets the A record with the IP address for
        backup.im.example.com from example.com's NS.




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


   9.  the client connects to that IP address, on port 10001 (from the
        SRV record), using ProtB over tcp.

   10.  the server responds with an "OK" message.

   11.  the client uses ProtB to challenge that this server has
        credentials to operate the service for the original domain
        (thinkingcat.example)

   12.  the server responds, and the rest is IM.


5. Motivation and Discussion

   Increasingly, application protocol standards are using domain names
   to identify server targets, and stipulating that clients should look
   up SRV resource records to determine the host and port providing the
   server.  This enables a distinction between naming an application
   service target and actually hosting the server.  It also increases
   flexibility in hosting the target service:

   o  the server may be operated by a completely different organization
      without having to list the details of that organization's DNS
      setup (SRVs)

   o  multiple instances can be set up (e.g., for load balancing or
      secondaries)

   o  it can be moved from time to time without disrupting clients'
      access, etc.

   This is quite useful, but Section 5.1 outlines some of the
   limitations inherent in the approach.

   That is, while SRV records can be used to map from a specific service
   name and protocol for a specific domain to a specific server, SRV
   records are limited to one layer of indirection, and are focused on
   server administration rather than on application naming.  And, while
   the DDDS specification and use of NAPTR allows multiple levels of
   redirection before locating the target server machine with an SRV
   record, this proposal requires only a subset of NAPTR strictly bound
   to domain names, without making use of the REGEXP field of NAPTR.
   These restrictions make the client's resolution process much more
   predictable and efficient than with some potential uses of NAPTR
   records.  This is dubbed "S-NAPTR" -- a "S"traightforward use of
   NAPTR records.





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


5.1 So, why not just SRV records?

   An expected question at this point is: this is so similar in
   structure to SRV records, why are we doing this with DDDS/NAPTR?

   Limitations of SRV include:

   o  SRV provides a single layer of indirection -- the outcome of an
      SRV lookup is a new domain name for which the A RR is to be found.

   o  the purpose of SRV is focused on individual server administration,
      not application naming: as stated in [5] "The SRV RR allows
      administrators to use several servers for a single domain, to move
      services from host to host with little fuss, and to designate some
      hosts as primary servers for a service and others as backups."

   o  target servers by "service" (e.g., "ldap") and "protocol" (e.g.,
      "tcp") in a given domain.  The definition of these terms implies
      specific things (e.g., that protocol should be one of UDP or TCP)
      without being precise.  Restriction to UDP and TCP is insufficient
      for the uses described here.

   The basic answer is that SRV records provide mappings from protocol
   names to host and port.  The use cases described herein require an
   additional layer -- from some service label to servers that may in
   fact be hosted within different administrative domains.  We could
   tweak SRV to say that the next lookup could be something other than
   an address record, but that is more complex than is necessary for
   most applications of SRV.

5.2 So, why not just NAPTR records?

   That's a trick question.  NAPTR records cannot appear in the wild --
   see [6].  They must be part of a DDDS application.

   The purpose here is to define a single, common mechanism (the DDDS
   application) to use NAPTR when all that is desired is simple DNS-
   based location of services.  This should be easy for applications to
   use -- some simple IANA registrations and it's done.

   Also, NAPTR has very powerful tools for expressing "rewrite" rules.
   That power (==complexity) makes some protocol designers and service
   administrators nervous.  The concern is that it can translate into
   unintelligible, noodle-like rule sets that are difficult to test and
   administer.

   This proposed DDDS application specifically uses a subset of NAPTR's
   abilities.  Only "replacement" expressions are allowed, not "regular



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


   expressions".

6. IANA Considerations

   This document calls for 2 IANA registries:  one for application
   service tags, and one for application protocol tags.

   Application service and protocol tags should be defined in an RFC
   (unless the "x-" experimental form is used, in which case they are
   unregistered).  There are no restrictions placed on the tags other
   than that they must conform with the syntax defined below (Appendix
   A.5).  The IANA registries should list the tags and the RFC that
   defines their use.

7. Security Considerations

   The security of this approach to application service location is only
   as good as the security of the DNS servers along the way.  If any of
   them is compromised, bogus NAPTR and SRV records could be inserted to
   redirect clients to unintended destinations.  This problem is hardly
   unique to S-NAPTR (or NAPTR in general).

   To protect against DNS-vectored attacks, applications should define
   some form of end-to-end authentication to ensure that the correct
   destination has been reached.  Many application protocols such as
   HTTPS, BEEP, IMAP, etc...  define the necessary handshake mechansims
   to accomplish this task.

   The basic mechanism works in the following way:

   1.  During some portion of the protocol handshake, the client sends
       to the server the original name of the desired destination (i.e.
       no transformations that may have resulted from NAPTR
       replacements, SRV targets, or CNAME changes).  In certain cases
       where the application protocol does not have such a feature but
       TLS may be used, it is possible to use the "server_name" TLS
       extension.

   2.  The server sends back to the client a credential with the
       appropriate name.  For X.509 certificates, the name would either
       be in the subjectDN or subjectAltName fields.  For Kerberos, the
       name would be a service principle name.

   3.  Using the matching semantics defined by the application protocol,
       the client compares the name in the credential with the name sent
       to the server.

   4.  If the names match, there is reasonable assurance that the



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


       correct end point has been reached.

   It is important to note that this document does not define either the
   handshake mechanism, the specific credenential naming fields, nor the
   name matching semantics.  Definitions of S-NAPTR for particular
   application protocols MUST define these.

8. Acknowledgements

   Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd for
   discussion and input that has (hopefully!) provoked clarifying
   revisions of this document.

References

   [1]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [4]  Eastlake, D., "Domain Name System Security Extensions", RFC
        2535, March 1999.

   [5]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
        specifying the location of services (DNS SRV)", RFC 2782,
        February 2000.

   [6]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        One: The Comprehensive DDDS", RFC 3401, October 2002.

   [7]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        Three: The Domain Name System (DNS) Database", RFC 3403, October
        2002.

   [8]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        Four: The Uniform Resource Identifiers (URI)", RFC 3404, October
        2002.










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


Authors' Addresses

   Leslie Daigle
   VeriSign, Inc.
   21355 Ridgetop Circle
   Dulles, VA  20166
   US

   EMail: [e-mail]; [e-mail]


   Andrew Newton
   VeriSign, Inc.
   21355 Ridgetop Circle
   Dulles, VA  20166
   US

   EMail: [e-mail]

Appendix A. Application Service Location Application of DDDS

   This section defines the DDDS application, as described in [6].

A.1 Application Unique String

   The Application Unique String is domain label for which an
   authoritative server for a particular service is sought.