draft-daigle-napstr-04.txt

bind 9.3结合mysql数据库

Network Working Group                                          L. Daigle
Internet-Draft                                                 A. Newton
Expires: August 15, 2004                                  VeriSign, Inc.
                                                       February 15, 2004


    Domain-based Application Service Location Using SRV RRs and the
              Dynamic Delegation Discovery Service (DDDS)
                       draft-daigle-napstr-04.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 15, 2004.

Copyright Notice

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

Abstract

   This memo defines a generalized mechanism for application service
   naming that allows service location without relying on rigid domain
   naming conventions (so-called name hacks).  The proposal defines a
   Dynamic Delegation Discovery System (DDDS) Application to map domain
   name, application service name, and application protocol to target
   server and port, dynamically.







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


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.    Straightforward-NAPTR (S-NAPTR) Specification  . . . . . . .  4
   2.1   Key Terms  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.2   S-NAPTR DDDS Application Usage . . . . . . . . . . . . . . .  5
   2.2.1 Ordering and Preference  . . . . . . . . . . . . . . . . . .  5
   2.2.2 Matching and non-Matching NAPTR Records  . . . . . . . . . .  5
   2.2.3 Terminal and Non-Terminal NAPTR Records  . . . . . . . . . .  5
   2.2.4 S-NAPTR and Successive Resolution  . . . . . . . . . . . . .  6
   2.2.5 Clients Supporting Multiple Protocols  . . . . . . . . . . .  6
   3.    Guidelines . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.1   Guidelines for Application Protocol Developers . . . . . . .  7
   3.1.1 Registration of application service and protocol tags  . . .  7
   3.1.2 Definition of conditions for retry/failure . . . . . . . . .  8
   3.1.3 Server identification and handshake  . . . . . . . . . . . .  8
   3.2   Guidelines for Domain Administrators . . . . . . . . . . . .  8
   3.3   Guidelines for Client Software Writers . . . . . . . . . . .  9
   4.    Illustrations  . . . . . . . . . . . . . . . . . . . . . . .  9
   4.1   Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   4.2   Service Discovery within a Domain  . . . . . . . . . . . . . 10
   4.3   Multiple Protocols . . . . . . . . . . . . . . . . . . . . . 10
   4.4   Remote Hosting . . . . . . . . . . . . . . . . . . . . . . . 11
   4.5   Sets of NAPTR RRs  . . . . . . . . . . . . . . . . . . . . . 12
   4.6   Sample sequence diagram  . . . . . . . . . . . . . . . . . . 12
   5.    Motivation and Discussion  . . . . . . . . . . . . . . . . . 14
   5.1   So, why not just SRV records?  . . . . . . . . . . . . . . . 15
   5.2   So, why not just NAPTR records?  . . . . . . . . . . . . . . 15
   6.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 16
   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 16
   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
         References . . . . . . . . . . . . . . . . . . . . . . . . . 17
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
   A.    Application Service Location Application of DDDS . . . . . . 18
   A.1   Application Unique String  . . . . . . . . . . . . . . . . . 18
   A.2   First Well Known Rule  . . . . . . . . . . . . . . . . . . . 18
   A.3   Expected Output  . . . . . . . . . . . . . . . . . . . . . . 18
   A.4   Flags  . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   A.5   Service Parameters . . . . . . . . . . . . . . . . . . . . . 19
   A.5.1 Application Services . . . . . . . . . . . . . . . . . . . . 19
   A.5.2 Application Protocols  . . . . . . . . . . . . . . . . . . . 20
   A.6   Valid Rules  . . . . . . . . . . . . . . . . . . . . . . . . 20
   A.7   Valid Databases  . . . . . . . . . . . . . . . . . . . . . . 20
   B.    Pseudo pseudocode for S-NAPTR  . . . . . . . . . . . . . . . 20
   B.1   Finding the first (best) target  . . . . . . . . . . . . . . 20
   B.2   Finding subsequent targets . . . . . . . . . . . . . . . . . 21
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 23




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


1. Introduction

   This memo defines a generalized mechanism for application service
   naming that allows service location without relying on rigid domain
   naming conventions (so-called name hacks).  The proposal defines a
   Dynamic Delegation Discovery System (DDDS -- see [6]) Application to
   map domain name, application service name, and application protocol
   to target server and port, dynamically.

   As discussed in Section 5, existing approaches to using DNS records
   to dynamically determining the current host for a given application
   service are limited in terms of the use cases supported.  To address
   some of the limitations, this document defines a DDDS Application to
   map service+protocol+domain to specific server addresses using both
   NAPTR [7] and SRV ([5]) DNS resource records.  This can be viewed as
   a more general version of the use of SRV and/or a very restricted
   application of the use of NAPTR resource records.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 ([2]).

2. Straightforward-NAPTR (S-NAPTR) Specification

   The precise details of the specification of this DDDS application are
   given in Appendix A.  This section defines the usage of the DDDS
   application.

2.1 Key Terms

   An "application service" is a generic term for some type of
   application, indpendent of the protocol that may be used to offer it.
   Each application service will be associated with an IANA-registered
   tag.  For example, instant messaging is a type of application
   service, which can be implemented by many different application-layer
   protocols, and the tag "IM" (used as an illustration here) could be
   registered for it.

   An "application protocol" is used to implement the application
   service.  These are also associated with IANA-registered tags.  In
   the case where multiple transports are available for the application,
   separate tags should be defined for each transport.

   The intention is that the combination of application service and
   protocol tags should be specific enough that finding a known pair
   (e.g., "IM:ProtC") is sufficient for a client to identify a server
   with which it can communicate.




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


   Some protocols support multiple application services.  For example,
   LDAP is an application protocol, and can be found supporting various
   services (e.g., "whitepages", "directory enabled networking", etc).

2.2 S-NAPTR DDDS Application Usage

   As outlined in Appendix A, NAPTR records are used to store
   application service+protocol information for a given domain.
   Following the DDDS standard, these records are looked up,  and the
   rewrite rules (contained in the NAPTR records) are used to determine
   the successive DNS lookups, until a desirable target is found.

   For the rest of this section, refer to the set of NAPTR resource
   records for example.com shown in the figure below.

   example.com.
   ;;       order pref flags service     regexp replacement
   IN NAPTR 100   10   ""    "WP:whois++" ""    bunyip.example.
   IN NAPTR 100   20   "s"   "WP:ldap"    ""    _ldap._tcp.myldap.example.com.
   IN NAPTR 200   10   ""    "IM:protA"   ""    someisp.example.
   IN NAPTR 200   30   "a"   "IM:protB"   ""    myprotB.example.com.


2.2.1 Ordering and Preference

   A client retrieves all of the NAPTR records associated with the
   target domain name (example.com, above).  These are to be sorted in
   terms of increasing ORDER, and increasing PREF within each ORDER.

2.2.2 Matching and non-Matching NAPTR Records

   Starting with the first sorted NAPTR record, the client examines the
   SERVICE field to find a match.  In the case of the S-NAPTR DDDS
   application, that means a SERVICE field that includes the tags for
   the desired application service and a supported application protocol.

   If more than one NAPTR record matches, they are processed in
   increasing sort order.

2.2.3 Terminal and Non-Terminal NAPTR Records

   A NAPTR record with an empty FLAG field is "non-terminal".  That is,
   more NAPTR RR lookups are to be performed.  Thus, to process a NAPTR
   record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is
   used as the target of the next DNS lookup -- for NAPTR RRs.

   In S-NAPTR, the only terminal flags are "S" and "A".  These are
   called "terminal" NAPTR lookups because they denote the end of the



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


   DDDS/NAPTR processing rules.  In the case of an "S" flag, the
   REPLACEMENT field is used as the target of a DNS query for SRV RRs,
   and normal SRV processing is applied.  In the case of an "A" flag, an
   address record is sought for the REPLACEMENT field target (and the
   default protocol port is assumed).

2.2.4 S-NAPTR and Successive Resolution

   As shown in the example NAPTR RR set above, it is possible to have
   multiple possible targets for a single application service+protocol
   pair.  These are to be pursued in order until a server is
   successfully contacted or all possible matching NAPTR records have
   been successively pursued to terminal lookups and servers contacted.
   That is, a client must backtrack and attempt other resolution paths
   in the case of failure.

   "Failure" is declared, and backtracking must be used when

   o  the designated remote server (host and port) fail to provide
      appropriate security credentials for the *originating* domain

   o  connection to the designated remote server otherwise fails -- the
      specifics terms of which are defined when an application protocol
      is registered

   o  the S-NAPTR-designated DNS lookup fails to yield expected results
      -- e.g., no A RR for an "A" target, no SRV record for an "S"
      target, or no NAPTR record with appropriate application service
      and protocol for a NAPTR lookup.  Except in the case of the very
      first NAPTR lookup, this last is a configuration error:  the fact
      that example.com has a NAPTR record pointing to "bunyip.example"
      for the "WP:Whois++" service and protocol means the administrator
      of example.com believes that service exists.  If bunyip.example
      has no "WP:Whois++" NAPTR record, the application client MUST
      backtrack and try the next available "WP:Whois++" option from
      example.com.  As there is none, the whole resolution fails.

   An application client first queries for the NAPTR RRs for the domain
   of a named application service.  The application client MUST select
   one protocol to choose The PREF field of the NAPTR RRs may be used by
   the domain administrator to The first DNS query is for the NAPTR RRs
   in the original target domain (example.com, above).

2.2.5 Clients Supporting Multiple Protocols

   In the case of an application client that supports more than one
   protocol for a given application service, it MUST pursue S-NAPTR
   resolution completely for one protocol before trying another.j It MAY



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


   choose which protocol to try first based on its own preference, or
   from the PREF ranking in the first set of NAPTR records (i.e., those
   for the target named domain).    However, the chosen protocol MUST be
   listed in that first NAPTR RR set.

   That is, what the client MUST NOT do is start looking for one
   protocol, observe that a successive NAPTR RR set supports another of
   its preferred protocols, and continue the S-NAPTR resolution based on
   that protocol.  For example, even if someisp.example offers the "IM"
   service with protocol "ProtB", there is no reason to believe it does
   so on behalf of example.com (since there is no such pointer in
   example.com's NAPTR RR set).

3. Guidelines

3.1 Guidelines for Application Protocol Developers

   The purpose of S-NAPTR is to provide application standards developers
   with a more powerful framework (than SRV RRs alone) for naming
   service targets, without requiring each application protocol (or
   service) standard to define a separate DDDS application.

   Note that this approach is intended specifically for use when it
   makes sense to associate services with particular domain names (e.g.,
   e-mail addresses, SIP addresses, etc).  A non-goal is having all
   manner of label mapped into domain names in order to use this.