DNS Extensions O. Gudmundsson Internet-Draft Shinkuro Inc. Updates: 2782 (if approved) A. Hoenes Intended status: Standards Track TR-Sys Expires: April 25, 2011 October 22, 2010 DNS SRV Usage Guidelines and Owner Name Recommendations draft-gudmundsson-dnsext-srv-clarify-02 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 "Service Name and Transport Protocol Port Number" registry and provides a few other corrections, clarifications, and usage recommendations. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 25, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Gudmundsson & Hoenes Expires April 25, 2011 [Page 1] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Synopsis of RFC 2782 . . . . . . . . . . . . . . . . . . . 3 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.3. Objective for this Document and its Companions . . . . . . 5 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2. General Considerations for SRV Service Prefixes . . . . . . . 7 3. Protocol Labels . . . . . . . . . . . . . . . . . . . . . . . 9 4. Standard Service Labels . . . . . . . . . . . . . . . . . . . 10 5. Service Discovery Client Considerations . . . . . . . . . . . 12 5.1. Protocol Label Selection . . . . . . . . . . . . . . . . . 13 5.2. Service Label Selection . . . . . . . . . . . . . . . . . 13 6. Provisioning of SRV records . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 Appendix A. Extended SRV Service Labels . . . . . . . . . . . . . 17 A.1. Motivation and Solution Space . . . . . . . . . . . . . . 18 A.2. Specification . . . . . . . . . . . . . . . . . . . . . . 18 A.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Gudmundsson & Hoenes Expires April 25, 2011 [Page 2] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 1. Introduction 1.1. Synopsis of RFC 2782 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.2. 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, and therefore this has mislead authors of specifications and implementers and users of service discovery: 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 Gudmundsson & Hoenes Expires April 25, 2011 [Page 3] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 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" IANA registries, respectively. The corresponding sections in the last edition of STD 2 [RFC1700] were "Assigned Internet Protocol Numbers" (pp. 8-10), "Well Known Port Numbers" (pp. 16-39) and "Registered Port Numbers" (pp. 39-55). But IANA also maintains the "Protocol and Service Names" registry (with file name "service-names"), dedicated to the "Official Protocol Names as these appear in the Domain Name System WKS records and the {legacy} NIC Host Table", and pointing to RFC 952 [RFC0952] for the description of use. (Note that WKS records contain a protocol-specific bit map of "Well Known Services" offered at a host. The protocol and service names in that registry are used in the presentation form of WKS records and translated by DNS servers to protocol numbers and bit positions for the well-known ports of the services; the reverse translation is also applied in DNS software where WKS RR presentation format is generated. The WKS record format worked pretty well when well- known ports were limited to the range up to 255, but long after the publication of the DNS Standards, that range has been expanded by one of the predecessors of RFC 1700, RFC 1340 [RFC1340] to up to 1023, which made WKS records much less practical -- see [Clnup].) Since this registry unabashedly mixes names for protocols and services and should only contain entries for applications that have been assigned a well-known (system) port number, it should be clear that this registry could not have been in mind at the time RFC 2782 has been written. However, anecdotal evidence has shown that this wasn't actually clear to all parties all over the years. As SRV records contain the port number where each server provides the service, the outmost utility of SRV RRs is for services that do not have a registered port number. (Services offered at a port number different from the registered default port number or multiple instances of a service offered at different port numbers are the next most important use cases.) Further, the number of ports available is small compared to the possible number of service names that could be registered, and so the set of services that can make use of SRV based service discovery is potentially much larger than the set of services with assigned port numbers. Therefore, the "Port Number" registry needed a more strict registration policy and is not the proper place for registering service names for use with SRV resource records. Gudmundsson & Hoenes Expires April 25, 2011 [Page 4] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 o On the other hand, having locally defined lists of service and/or protocol names (as suggested by the text of RFC 2782) 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 motive for the deployment of the Domain Name System. Therefore, locally defined lists are not suitable sources for the names appearing in the Service Prefix of SRV owner names -- at least for services offered for larger than local scope. 1.3. 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 Name and Transport Protocol Port Numbers" registry [I-D.ietf-tsvwg-iana-ports] where all service registrations will take place in the future. [[ RFC-Editor: Please replace (throughout the entire document) 'yyyy' by the RFC number assigned to Ref. [I-D.ietf-tsvwg-iana-ports] wherever "RFC yyyy" is used as a shorthand for that document. ]] This document updates RFC 2782 [RFC2782] in clarifying how to use the registrations in that registry and other elements to construct standard 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. Additionally, usage considerations for SRV based service lookup and the provisioning of SRV records are presented, based on experience gained since the publication of RFC 2782. A companion document of this one, "Service Registration Fixes" [Clnup], collects from various RFCs and IANA documents registrations that ought be in the "Service Name and Transport Protocol Port Number" registry, and it 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 [I-D.ietf-tsvwg-iana-ports] and this document. These recommendations include the option to make use of the extension scheme suggested in the Appendix. Gudmundsson & Hoenes Expires April 25, 2011 [Page 5] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 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.4. 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 IANA "Service Name and Transport Protocol Port Number" registry [I-D.ietf-tsvwg-iana-ports]. See Section 4 for details. Note: Traditionally, this term has been used only for the symbolic names assigned to "Well Known Ports" (aka "Assigned Port" or "System Ports") in the IANA "Protocol and Service Names" registry in support of the "NIC Hosts Table" (RFC 810 [RFC0810] and its successor, RFC 952 [RFC0952]) and the DNS WKS resource record [RFC1035]; this has been done so in all "Assigned Numbers" RFCs since RFC 900 ( [RFC0900], [RFC0923], [RFC0943], [RFC0960], [RFC0990], [RFC1010], [RFC1060], [RFC1340], [RFC1700]); RFC 1060 has used this term in the sense we use it now, but restricted to the "Unix Standard services"; later RFCs have used the term "keyword" and "short name" for this purpose; [I-D.ietf-tsvwg-iana-ports] re-establishes and expands the general use of this term. 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. Gudmundsson & Hoenes Expires April 25, 2011 [Page 6] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 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 (righthand) label of the Service Prefix. It indicates the transport protocol to which the 'Port' element of the SRV RDATA serves as the demultiplexer value. See Section 3 for details. Service Label (or: SRV Service Label) The more specific, second 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, as specified in RFC 2782 [RFC2782]. NOTE: There are cases where (in practice or under consideration) additional labels are prepended. The extension scheme in Appendix A is offered as a guideline for an alternative to such multi-level hierachical Service Labels that conforms to the general rules. But since this extension proposal is currently non-normative, we cannot reasonably ban present use with a "MUST" in place of the "SHOULD" above. 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 before trying to contact the service at its assigned port number (if any). Gudmundsson & Hoenes Expires April 25, 2011 [Page 7] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 Some services can be carried equivalently in different encapsulations using higher-level "substrate" protocols like HTTP, BEEP, SOAP, SIP, or 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. This is likely to happen during the introduction of new transport schemes for an application. When generic middleware layers are used, there commonly is no practical method to let such plug-in middleware layers chose among them based on packet content, or to perform a negotiation of the particular substrate protocol. 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. Within the semantics of the tree-oriented naming scheme used in the DNS, there are two possibilities to achieve this goal for a particular application: 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 Name and Transport Protocol Port Number" registry [I-D.ietf-tsvwg-iana-ports], 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 RFC yyyy [I-D.ietf-tsvwg-iana-ports] (15 characters, see Section 4). Also, RFC yyyy 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 RFC yyyy. 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 more important, an extension scheme is needed for the construction of longer, more- specific Service Labels for such exceptional services. Gudmundsson & Hoenes Expires April 25, 2011 [Page 8] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 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 RFC yyyy [I-D.ietf-tsvwg-iana-ports]. 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 IANA "Service Name and Transport Protocol Port Number" registry, following the registration procedures of [I-D.ietf-tsvwg-iana-ports]. 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 it 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. 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 Name and Transport Protocol Port Number" registry as specified in [I-D.ietf-tsvwg-iana-ports] or by future IESG-endorsed amendments to that registry. Gudmundsson & Hoenes Expires April 25, 2011 [Page 9] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 Like 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 Name and Transport Protocol Port Number" registry [I-D.ietf-tsvwg-iana-ports] 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. In practice, this makes it impossible to define and support SRV-based service discovery for applications/services that can be carried over either UDP or UDP-lite, since both variants would have to be reperesented by SRV records at the same node in the DNS database, with no means to distinguish between the different transport protocols inside the SRV RRs. Arguably, this raises another obstacle to the deployment and use of UDP-lite and makes a smoth migration from UDP to UDP-lite almost impossible. 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 Service 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 protocol registered in the IANA "Service Name and Transport Protocol Port Number" registry [I-D.ietf-tsvwg-iana-ports]. 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 Name and Transport Protocol Port Number" registry). Gudmundsson & Hoenes Expires April 25, 2011 [Page 10] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 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. Like all domain name labels, SRV Service Labels are matched in a case-insensitive manner. [I-D.ietf-tsvwg-iana-ports] 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 ("-"); - there MUST be at least one letter in a Service Name; - 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 rule below token = *(1*DIGIT [HYPHEN]) 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 = ; A-Z, a-z DIGIT = ; 0-9 Note: In case the rule turns out to be in conflict with RFC yyyy [I-D.ietf-tsvwg-iana-ports], the latter has precedence. However, in the -07 draft version of [I-D.ietf-tsvwg-iana-ports], the formal syntax definition (ABNF) does not agree with the prose; for clarity, a consistent version of the ABNF is presented above, which is expected to be in the next version of that I-D as well. Gudmundsson & Hoenes Expires April 25, 2011 [Page 11] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 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 octets long). The other restrictions assure that Service Names cannot be confused with numbers (e.g., port numbers) or port range notation (like nn-mmm) and that they 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 [I-D.ietf-tsvwg-iana-ports]. 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. Update to RFC 2782: 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 components follow the protocol layers, it should refer to "(address, protocol, port)" tuples. Gudmundsson & Hoenes Expires April 25, 2011 [Page 12] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 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 column of the IANA "Service Name and Transport Protocol Port Number" registry entry, during registration or via registration update [I-D.ietf-tsvwg-iana-ports]. Absent such information, the following priority order SHOULD be used as appropriate, based on which transports are defined and registered for the service, and which are 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 Name and Transport Protocol Port Number" registry will clearly indicate (in the Notes column of the registry entries) which name is the primary one and which names are considered aliases, including pointers from the entries for alias Service Names to the entry of the primary Service Name. 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. Gudmundsson & Hoenes Expires April 25, 2011 [Page 13] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 If a service/application supports different well marked instances identified by different Service Names or a related specification has 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 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 use the primay Service Name. 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. Gudmundsson & Hoenes Expires April 25, 2011 [Page 14] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 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. 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 (top-level) 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 [I-D.ietf-tsvwg-iana-ports] 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 [I-D.ietf-tsvwg-iana-ports] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", draft-ietf-tsvwg-iana-ports-07 (work in progress), October 2010. Gudmundsson & Hoenes Expires April 25, 2011 [Page 15] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 [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. 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. [RFC0810] Feinler, E., Harrenstien, K., Su, Z., and V. White, "DoD Internet host table specification", RFC 810, March 1982. [RFC0900] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 900, June 1984. [RFC0923] Reynolds, J. and J. Postel, "Assigned numbers", RFC 923, October 1984. [RFC0943] Reynolds, J. and J. Postel, "Assigned numbers", RFC 943, April 1985. [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985. [RFC0960] Reynolds, J. and J. Postel, "Assigned numbers", RFC 960, December 1985. [RFC0990] Reynolds, J. and J. Postel, "Assigned numbers", RFC 990, November 1986. [RFC1010] Reynolds, J. and J. Postel, "Assigned numbers", RFC 1010, May 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1060] Reynolds, J. and J. Postel, "Assigned numbers", RFC 1060, March 1990. Gudmundsson & Hoenes Expires April 25, 2011 [Page 16] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 [RFC1340] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1340, July 1992. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [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. [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 Gudmundsson & Hoenes Expires April 25, 2011 [Page 17] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 specifications of service discovery procedures for applications that cannot contend with Standard Service Labels as specified in Section 4. This way, the specification below becomes normative for these (and only these) particular applications/services. 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 [I-D.ietf-tsvwg-iana-ports] does not allow the underscore ("_") character, which in turn already is used as a prefix character for SRV Service and Protocol Labels, where it serves 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: 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 rule Gudmundsson & Hoenes Expires April 25, 2011 [Page 18] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 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 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 is strongly RECOMMENDED that these Service Names be used to identify the corresponding qualifiers. The companion document [Clnup] contains examples of legacy use cases specified in the IETF that preferably should migrate to this scheme and thereby, it instantiates these recommendations. Gudmundsson & Hoenes Expires April 25, 2011 [Page 19] Internet-Draft SRV Guidelines & Prefix Recommendations October 2010 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 April 25, 2011 [Page 20]