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]