Network Working Group                                          L. Daigle
Internet-Draft                                                 A. Newton
Expires: April 25, 2004                                   VeriSign, Inc.
                                                        October 26, 2003


    Domain-based Application Service Location Using SRV RRs and the
              Dynamic Delegation Discovery Service (DDDS)
                       draft-daigle-napstr-03.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 April 25, 2004.

Copyright Notice

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

Abstract

   This memo defines a Dynamic Delegation Discovery System (DDDS) [5]
   Application for domain name based discovery of application services.
   Essentially, this uses DNS NAPTR resource records [6] to provide one
   more layer of redirection for service lookup than is feasible with
   SRV ([4]) records.  It is proposed because real-life use is
   demonstrating a need for something slightly more substantial than
   SRV, and alternatively SRV usage may become twisted out of its
   intended shape.





Daigle & Newton          Expires April 25, 2004                 [Page 1]


Internet-Draft           draft-daigle-napstr-03             October 2003


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1   What this document means for application protocol developers  4
   2.    Basic Proposal . . . . . . . . . . . . . . . . . . . . . . .  4
   2.1   Key Terms  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.2   Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.    Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.1   Service Discovery within a Domain  . . . . . . . . . . . . .  6
   3.2   Multiple Protocols . . . . . . . . . . . . . . . . . . . . .  6
   3.3   Remote Hosting . . . . . . . . . . . . . . . . . . . . . . .  7
   3.4   Sets of NAPTR RRs  . . . . . . . . . . . . . . . . . . . . .  8
   4.    Motivation and Discussion  . . . . . . . . . . . . . . . . .  9
   4.1   So, why not just SRV records?  . . . . . . . . . . . . . . .  9
   4.2   So, why not just NAPTR records?  . . . . . . . . . . . . . .  9
   4.3   Open Questions . . . . . . . . . . . . . . . . . . . . . . . 10
   5.    Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.1   Guidelines for Application Protocol Developers . . . . . . . 10
   5.1.1 Registration of application service and protocol tags  . . . 10
   5.1.2 Definition of conditions for retry/failure . . . . . . . . . 10
   5.1.3 Server identification and handshake  . . . . . . . . . . . . 11
   5.2   Guidelines for Domain Administrators . . . . . . . . . . . . 11
   5.3   Guidelines for Client Software Writers . . . . . . . . . . . 12
   5.4   Pseudo pseudocode for S-NAPTR  . . . . . . . . . . . . . . . 12
   5.4.1 Finding the first (best) target  . . . . . . . . . . . . . . 12
   5.4.2 Finding subsequent targets . . . . . . . . . . . . . . . . . 13
   5.5   Sample unrolling of the S-NAPTR process  . . . . . . . . . . 13
   5.6   Sample sequence diagram  . . . . . . . . . . . . . . . . . . 14
   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
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 21







Daigle & Newton          Expires April 25, 2004                 [Page 2]


Internet-Draft           draft-daigle-napstr-03             October 2003


1. Introduction

   Increasingly, application protocol standards are using domain names
   to identify server targets, and stipulating that clients should look
   up SRV ([4]) 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 delegate some portion of the zone

   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 4.1 outlines some of the
   limitations inherent in the approach.

   To address some of the limitations, this document defines a DDDS [5]
   Application to map service+protocol+domain to specific server
   addresses using both NAPTR [6] and SRV 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.

   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 (prefetchable, cachable) than with some uses of NAPTR
   records.  This is dubbed "S-NAPTR" -- a "S"traightforward use of
   NAPTR records.

   For the purposes of this document:

   o  an "application service" is a generic term for some generic type
      of application, independent of the protocol that may be used to
      offer it.

   o  an "application protocol" is an IANA-registered tag associated
      with a protocol (and application tranpsort protocol, if several



Daigle & Newton          Expires April 25, 2004                 [Page 3]


Internet-Draft           draft-daigle-napstr-03             October 2003


      are available for the application) used to implement one or
      several services

   For example, "e-mail" is an application service; "SMTP" is the
   protocol that is used to implement it.  "Instant Messaging" is an
   application service, for which there are several existing and
   proposed application protocols ("jabber", "simple", etc).  "LDAP" is
   an application protocol which can be used to implement several
   different application services (e.g., a "whitepages" service,
   directory enabled networking service, etc).

1.1 What this document means for application protocol developers

   The purpose of this document 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.

   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.

2. Basic Proposal

   The precise details of the specification of this DDDS application are
   given in Appendix A.  In general, the proposal is to store
   application service and protocol descriptions in NAPTR records for
   individual domains.  This will enable domain administrators to
   provide redirection to other domains that provision individual
   services, with appropriate weightings and preferences.

2.1 Key Terms

   Each "application service" will be associated with an IANA-registered
   tag.  For example, instant messaging is a type of application, which



Daigle & Newton          Expires April 25, 2004                 [Page 4]


Internet-Draft           draft-daigle-napstr-03             October 2003


   is implemented by many different application-layer protocols, and the
   tag "IM" (used as an illustration here) could be registered for it.

   An "application protocol" tag represents a protocol used to implement
   the application service.  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.

2.2 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 3.1).

   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 3.2).

   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 3.3 for an example that cannot be served by
      SRV records alone.


3. Examples

   Section 3.1 illustrates the use of S-NAPTR to express the list of
   available application protocols to provide a particular service
   within a domain.  A chief purpose of S-NAPTR is to allow a layer of
   indirection between service naming and service operation that is not
   possible with SRV RRs alone.  The example in Section 3.2 illustrates
   this.  Section 3.3 revisits the first example to illustrate the power
   of S-NAPTR in separating the choice of available protocols (which the
   service owner selects) from the choice and preference of running them
   (which the hosting service establishes).






Daigle & Newton          Expires April 25, 2004                 [Page 5]


Internet-Draft           draft-daigle-napstr-03             October 2003


3.1 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.com might look like
   this:

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

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

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


3.2 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 April 25, 2004                 [Page 6]


Internet-Draft           draft-daigle-napstr-03             October 2003


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

   For example, "thinkingcat.com" 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.com 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.com, the NAPTR records
   for thinkingcat.com are retrieved:

   thinkingcat.com.
   ;;   order   pref    flags   service regexp  replacement
   IN NAPTR 100 10      "s"     "IM:ProtA" ""   _ProtA._tcp.thinkingcat.com.
   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.example.com.au


3.3 Remote Hosting

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

   If the owner domain does not have any preference about which
   application protocol is used, a better way to approach this is to
   have one NAPTR RR in the thinkingcat.com 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 April 25, 2004                 [Page 7]


Internet-Draft           draft-daigle-napstr-03             October 2003


   thinkingcat.com.
   ;;      order   pref    flags   service regexp  replacement
   IN NAPTR 100    10      "s"     "IM:ProtA" ""    _ProtA._tcp.thinkingcat.c
   om.
   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.c
   om.
   IN NAPTR 100    20      "s"     "IM:ProtB"   ""    _ProtB._tcp.example.com.



   _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.example.com.au


3.4 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.com had the CredReg service set up as
   described in Section 3.1 and the instant messaging service set up as
   described in Section 3.3, then a client querying for the NAPTR RR set
   from thinkingcat.com would get the following answer:

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

   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.




Daigle & Newton          Expires April 25, 2004                 [Page 8]


Internet-Draft           draft-daigle-napstr-03             October 2003


4. Motivation and Discussion

4.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 [4] "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.

4.2 So, why not just NAPTR records?

   That's a trick question.  NAPTR records cannot appear in the wild --
   see [5].  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.




Daigle & Newton          Expires April 25, 2004                 [Page 9]


Internet-Draft           draft-daigle-napstr-03             October 2003


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

4.3 Open Questions

   There remain some open questions about the specific approach proposed
   for S-NAPTR.

   o  Is the 32-character limit for the "service" field too limiting?

   o  Is it better-practice to put each application service/protocol
      pair in a separate NAPTR RR?

   o  Note that the previous 2 points trade off against each other --
      separate RRs for each application service/protocol reduces the
      likelihood of blowing the 32-character limit, but increases the
      size of the RRset.

   o  Is this going to generate RRsets that are likely to exceed the UDP
      packet size for the response?

   o  As described in Section 5, the client will not try to "negotiate"
      protocol preferences with the what is listed in the NAPTR records
      -- it will try its favoured protocols in turn.  The only issue
      with that is that it overrides the preferences expressed by the
      server.  Is there any way to allow this "negotiation" without
      creating an ever-more-complex S-NAPTR resolution process?


5. Guidelines

5.1 Guidelines for Application Protocol Developers

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

5.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.

5.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



Daigle & Newton          Expires April 25, 2004                [Page 10]


Internet-Draft           draft-daigle-napstr-03             October 2003


   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.

5.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.

5.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
   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.



Daigle & Newton          Expires April 25, 2004                [Page 11]


Internet-Draft           draft-daigle-napstr-03             October 2003


   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).


5.3 Guidelines for Client Software Writers

   To properly understand DDDS/NAPTR, an implementor must read [5].
   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.

5.4 Pseudo pseudocode for S-NAPTR

5.4.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.

   (N.B.  -- this is brittle!  no error checking!).


    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]

      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
     }

    if ([FLAG in cur-rr is "U"])



Daigle & Newton          Expires April 25, 2004                [Page 12]


Internet-Draft           draft-daigle-napstr-03             October 2003


      return target  ; the replacement field of the NAPTR record

    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)


   If a client actually supports multiple protocols for a particular
   application service, it could apply the algorithm above for each
   protocol in turn, in order of its preference.

5.4.2 Finding subsequent targets

   The pseudocode in Section 5.4 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 should either

   o  entwine the application-specific protocol with the DNS lookup and
      RRset processing described in the pseudocode; or

   o  use callbacks for the S-NAPTR processing.


5.5 Sample unrolling of the S-NAPTR process

   The following is an example of using the S-NAPTR process.  It uses
   the tag 'WEB' to denote the web browsing application service and the
   tag 'SOAP' to denote an XML-based RPC service.  It uses the
   application protocol tag of 'http' to denote the protocol used for



Daigle & Newton          Expires April 25, 2004                [Page 13]


Internet-Draft           draft-daigle-napstr-03             October 2003


   the above services.

   1.  The client requests all the NAPTR records for the target DNS
       label.

   2.  For the S-NAPTR use of NAPTR RRs, the NAPTR regexp field will
       always be empty.  Therefore, the client ignores all NAPTR RRs
       with anything in the regexp field, or flags that are not defined
       for use in S-NAPTR.

   3.  From the remaining NAPTR records, the client selects the lowest-
       order and then lowest preference NAPTR record with the desired
       application service (e.g., 'WEB' or 'SOAP').   An empty flag
       field indicates the next lookup should be for a NAPTR record (as
       opposed to SRV, or A, etc...).  The replacement field is used as
       the label for which the NAPTR records are retrieved.

   4.  From here, the client follows the NAPTR record for the
       application service using the desired application protocol from
       the original list of application protocols given for that service
       type (e.g.  'WEB:http' or 'SOAP:http').

   5.  Supposing the matching NAPTR record has "s" in the flag field,
       the next lookup is for SRV records using the value of the
       replacement field as the DNS label.  The client selects the SRV
       records with the appropriate priority and weight, and uses that
       to determine the target of the next DNS lookup (for an A or AAAA
       record).

   6.  Once the client has determined the IP address of the server using
       an A or AAAA record, the client attempts a connection for each
       address record for each server name on the specified port with
       the selected protocol.  If the connection is refused, then the
       client should repeat the previous step.  If all SRV records from
       the previous step are exhausted, then the client should signal an
       exception state.


5.6 Sample sequence diagram

   Consider the example in Section 3.2.  Visually, the sequence of steps
   required for the client to reach the final server for a "ProtB"
   service for IM for the thinkingcat.com domain is as follows:








Daigle & Newton          Expires April 25, 2004                [Page 14]


Internet-Draft           draft-daigle-napstr-03             October 2003


   Client   NS for                NS for
            thinkingcat.com       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.com is reached with a
        request for all NAPTR records

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

   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 3.2.

   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.

   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.



Daigle & Newton          Expires April 25, 2004                [Page 15]


Internet-Draft           draft-daigle-napstr-03             October 2003


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

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


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.




Daigle & Newton          Expires April 25, 2004                [Page 16]


Internet-Draft           draft-daigle-napstr-03             October 2003


   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
       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]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

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

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

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

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

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








Daigle & Newton          Expires April 25, 2004                [Page 17]


Internet-Draft           draft-daigle-napstr-03             October 2003


Authors' Addresses

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

   EMail: leslie@verisignlabs.com; leslie@thinkingcat.com


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

   EMail: anewton@verisignlabs.com

Appendix A. Application Service Location Application of DDDS

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

A.1 Application Unique String

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

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 3 of the Flags defined for the
   URI/URN Resolution Application ([7]): "S", "A" and "U".  No other
   Flags are valid.

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



Daigle & Newton          Expires April 25, 2004                [Page 18]


Internet-Draft           draft-daigle-napstr-03             October 2003


   The "S" flag means that the output of this Rule is a domain label for
   which one or more SRV [4] 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.  "U" means that the output of the Rule is a
   URI which should be resolved.

   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 ([2]):

      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 ([7]).  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 April 25, 2004                [Page 19]


Internet-Draft           draft-daigle-napstr-03             October 2003


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.
   [6] 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 [6] for more
   information on NAPTR records and the Additional Information section
   of a DNS response packet.






















Daigle & Newton          Expires April 25, 2004                [Page 20]


Internet-Draft           draft-daigle-napstr-03             October 2003


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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 April 25, 2004                [Page 21]