draft-daigle-napstr-04.txt

bind 9.3结合mysql数据库

   Specifically not addressed in this document is how to select the
   domain for which the service+protocol is being sought.  It is up to
   other conventions to define how that might be used (e.g., instant
   messaging standards can define what domain to use from IM URIs, how
   to step down from foobar.example.com to example.com, and so on, if
   that is applicable).

   Although this document proposes a DDDS application that does not use
   all the features of NAPTR resource records, it does not mean to imply
   that DNS resolvers should fail to implement all aspects of the NAPTR
   RR standard.  A DDDS application is a client use convention.

   The rest of this section outlines the specific elements that protocol
   developers must determine and document in order to make use of S-
   NAPTR.

3.1.1 Registration of application service and protocol tags

   Application protocol developers that wish to make use of S-NAPTR must
   make provision to register any relevant application service and
   application protocol tags, as described in Section 6.



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


3.1.2 Definition of conditions for retry/failure

   One other important aspect that must be defined is the expected
   behaviour for interacting with the servers that are reached via S-
   NAPTR.  Specifically,  under what circumstances should the client
   retry a target that was found via S-NAPTR?  What should it consider a
   failure that causes it to return to the S-NAPTR process to determine
   the next serviceable target (a less preferred target)?

   For example, if the client gets a "connection refused" from a server,
   should it retry for some (protocol-dependent) period of time?  Or,
   should it try the next-preferred target in the S-NAPTR chain of
   resolution?  Should it only try the next-preferred target if it
   receives a protocol-specific permanent error message?

   The most important thing is to select one expected behaviour and
   document it as part of the use of S-NAPTR.

   As noted earlier, failure to provide appropriate credentials to
   identify the server as being authoritative for the original taret
   domain is always considered a failure condition.

3.1.3 Server identification and handshake

   As noted in Section 7, use of the DNS for server location increases
   the importance of using protocol-specific handshakes to determine and
   confirm the identity of the server that is eventually reached.

   Therefore, application protocol developers using S-NAPTR should
   identify the mechanics of the expected identification handshake when
   the client connects to a server found through S-NAPTR.

3.2 Guidelines for Domain Administrators

   Although S-NAPTR aims to provide a "straightforward" application of
   DDDS and use of NAPTR records, it is still possible to create very
   complex chains and dependencies with the NAPTR and SRV records.

   Therefore, domain administrators are called upon to use S-NAPTR with
   as much restraint as possible, while still achieving their service
   design goals.

   The complete set of NAPTR, SRV and A RRs that are "reachable" through
   the S-NAPTR process for a particular application service can be
   thought of as a "tree".  Each NAPTR RR retrieved points to more NAPTR
   or SRV records; each SRV record points to several A record lookups.
   Even though a particular client can "prune" the tree to use only
   those records referring to application protocols supported by the



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


   client, the tree could be quite deep, and retracing the tree to retry
   other targets can become expensive if the tree has many branches.

   Therefore,

   o  Fewer branches is better:  for both NAPTR and SRV records, provide
      different targets with varying preferences where appropriate
      (e.g., to provide backup services, etc), but don't look for
      reasons to provide more.

   o  Shallower is better:  avoid using NAPTR records to "rename"
      services within a zone.  Use NAPTR records to identify services
      hosted elsewhere (i.e., where you cannot reasonably provide the
      SRV records in your own zone).


3.3 Guidelines for Client Software Writers

   To properly understand DDDS/NAPTR, an implementor must read [6].
   However, the most important aspect to keep in mind is that, if one
   target fails to work for the application, it is expected that the
   application will continue through the S-NAPTR tree to try the (less
   preferred) alternatives.

4. Illustrations

4.1 Use Cases

   The basic intended use cases for which S-NAPTR has been developed
   are:

   o  Service discovery within a domain.  For example, this can be used
      to find the "authoritative" server for some type of service within
      a domain (see the specific example in Section 4.2).

   o  Multiple protocols.  This is increasingly common as new
      application services are defined.  This includes the case of
      instant messaging (a service) which can be offered with multiple
      protocols (see Section 4.3).

   o  Remote hosting.  Each of the above use cases applies within the
      administration of a single domain.  However, one domain operator
      may elect to engage another organization to provide an application
      service.  See Section 4.4 for an example that cannot be served by
      SRV records alone.






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


4.2 Service Discovery within a Domain

   There are occasions when it is useful to be able to determine the
   "authoritative" server for a given application service within a
   domain.  This is "discovery", because there is no a priori knowledge
   as to whether or where the service is offered; it is therefore
   important to determine the location and characteristics of the
   offered service.

   For example, there is growing discussion of having a generic
   mechanism for locating the keys or certificates associated with
   particular application (servers) operated in (or for) a particular
   domain.  Here's a hypothetical case for storing application key or
   certificate data for a given domain.  The premise is that some
   credentials registry (CredReg) service has been defined to be a leaf
   node service holding the keys/certs for the servers operated by (or
   for) the domain.  Furthermore, it is assumed that more than one
   protocol is available to provide the service for a particular domain.
   This DDDS-based approach is used to find the CredReg server that
   holds the information.

   Thus, the set of NAPTR records for thinkingcat.example might look
   like this:

   thinkingcat.example.
   ;;       order pref flags service                 regexp  replacement
   IN NAPTR 100   10   ""    "CREDREG:ldap:iris-beep" ""     theserver.thinkingcat.example.

   Note that another domain, offering the same application service,
   might offer it using a different set of application protocols:

   anotherdomain.example.
   ;;       order pref flags service                    regexp replacement
   IN NAPTR 100   10   ""    "CREDREG:iris-lw:iris-beep" ""    foo.anotherdomain.example.


4.3 Multiple Protocols

   As it stands, there are several different protocols proposed for
   offering "instant message" services.  Assuming that "IM" was
   registered as an application service, this DDDS application could be
   used to determine the available services for delivering to a target.

   Two particular features of instant messaging should be noted:

   1.  gatewaying is expected to bridge communications across protocols

   2.  instant messaging servers are likely to be operated out of a



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


       different domain than the instant messaging address, and servers
       of different protocols may be offered by independent
       organizations

   For example, "thinkingcat.example" may support its own servers for
   the "ProtA" instant messaging protocol, but rely on outsourcing from
   "example.com" for "ProtC" and "ProtB" servers.

   Using this DDDS-based approach, thinkingcat.example can indicate a
   preference ranking for the different types of servers for the instant
   messaging service, and yet the out-sourcer can independently rank the
   preference and ordering of servers.  This independence is not
   achievable through the use of SRV records alone.

   Thus, to find the IM services for thinkingcat.example, the NAPTR
   records for thinkingcat.example are retrieved:

   thinkingcat.example.
   ;;	order pref flags service   regexp replacement
   IN NAPTR 100  10   "s"   "IM:ProtA" ""    _ProtA._tcp.thinkingcat.example.
   IN NAPTR 100  20   "s"   "IM:ProtB" ""    _ProtB._tcp.example.com.
   IN NAPTR 100  30   "s"   "IM:ProtC" ""    _ProtC._tcp.example.com.

   and then the administrators at example.com can manage the preference
   rankings of the servers they use to support the ProtB service:

   _ProtB._tcp.example.com.
    ;;    Pref Weight Port  Target
   IN SRV 10    0     10001 bigiron.example.com
   IN SRV 20    0     10001 backup.im.example.com
   IN SRV 30    0     10001 nuclearfallout.australia-isp.example


4.4 Remote Hosting

   In the Instant Message hosting example in Section 4.3, the service
   owner (thinkingcat.example) had to host pointers to the hosting
   service's SRV records in the thinkingcat.example domain.

   A better way to approach this is to have one NAPTR RR in the
   thinkingcat.example domain pointing to all the hosted services, and
   the hosting domain has NAPTR records for each service to map them to
   whatever local hosts it chooses (and may change from time to time).








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


   thinkingcat.example.
   ;;      order pref flags service         regexp replacement
   IN NAPTR 100  10   "s"   "IM:ProtA"       ""    _ProtA._tcp.thinkingcat.example.
   IN NAPTR 100  20   ""    "IM:ProtB:ProtC" ""    thinkingcat.example.com.


   and then the administrators at example.com can break out the
   individual application protocols and manage the preference rankings
   of the servers they use to support the ProtB service (as before):

   thinkingcat.example.com.
   ;;      order pref flags service   regexp  replacement
   IN NAPTR 100  10   "s"   "IM:ProtC" ""     _ProtC._tcp.example.com.
   IN NAPTR 100  20   "s"   "IM:ProtB" ""     _ProtB._tcp.example.com.



   _ProtC._tcp.example.com.
    ;;    Pref Weight Port  Target
   IN SRV 10    0     10001 bigiron.example.com
   IN SRV 20    0     10001 backup.im.example.com
   IN SRV 30    0     10001 nuclearfallout.australia-isp.example


4.5 Sets of NAPTR RRs

   Note that the above sections assumed that there was one service
   available (via S-NAPTR) per domain.  Often, that will not be the
   case.  Assuming thinkingcat.example had the CredReg service set up as
   described in Section 4.2 and the instant messaging service set up as
   described in Section 4.4, then a client querying for the NAPTR RR set
   from thinkingcat.com would get the following answer:

   thinkingcat.example.
   ;;       order pref flags service          regexp  replacement
   IN NAPTR 100   10   "s"   "IM:ProtA"        ""     _ProtA._tcp.thinkingcat.example.
   IN NAPTR 100   20   ""    "IM:ProtB:ProtC:" ""     thinkingcat.example.com.
   IN NAPTR 200   10   ""    "CREDREG:ldap:iris-beep" "" bouncer.thinkingcat.example.

   Sorting them by increasing "ORDER", the client would look through the
   SERVICE strings to determine if there was a NAPTR RR that matched the
   application service it was looking for, with an application protocol
   it could use.  The first (lowest PREF) record that so matched is the
   one the client would use to continue.

4.6 Sample sequence diagram

   Consider the example in Section 4.3.  Visually, the sequence of steps



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