DNS Extensions                                            O. Gudmundsson
Internet-Draft                                             Shinkuro Inc.
Updates: 2782 (if approved)                                    A. Hoenes
Intended status: Standards Track                                  TR-Sys
Expires: July 1, 2010                                  December 28, 2009


                  Clarification of DNS SRV Owner Names
                draft-gudmundsson-dnsext-srv-clarify-00

Abstract

   The DNS SRV record has been specified in RFC 2052 and RFC 2782 for
   use in dynamic service discovery for a domain.  These two RFCs did
   not clearly specify an IANA registry for the names of the services
   and their underlying protocols.  This document clarifies RFC 2782
   regarding the formation and use of the Service Prefix in the owner
   name of SRV records, based on the unified IANA registry for "Service
   Names and Port Numbers".

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 July 1, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Gudmundsson & Hoenes      Expires July 1, 2010                  [Page 1]


Internet-Draft          SRV Prefix Clarifications          December 2009


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Problem Statement  . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Objective for this Document and its Companions . . . . . .  4
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  General Considerations for SRV Service Prefixes  . . . . . . .  6
   3.  Protocol Labels  . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Standard Service Labels  . . . . . . . . . . . . . . . . . . .  8
   5.  Service Discovery Client Considerations  . . . . . . . . . . . 10
     5.1.  Protocol Label Selection . . . . . . . . . . . . . . . . . 11
     5.2.  Service Label Selection  . . . . . . . . . . . . . . . . . 11
   6.  Provisioning of SRV records  . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Extended SRV Service Labels . . . . . . . . . . . . . 15
     A.1.  Motivation and Solution Space  . . . . . . . . . . . . . . 15
     A.2.  Specification  . . . . . . . . . . . . . . . . . . . . . . 15
     A.3.  Applicability  . . . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17

















Gudmundsson & Hoenes      Expires July 1, 2010                  [Page 2]


Internet-Draft          SRV Prefix Clarifications          December 2009


1.  Introduction

   The SRV resource record (RR) was originally introduced in RFC 2052
   [RFC2052] as an experimental extension to the Domain Name System
   (DNS).  It proved a highly valuable addition for service location and
   provisioning.  The SRV record was thus standardized in RFC 2782
   [RFC2782].  The main difference between these two versions is the use
   of the underscore ("_") prefix character in names to avoid naming
   conflicts between service names and regular names.

   The presentation form of the SRV resource record (RR type 33),
   including the recommended structure of owner names for its use, is as
   follows [RFC2782]:

      _Service._Proto.Name SRV Priority Weight Port Target

   The owner name is formed from the fully qualified domain name (FQDN)
   (indicated by "Name") of the domain that is offering the service by
   prepending a "Service Prefix" that consists of two more DNS labels.
   The first label prepended to "Name" (indicated by "_Proto") denotes
   the protocol over which the application protocol is carried; it is
   henceforth designated as the "Protocol Label".
   The final (least significant, i.e. leftmost) label prepended
   (indicated by "_Service") denotes the Service/Application that is
   being offered; it is henceforth designated as the "Service Label".

   The RDATA portion of the SRV resource record is comprised of the 16-
   bit unsigned integer components 'Priority', 'Weight', and 'Port', and
   a domain name, 'Target':
   The Priority and Weight fields are used for selecting among multiple
   SRV records at the same owner name (see RFC 2782 [RFC2782]).
   The PORT field is the port number over which the service is provided
   at the Target name, which is an FQDN of the node hosting the service.

1.1.  Problem Statement

   RFC 2782 says that the source of names for "Service" and "Proto" is
   "Assigned Numbers" (STD2) or a locally defined repository.

   However, upon reflection, both alternatives do not seem to make
   particular sense:

   o  The STD2 series of documents was obsoleted by RFC 3232 [RFC3232]
      and IANA registration publication was handed over to on-line
      registries maintained by IANA.  Unfortunately it is not explicitly
      explained in RFC 2782 which section of STD2 it is referring to,
      nor does RFC 3232 help.  By common knowledge, RFC 2782 referred to
      the Keyword columns of the "Protocol Numbers" and "Port Numbers"



Gudmundsson & Hoenes      Expires July 1, 2010                  [Page 3]


Internet-Draft          SRV Prefix Clarifications          December 2009


      IANA registries, respectively.

      As SRV records contain the port where each server provides the
      service, the outmost utility of SRV RRs is for services that do
      not have a registered port number.  Also, the number of ports
      available is small compared to the possible number of service
      names that could be registered.  Therefore, the "Port Number"
      registry needs a more strict registration policy and is not the
      proper place for registering service names for use with SRV
      resource records.

   o  Having locally defined lists of service and/or protocol names
      would equally allow to list the full service information in such
      local databases and thus make the usage of SRV records redundant.
      In any case, this scenario is not applicable for publicly
      available services where potential clients are not under the
      control of the authority offering the services, and hence most
      probably would have no access to the proper "locally provided"
      information.  The reader is reminded that locally maintained
      database solutions generally scale very poorly, and that this once
      was the major momentum for the deployment of the Domain Name
      System.

1.2.  Objective for this Document and its Companions

   In an effort to streamline and fix mistakes in assigning service
   names and port numbers over the years, an effort has been undertaken
   to create a unified "Service Names and Port Numbers" registry
   [RFCyyyy] where all service registrations will take place in the
   future.

   This document updates RFC 2782 [RFC2782] in clarifying how to use the
   registrations in that registry and other elements to construct SRV
   owner names.
   Furthermore, this document proposes an extension method for specific
   applications that need a finer granularity in specifying protocol
   stacks underlying the application protocol or have other important
   reasons to qualify the service instance provided.

   A companion document of this one, "Service Registration Fixes" [TBD],
   collects from various RFCs and IANA documents registrations that
   ought be in the "Service Names and and Ports Numbers" registry and
   specifies appropriate actions in moving the registrations over to the
   new registry.  It also gives advice for authors wishing to update
   existing specifications for particular applications that had produced
   SRV usage guidelines in a manner that is no more admissible under the
   unified rules of RFC yyyy [RFCyyyy].




Gudmundsson & Hoenes      Expires July 1, 2010                  [Page 4]


Internet-Draft          SRV Prefix Clarifications          December 2009


   Note: RFC 5507 [RFC5507] discusses the use of "underscore labels" in
   the DNS more generally, from the architectural point of view of the
   IAB.  Most such uses are not related to SRV records and hence will
   not conflict with the SRV Protocol Label; thus, there will not be
   namespace conflicts.

1.3.  Terminology

   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 RFC 2119 [RFC2119].

   For clarity and precision, this document uses the following
   capitalized terms:

   Service Name
         The identifier for a particular service registered in the
         "Service Names and Port Numbers" IANA registry [RFCyyyy].
         See Section 4 for details.

   Service Domain
         The FQDN of the domain for which a particular instance of a
         service is provided (or sought by a prospective client).

   Service Prefix (or: SRV Service Prefix)
         The service specific relative domain name (additional labels)
         prepended to the Service Domain to form the owner name of the
         SRV resource record(s) pointing to the service instance(s).  As
         usual, in the DNS presentation format (e.g., in a DNS zone
         file) all domain name labels are concatenated using the period
         (".") as a separator character.
         In RFC 2782, the Service prefix consists of exactly two labels
         (described right off below), and this specification does not
         change this.  The labels contained in a Service Prefix adhere
         to the common naming hierarchy rules for the DNS, specifying
         the most significant part (the protocol immediately carried
         over IP) on the righthand side and the particular application/
         service as the least significant part on the lefthand side.

   Protocol Label (or: SRV Protocol Label)
         The most significant label of the Service Prefix.  It indicates
         the transport protocol to which the 'Port' element of the SRV
         RDATA serves as the demultiplexor value.
         See Section 3 for details.







Gudmundsson & Hoenes      Expires July 1, 2010                  [Page 5]


Internet-Draft          SRV Prefix Clarifications          December 2009


   Service Label (or: SRV Service Label)
         The less significant (leftmost) label of the Service Prefix.
         It indicates the particular service by incorporating the
         Service Name registered for this service/application.
         See Section 4 and Appendix A for details.


2.  General Considerations for SRV Service Prefixes

   SRV Service Prefixes SHOULD consist of exactly two labels.

   If the specification of a particular application/service indicates
   that this service is to be provided at a specific registered port
   number and does not mention DNS SRV based service discovery,
   prospective clients SHOULD NOT assume the existence of SRV records
   for this application, unless the client has hints available that
   indicate otherwise -- for instance by means of configuration.  In
   this case, only the rules of Sections 3 and 4 apply.

   If the specification of a particular application/service does mention
   dynamic service discovery based on DNS SRV records but does not
   specify otherwise in a precise and unambiguous manner, the rules of
   Sections 3 and 4 apply.  In this case, a prospective client SHOULD
   look up the DNS for the appropriate SRV records for the intended
   Service Domain.

   Some services can be carried equivalently in different encapsulations
   using higher-level "substrate" protocols like HTTP, BEEP, SOAP, SIP,
   XMPP, some of which in turn can be carried over different transport
   protocols.  In this case, it is possible that certain servers for an
   application only support specific protocol stacks, or that a Service
   Domain provides a different set of servers for each protocol stack.
   Consequently, there occasionally is a need to specify such details in
   the SRV Service Prefix.  Since the Protocol Label is intentionally
   restricted (Section 3), this information has to be carried in the
   Service Label for this application.

   There are two possibilities to achieve this goal:

   a.  If there is only a small number of "substrate" protocols to
       distinguish, it is RECOMMENDED that the application designers
       register multiple Service Names with IANA in the "Service Names
       and Port Numbers" registry [RFCyyyy], which usually will start
       with the same characters and contain a suffix attached with a
       hyphen embedded in the name.

       One disadvantage of this solution is the length limitation
       imposed on the Service Name by [RFCyyyy] (15 characters, see



Gudmundsson & Hoenes      Expires July 1, 2010                  [Page 6]


Internet-Draft          SRV Prefix Clarifications          December 2009


       Section 4).  Also, [RFCyyyy] recommends that -- notwithstanding
       some very popular, and mostly legacy cases -- each service ought
       to be represented by a *single* Service Name.  If the service is
       the same and only the substrate used is different, this solution
       arguably is in conflict with [RFCyyyy].

   b.  If the number of substrate stacks to be supported is larger, or
       if the 'canonical' labels that the application designers prefer
       would result in exceeding the maximum length of Service Names, or
       if multi-layer substrates shall be represented, or if the "unique
       Service Name per service" argument is deemed important, an
       extension scheme is needed for the construction of Service Labels
       for such exceptional services.

       The non-normative Appendix A proposes a scheme for extended
       Service Labels that does not pollute the namespace of Service
       Names and hence adheres to the uniqueness and collision-freeness
       requirements of [RFCyyyy].  The basic Service Name can be easily
       extracted from these extended Service Labels, as they employ a
       separator character not allowed in Service Names to attach
       qualifier(s) to a 'basic' Service Label as specified in
       Section 4.

       Application designers who want to make use of that scheme MUST
       independently and unambiguously specify the application of that
       scheme for their service and ensure that a reference to the
       document containing this specification (if different from the
       document specifying the basic service) is added to the entry for
       that service in the "Service Names and Port Numbers" IANA
       registry, following the registration procedures of [RFCyyyy].

       To re-iterate, absent such explicit, registered specification,
       the rules of Section 4 (and, of course, Section 3 as well) still
       apply in these cases.

   Application protocol designers ought to keep service discovery
   simple.  The fewer alternatives a prospective client has to consider
   and the fewer choices he has to find suitable SRV records, the faster
   the service discovery can be performed, because it needs fewer DNS
   queries on average and thus incurs less latency.  If alternative
   transports and/or variations of the service are really needed to be
   distinguished by service discovery, to foster interoperablity there
   SHOULD always be defined a default version supported by all clients
   and servers, and configured in the DNS, thus allowing an orderly
   fallback in case client preferences cannot be accommodated.






Gudmundsson & Hoenes      Expires July 1, 2010                  [Page 7]


Internet-Draft          SRV Prefix Clarifications          December 2009


3.  Protocol Labels

   SRV Protocol Labels MUST be formed by prepending an underscore
   character ("_") to the name of an IETF transport protocol that

   -  is registered in the IANA "Protocols" registry [RFC5237];

   -  makes use of 16-bit unsigned integer demultiplexing values, at
      least at the server side of its transport associations -- these
      are traditionally denoted as "[server] port numbers";

   -  is supported by the IANA "Service Names and Port Numbers" registry
      as specified in [RFCyyyy] or by future IESG-endorsed amendments to
      that registry.

   As all domain labels, SRV Protocol Labels are matched in a case-
   insensitive manner.

   Currently, the following SRV Protocol Labels are defined :

          +----------+--------------------+---------------------+
          | Protocol | SRV Protocol Label | References          |
          +----------+--------------------+---------------------+
          | TCP      | _tcp               | [RFC0793] [RFC4614] |
          | UDP      | _udp               | [RFC0768]           |
          | UDP-lite | _udp               | [RFC3828]           |
          | DCCP     | _dccp              | [RFC4340]           |
          | SCTP     | _sctp              | [RFC4960]           |
          +----------+--------------------+---------------------+

                                  Table 1

   Note that, although they have been assigned different protocol
   numbers in the IANA Protocol Numbers registry [RFC5237]), the IANA
   "Service Names and Port Numbers" registry [RFCyyyy] does not make a
   distinction between 'classical' UDP [RFC0793] and UDP-lite [RFC3828],
   and hence both protocol variations are represented by the same SRV
   Protocol Label.


4.  Standard Service Labels

   Absent a normative document specifying otherwise, the SRV Service
   Label for a specific service/application SHOULD be in the form of a
   "Standard SRV Servcie Label" as specified in this section.

   Standard SRV Service Labels MUST be formed by prepending an
   underscore character ("_") to the Service Name of an application



Gudmundsson & Hoenes      Expires July 1, 2010                  [Page 8]


Internet-Draft          SRV Prefix Clarifications          December 2009


   protocol registered in the IANA "Service Names and Port Numbers"
   registry [RFCyyyy].

   Note that in order to make use of DNS based service discovery using
   SRV records, the application/service does *not* need an IANA-assigned
   port number (which would also be filed in the IANA "Service Names and
   Port Numbers" registry).

   The port numbers carried in the RDATA portion of the SRV records are
   locally assigned within the Service Domain; in case the service
   indeed has an IANA-assigned (default) port number, the locally
   assigned port number MAY coincide with that default port number,
   unless the documentation of the service specifies otherwise (it may
   say "MUST", "SHOULD", or recommend *against* using the default).

   As all domain name labels, SRV Service Labels are matched in a case-
   insensitive manner.

   [RFCyyyy] restricts IANA-registered Service Names to 15 characters in
   "ldh-syntax", informally:

   -  all characters MUST be either letters from A to Z, decimal digits
      from 0 to 9, or hyphens ("-");

   -  the Service Name MUST contain at least one letter or hyphen;

   -  the first and the last character MUST be a letter or digit, not a
      hyphen;

   -  two hyphens MUST NOT be adjacent in a Service Name.

   More formally, this can be restated in ABNF [RFC5234]:

      serv-label     = std-serv-label

      std-serv-label = USC service-name

      service-name   = 1*15(L-D-H)
                       ; also conforming to the <token> rule below

      token          = ( ALPHA / (1*DIGIT ((HYPHEN ALPHANUM) / ALPHA)) )
                       *([HYPHEN] ALPHANUM)

      L-D-H          = ALPHA / DIGIT / HYPHEN
      ALPHANUM       = ALPHA / DIGIT   ; A-Z, a-z, 0-9
      HYPHEN         = %x2d            ; "-" (hyphen)
      USC            = %x5f            ; "_" (underscore)
      ALPHA          = <See RFC 5234>



Gudmundsson & Hoenes      Expires July 1, 2010                  [Page 9]


Internet-Draft          SRV Prefix Clarifications          December 2009


      DIGIT          = <See RFC 5234>

   Note:  In case the <service-name> rule turns out to be in conflict
      with RFC yyyy [RFCyyyy], the latter has precedence.

   The length restriction is there to support use of Service Names in
   other contexts than SRV Service Labels (which, as all DNS labels, can
   be 63 characters long).  The other restrictions assure that Service
   Names cannot be confused with numbers (e.g., port numbers) and follow
   the common restrictions for domain labels that prohibit conflicts
   with domain name internationalization efforts.

   Appendix A offers a scheme for "Extended SRV Service Labels" that can
   be adopted by service specifications that cannot contend with these
   restrictions, and which seek for a versatile naming scheme not
   violating the provisions of [RFCyyyy].


5.  Service Discovery Client Considerations

   Implementations making use of dynamic service discovery based on DNS
   SRV records for a particular application/service will construct a
   prioritized list of applicable Service Prefixes, following the
   guidelines in the two subsections below.

   To form the QNAME(s) for DNS SRV lookup, each Service Prefix is
   concatenated (with a period as the label separator character) to the
   FQDN of the Service Domain the application is interested in.

   Depending on application strategy and perhaps local policy
   (configuration), the DNS queries with QCLASS=IN and QTYPE=SRV can be
   performed serially or in parallel -- to decrease the latency in the
   case higher priority queries do not succeed in finding matching SRV
   record(s).

   The answers obtained are processed as specified in RFC 2782
   [RFC2782], subject to the preferences of the service client for
   transport and/or "substrate" protocols.  If necessary, the Target
   domain names obtained are then queried for address records (i.e., at
   the time of this writing, A and/or AAAA RRs) to determine the network
   layer addresses to be contacted over the corresponding transport
   protocol using the port number contained in the 'Port' element of the
   respective SRV record.

   Note:  RFC 2782 [RFC2782] on page 7 imprecisely indicates the client
      "[SHOULD] ... try to connect to the (protocol, address, service)"
      tuple.  Since at the transport layer the port number needs to be
      used, not the service (name?), and to let the order of the tuple



Gudmundsson & Hoenes      Expires July 1, 2010                 [Page 10]


Internet-Draft          SRV Prefix Clarifications          December 2009


      components follow the protocol layers, it should refer to
      "(address, protocol, port)" tuples.

5.1.  Protocol Label Selection

   Some services are defined to operate over only one transport
   protocol.  In this case the application MUST use the appropriate
   transport label in forming the Service Prefix for SRV record lookup.

   If a service can operate over multiple transport protocols, then the
   specification of the service might indicate an order of preference,
   or local policy may supply it.  Any service can provide a specific
   order in the Notes section of the "Service Names and Port Numbers"
   registry, during registration or via registration update [RFCyyyy].
   Absent such information, the following priority order SHOULD be used
   as appropriate, based on what transports are defined and registered
   for the service, and supported by the client: _udp, _tcp, _sctp,
   _dccp.

5.2.  Service Label Selection

   Absent service specific documentation saying otherwise or hints
   available to the client (e.g., by configuration), the following
   recommendations SHOULD be followed.

   If an application/service has a single registered Service Name, a
   prospective client uses the Standard Service Label derived from it
   according to Section 4.

   Contrary to the strong recommendation in RFC 2782 [RFC2782], several
   legacy services have been assigned more than one Service Name in the
   past.  For instance, the well-know "systat" service is also referred
   to as "users" service, the DNS service, "domain", is also referred to
   as "nameserver" or "dns", "rlp" is also denoted as "resource", the
   WhoIs service is identified by "whois" and "nicname", the web service
   uses "http" or "www", "kerberos" is also indicated by "kdc", and the
   PCMail service has been assigned the equivalent Service Names
   "pcmail-srv" and "pcmail".
   In all these cases, the "Service Names and Port Numbers" registry
   will clearly indicate which name is the primary one and which names
   are considered aliases.
   Unless a prospective client has specific hints available (e.g., by
   configuration) indicating that a specific alias name ought to be
   tried preferentially, the primary Service Name SHOULD be used, and it
   also SHOULD be tried if the lookup of an alias name fails.

   If a service/application supports different well marked instances
   identified by different Service Names or a related specification has



Gudmundsson & Hoenes      Expires July 1, 2010                 [Page 11]


Internet-Draft          SRV Prefix Clarifications          December 2009


   introduced the usage of extended Service Labels for discovery of this
   service (e.g., making use of the scheme specified in Appendix A), the
   specifications SHOULD always also define a single default service
   instance, and hence a default Service Label or Service Name (that can
   be used to construct the the corresponding Standard Service Label).
   Prospective clients MAY follow any service instance selection policy
   desired (by implementation, deployment, or configuration), but SHOULD
   be prepared to fall back to the default service instance if the SRV
   record lookup for preferred service instance(s) fails.


6.  Provisioning of SRV records

   DNS zone administrators SHOULD support (and encourage) the
   provisioning of SRV records related to the basic domains they manage.
   Dynamic DNS Update ([RFC2136], [RFC3007]) is an option, but this is
   out of scope for this document.

   The structure of SRV owner names makes it possible (but not
   necessary) to delegate the per-protocol subdomains (given by the
   defined Protocol Labels) related to a Service Domain.  If delegated,
   because various services are offered over different protocols,
   preferably all the subdomains SHOULD be served within the same
   administrative domain (or even on the same authoritiaive servers),
   thereby simplifying administrative procedures for the maintenance of
   the SRV records.

   For services with alias names available as well, DNS zone managers
   SHOULD strongly encourage the use of the primary Service Names for
   the formation of the SRV Service Labels.  Applications registering
   SRV names in the DNS SHOULD always If Service Prefixes based on
   "nicknames" are wanted, for consistency and maintenance reasons it is
   RECOMMENDED that CNAME records be placed at the corresponding owner
   names instead of SRV records, thus redirecting DNS lookups to a
   single SRV RRset bound to the primary Service Name.

   [RFC2782] goes at considerable length to explain why SRV RRs are not
   suitable for short-term load balancing purposes, and that therefore
   SRV records can have reasonably long TTL values.

   The combination of 'Priority' and 'Weight' in SRV RRs has proven
   ardous to make proper use of, and inconsistent client behavior makes
   it unlikely that hypothetical strategies for fine-tuned load
   distribution can be achieved in practice by populating a two-
   dimensional variety of (Priority, Weight) tuples in any SRV RRset.
   Experience has shown that fixing a 'standard' value for 'Priority'
   and varying only the 'Weight' values is much more likely to influence
   client behavior in a deterministic way.



Gudmundsson & Hoenes      Expires July 1, 2010                 [Page 12]


Internet-Draft          SRV Prefix Clarifications          December 2009


   Note:  The SRV 'Target' is an FQDN, not an IP address.  In the past,
      there have been attempts to encourage the use of IP addresses for
      'Target', but that is not possible.  Some implementations have
      been observed to accept an IPv4 address for 'Target' and store it
      as a 4-label domain name, causing the trailing label to become
      numeric, which is not allowed.


7.  Security Considerations

   This document does not have any specific security implications.
   However it is hoped that the more orderly, and more frequent use of
   SRV-based dynamic service discovery, based on the rules clarified in
   this documents and the establishment of a unified service registry,
   will provide valuable information for administrators and security
   policy makers, to the benefit of the overall security of the
   Internet.

   For the general security considerations of SRV resource records, see
   RFC 2782 [RFC2782].  The use of DNSSEC [RFC4033] to digitally sign
   zones publishing SRV records provides data integrity to the DNS
   lookup and prevents spoofing.

   All security considerations in RFC yyyy [RFCyyyy] related to port
   numbers apply to applications/protocols that use SRV based service
   discovery rather than assigned (server) port numbers.


8.  IANA Considerations

   This document has no IANA actions.


9.  References

9.1.  Normative References

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

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

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFCyyyy]  Cotton, M., Eggert, L., Mankin, A., Touch, J., and M.



Gudmundsson & Hoenes      Expires July 1, 2010                 [Page 13]


Internet-Draft          SRV Prefix Clarifications          December 2009


              Westerlund, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry",
              draft-ietf-tsvwg-iana-ports-04 (work in progress),
              December 2009.

9.2.  Informative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC2052]  Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
              location of services (DNS SRV)", RFC 2052, October 1996.

   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, April 1997.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, November 2000.

   [RFC3232]  Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
              an On-line Database", RFC 3232, January 2002.

   [RFC3828]  Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
              G. Fairhurst, "The Lightweight User Datagram Protocol
              (UDP-Lite)", RFC 3828, July 2004.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340, March 2006.

   [RFC4614]  Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap
              for Transmission Control Protocol (TCP) Specification
              Documents", RFC 4614, September 2006.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC5237]  Arkko, J. and S. Bradner, "IANA Allocation Guidelines for
              the Protocol Field", BCP 37, RFC 5237, February 2008.




Gudmundsson & Hoenes      Expires July 1, 2010                 [Page 14]


Internet-Draft          SRV Prefix Clarifications          December 2009


   [RFC5507]  IAB, Faltstrom, P., Austein, R., and P. Koch, "Design
              Choices When Expanding the DNS", RFC 5507, April 2009.


Appendix A.  Extended SRV Service Labels

   This non-normative Section defines a versatile extension scheme for
   SRV Service Labels that can be incorporated by reference in
   specifications of service discovery procedures for applications that
   cannot contend with Standard Service Labels as specified in
   Section 4.

A.1.  Motivation and Solution Space

   Sections 2 and 4 identify scenarios of applications/services that
   might reasonably wish to use an extended scheme for forming their
   Service Labels, in particular to identify protocol layers
   (encapsulation layers, "substrate" protocols) stacked between the
   transport protocol and the application protocol itself, without
   having to register a multitude of Service Names in the "Service Names
   and Port Numbers" registry and hence being bound to the 15-character
   name size limit.  Other scenarios with similar requirements have been
   mentioned in recent work-in-progress in the IETF.

   For being useful, a scheme for extended Service Labels must allow (a)
   to easily determine that a label obeys to this scheme and (b) to
   unambiguously extract the underlying Service Name and the added
   extension components (henceforth: Qualifiers) from the full label,
   whereas at the same time the scheme needs to ensure that it does not
   pollute the name space of Service Names and that thereby the
   uniqueness of registered Service Names is not disturbed.

   As restated in Section 4, the syntax of Service Names from [RFCyyyy]
   does not allow the underscore ("_") character, which in turn already
   is used as a prefix character for SRV Service and Protocol Labels
   serving to distinguish these labels from 'ordinary' domain name
   components.  Therefore, a manifest method to construct extended
   Service Labels is to concatenate the given Service Name and
   Qualifiers, prepending each component by an underscore character.

A.2.  Specification

   Thus, we arrive at the following syntax for Extended Service Labels,
   extending the ABNF from Section 4:







Gudmundsson & Hoenes      Expires July 1, 2010                 [Page 15]


Internet-Draft          SRV Prefix Clarifications          December 2009


         serv-label     =/ ext-serv-label

         ext-serv-label = USC service-name 1*( USC serv-qualifier )
                          ; total size limited to 63 characters

         serv-qualifier = 1*(l-d-h)
                          ; also conforming to the <token> rule

   Hypothetical example:
      Assume an application with registered Service Name "foohoo" for
      transport over SCTP is served for the domain "ext.example".  Also
      assume that this service needs to be qualified by the keywords
      (service qualifiers) (1) "barbar" and (2) "aanne".
      Then the corresponding Extended SRV Service Label will be:

         _fooho_barbar_aanne

      and the full SRV owner name will be:

         _fooho_barbar_aanne._sctp.ext.example

   Application designers who want to make use of this scheme need to
   precisely document the <serv-qualifier> values supported and refer
   normatively to this section.  Any such specification SHOULD indicate
   a mandatory-to-implement default form of the service that will be
   represented by the Standard Service Label for this service, per
   Section 4.  This allows for an easy fallback strategy for clients of
   such service that are not interested in particular variants of the
   service, or when the service variant preferred by the client is not
   offered at a particular Service Domain and hence not represented by
   an SRV record in the DNS.
   Absent such application-specific documentation, always the Standard
   Service Labels specified in Section 4 are used.

A.3.  Applicability

   Each application/service making use of this mechanism inherits from
   its registered Service Name a distinct namespace, and its designers
   must manage this 'private' namespace of valid Extended Service Labels
   according to their needs.  For instance, there is no central IANA
   registry for such namespaces.  The application is still identified by
   its Service Name, and the related leading standard Service Label part
   is to be used for policy decisions.

   If the service qualifiers are used to indicate intermediate layers,
   the application-specific service discovery specification SHOULD
   specify that the qualifiers be given in protocol stacking order; if
   substrate protocols used have their own registered Service Name, it



Gudmundsson & Hoenes      Expires July 1, 2010                 [Page 16]


Internet-Draft          SRV Prefix Clarifications          December 2009


   is strongly RECOMMENDED that these Service Names be used to identify
   the corresponding qualifiers.

   The companion document [TBD] contains examples of legacy use cases
   specified in the IETF that preferably should migrate to this scheme
   and thereby, it instantiates these recommendations.


Authors' Addresses

   Olafur Gudmundsson
   Shinkuro Inc.
   4922 Fairmont Avenue, Suite 250
   Bethesda, MD  20814
   USA

   Email: ogud@ogud.com


   Alfred Hoenes
   TR-Sys
   Gerlinger Str. 12
   Ditzingen  D-71254
   Germany

   Email: ah@TR-Sys.de

























Gudmundsson & Hoenes      Expires July 1, 2010                 [Page 17]