Network Working Group O. Gudmundsson Internet-Draft Shinkuro Inc. Intended status: Standards Track A. Hoenes Expires: April 29, 2010 TR-Sys October 26, 2009 Creation of a Registry for DNS SRV Record Service Prefixes draft-gudmundsson-dns-srv-iana-registry-04 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 April 29, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The DNS SRV record has been specified in RFC 2052 and RFC 2782. These two RFCs did not specify an IANA registry for names of the Gudmundsson & Hoenes Expires April 29, 2010 [Page 1] Internet-Draft IANA SRV registry October 2009 services using SRV records as defined by various protocols. This document creates such a registry and populates it. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. SRV Service Prefix Registry Considerations . . . . . . . . . . 5 2.1. To _ or Not To _ . . . . . . . . . . . . . . . . . . . . . 5 2.2. Service Name Maintenance . . . . . . . . . . . . . . . . . 5 2.3. Name Collisions in Service Registrations . . . . . . . . . 5 3. SRV Protocol Labels . . . . . . . . . . . . . . . . . . . . . 6 4. SRV Service Labels . . . . . . . . . . . . . . . . . . . . . . 7 4.1. SRV Service Prefix Registration Template . . . . . . . . . 7 4.2. Initial SRV Service Labels Registry Contents . . . . . . . 7 4.3. RFC Examples and Pointers . . . . . . . . . . . . . . . . 9 5. Relationship to Other IANA Registries . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Gudmundsson & Hoenes Expires April 29, 2010 [Page 2] Internet-Draft IANA SRV registry October 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 naming structure for its use, is as follows [RFC2782]: _Service._Proto.Name SRV Priority Weight Port Target The "_Service" label indicates the name of the Service/Application that is being offered. The "_Proto" label denotes the name of the transport protocol to be used for the service. "Name" is the domain name that is offering the service. The PORT field is the port number over which the service is provided at the Target name. The Priority and Weight fields are used for selecting among multiple SRV records at the same owner name. RFC 2782 says that the source of names for "Service" and "Proto" is "Assigned Numbers" (STD2) or a locally defined repository. Note: 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" IANA registries. However, upon reflection, both alternatives do not seem to make particular sense: o 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. Gudmundsson & Hoenes Expires April 29, 2010 [Page 3] Internet-Draft IANA SRV registry October 2009 o Having locally defined lists of Service and/or Proto 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 should be 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. For these reasons, this document creates a separate IANA registry for Services that allow or specify service discovery via SRV look-up. Note: A couple of RFCs published in the past pretend to have registered with IANA particular SRV Service/Protocol combinations, but at the time of this writing, evidence shows that this did not happen actually. Section 4.2 tries to collect this past wisdom to initiallly populate the new registry. This Service Registry explicitly removes the constraint that services need a port number registration. The registration requirement for this new registry is set low in order to make it relatively easy to register a new service name. To a large extent, the requirement to register port numbers can be eliminated by encouraging SRV for service discovery and location in all new application protocols. For this reason, there ought not be a name conflict between what is registered in the SRV registry defined in this document and the legacy service names in the port numbers registry. See Section 2.3 for elaborations on such name conflicts. In the spirit of BCP 17, RFC 2219 [RFC2219], this registry should also help providing an orderly substitute for the poorly specified Well-Known Network Service Alias names. Note: RFC 5507 [RFC5507], discusses the use of "underscore labels" in the DNS more generally, from the architectural point of view of the IAB. 1.1. 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] . Gudmundsson & Hoenes Expires April 29, 2010 [Page 4] Internet-Draft IANA SRV registry October 2009 2. SRV Service Prefix Registry Considerations Registering a new service should be easy and painless process; all that is needed is a pointer to a service description. In some cases, applicants may not want to release the service/protocol specification, and that is fine. 2.1. To _ or Not To _ The original SRV RFC used regular DNS names for service and transport names. This was shown to cause some name conflicts. For example, it is impossible to have the name "TCP" delegation and also provide a service on http.tcp. For this reason, the current SRV RFC specifies the use of underscore in front of all names for both protocols and services. The argument for following this nomenclature for protocols is clear and needed. On the other hand, having a full DNS name space created on the left of each protocol name, the argument for name collision in the services does not apply. Arguments that the presence of the underscore character makes it easier to spot that this is a service are not convincing. A possible future extension to allow IDN Service names may only work if the underscore prefix is not used. 2.2. Service Name Maintenance As Service names are a DNS label, the strings can be up to 63 octets long. This is a large enough space that reuse and reclaiming of names is not an issue, unlike for the port space. However, applicants (or their provably legitimate successors) can later request updates to the contact information and/or references, and anyone can add another protocol for an existing service, based on additional specification. Such requests, when sent to IANA, must clearly be marked as change requests. 2.3. Name Collisions in Service Registrations As this document allows registrations of NEW services without the underscore ("_") prefix, these registrations MUST NOT collide with pre-existing registrations that start with or without the underscore prefix. A name collision is defined to occur if two labels compare equal under case-insensitive comparison after stripping of the underscore prefix (if any) from both. In registering a new name in the SRV registry there MUST not be a name conflict with the "PORT NUMBERS" registry keyword field. Gudmundsson & Hoenes Expires April 29, 2010 [Page 5] Internet-Draft IANA SRV registry October 2009 New registraions in the "PORT NUMBERS" MUST NOT create a name confict with the SRV registry. 3. SRV Protocol Labels This section contains the known Protocol identifiers to be entered into the SRV Protocol Labels sub-registry. First, the IETF-specified transport protocols are listed, with the common labels also appearing in the IANA "Protocols" registry. In a number of RFCs there have been examples where services/protocols are defined to work over "Overlay" (or "Substrate") protocols such as xmpp and http. These are added next. Table 1 lists the labels assigned to IETF standardized transport protocols, and those specified for other substrate protocols in existing RFCs published before this document. It represents the initial contents of the SRV Protocol Labels sub-registry. +---------------------+--------------------+ | Protocol | References | +---------------------+--------------------+ | Transport protocols | | | _tcp | RFC 793 [RFC0793] | | _udp | RFC 768 [RFC0768] | | _dccp | RFC 4340 [RFC4340] | | _sctp | RFC 4960 [RFC4960] | | Overlay protocols | | | _http | RFC 4386 [RFC4386] | | _ipv6 | RFC 5026 [RFC5026] | | _ldap | RFC 4386 [RFC4386] | | _sip | RFC 5509 [RFC5509] | | _ocsp | RFC 4386 [RFC4386] | | _xmpp | RFC 3921 [RFC3921] | +---------------------+--------------------+ Table 1 NOTE #1: For the purpose of the _Protocol labels and this registry, UDP-Lite [RFC3828] is treated as indistinguishable from UDP [RFC0768]. NOTE #2: There have been a few underscore protocol labels defined for use by specific mail service databases such as "_domainkey" and "_vouch"; these are not registered anywhere. The related specifications do not employ SRV RRs however; therefore these labels Gudmundsson & Hoenes Expires April 29, 2010 [Page 6] Internet-Draft IANA SRV registry October 2009 are currently regarded as out of scope. It would be possible to register these in the registry above as RESERVED labels, to capture their use and avoid label collisions, if that is deemed useful. 4. SRV Service Labels 4.1. SRV Service Prefix Registration Template Submit registrations to TDB@TDB [[ RFC Editor Note: final email address to be supplied by IANA! ]] Registration of SRV Service Prefix a. Kind of request: (new) or (update) b. Registrant name: c. Organization: d. Contact e-mail and international phone number: e. Name of Service: f. Protocol(s) used: g. Reference to document(s) defining the service, (optional): h. Short Service description (optional): i. Delay publication: Y/N IANA will archive the accepted templates and make them available via links in the registry. IANA will accept and act upon applications for service identifiers, provided there is no Service name collision within the SRV Service Prefixes registry or with the Port Numbers registry. The publication of such assignments can be deferred up to 30 days from the receipt of the application. Please specify if delay is requested. 4.2. Initial SRV Service Labels Registry Contents This section is expected to contain the most common service labels defined in the IETF that are in use with and without underscore prefix. It is expected that the template above will be used to register other service labels that are in common use. Table 2 specifies the initial contents of the SRV Service Labels sub- registry. This list is based on DNS server logs from September 2008 and strings found in RFCs (published before September 2009). Gudmundsson & Hoenes Expires April 29, 2010 [Page 7] Internet-Draft IANA SRV registry October 2009 +-----------------+---------------------+--------------------+ | Service label | Protocol(s) defined | Reference(s): | +-----------------+---------------------+--------------------+ | _apex-edge | _tcp | RFC 3340 | | _apex-mesh | _tcp | RFC 3340 | | _beep | _tcp | RFC 3620 | | _capwap-control | _upd | RFC 5415 | | _certificates | _tcp | RFC 4387 | | _crls | _tcp | RFC 4387 | | _diameter | _tcp, _sctp | RFC 3588 | | _dns-llq-tls | _tcp | | | _dns-sd | _upd | | | _dns-update | _upd | | | _dvbservdsc | _udp, _tcp | RFC 5328 | | _im | _xmpp, _sip | RFC 3921, RFC 5509 | | _iris-lwz | _udp | RFC 3981 | | _jabber | _tcp | | | _kerberos | _upd, _tcp | RFC 4120 | | _ldap | _tcp | RFC 3088 | | _mihcs | _upd, _tcp , _scp | RFC 5679 | | _mihes | _upd, _tcp , _scp | RFC 5679 | | _mihis | _upd, _tcp , _scp | RFC 5679 | | _mip6 | _ipv6 | RFC 5026, RFC 5555 | | _msrps | _tcp | RFC 4976 | | _mtqp | _tcp | RFC 3887 | | _pkixrep | _http, _ldap, _ocsp | RFC 4386 | | _pres | _xmpp, _sip | RFC 3921, RFC 5509 | | _pgp | _tcp | RFC 4387 | | _pgprevocations | _tcp | RFC 4387 | | _rwhois | _tcp | RFC 2167 | | _soap-beep | _tcp | RFC 3288, RFC 4227 | | _sip | _udp, _tcp, _sctp | RFC 3263, RFC 4168 | | _sips | _tcp, _sctp | RFC 3263, RFC 4168 | | _sipfederation | _tcp | | | _slpda | _udp, _tcp | RFC 3832 | | _stun | _udp, _tcp | RFC 4389 | | _stuns | _tcp | RFC 4389 | | _syslog | _tcp | RFC 3195 | | _tunnel | _tcp | RFC 3620 | | _xmlrpc-beep | _tcp | RFC 3529 | | _xmpp | _tcp | RFC 3921 | | _xmpp-client | _tcp | RFC 3920 | | _xmpp-server | _tcp | RFC 3920 | +-----------------+---------------------+--------------------+ Table 2 Gudmundsson & Hoenes Expires April 29, 2010 [Page 8] Internet-Draft IANA SRV registry October 2009 4.3. RFC Examples and Pointers There are a few instances where RFCs have what looks like SRV label names but are just examples and should not be registered. This section for completeness contains any such instances the editors are aware off. o _iris-* RFC 3981 appendix A o _mail RFC 4985 o _ntp RFC 4085 o _pigen RFC 3091 o _telnet RFC 3620 o _ssh RFC 4592 There are a few instances where RFCs hint at external SRV usage/names but the editors have not been able to track down the documents. o RFC 4123 says: ITU-T H.323 Annex O also defines SRV use. o RFC 4280 points to 3GPP specs defining use(s?) of SRV. 5. Relationship to Other IANA Registries The SRV Service Labels registry is not a replacement for the two, more specific registries established by RFC 3861 [RFC3861], the "Instant Messaging SRV Protocol Label Registry" currently located at and the "Presence SRV Protocol Label Registry" currently located at Currently, there is one registration ("_xmpp") in each of these registries, performed by RFC 3921 [RFC3921], and another, more recent registration ("_sip"), performed by RFC 5509 [RFC5509], and this is reflected above. To avoid service name collisions, future registrations in the above two registries should always be accompanied by registration updates for the SRV Service Prefix registry. The IANA "Public Key Infrastructure using X.509 (PKIX) Parameters" "PKIX SRV Protocol Labels" sub-registry currently filed at contains a single entry for the service label "_pkixrep" in combination with three protocols, based on RFC 4386 [RFC4386], which has been included in Table 2. Arguably, that sub-registry might be abandoned by a future update of [RFC4386], in favor of making use of the new, general- purpose registry defined in this document, since it fulfills all requirements posed in sections 2 amd 4 of that RFC. Gudmundsson & Hoenes Expires April 29, 2010 [Page 9] Internet-Draft IANA SRV registry October 2009 6. Security Considerations This draft creates a registry that should have been created a long time ago. This in its own does not have any security implications. However it is hoped that the registry will provide valuable information for administrators and security policy makers, to the benefit of the overall security community of the Internet. 7. IANA Considerations This document creates a new IANA registry with 2 sub-registries. The registry is named "DNS SRV Service Prefixes". The policy for creating new sub-registries is "IETF Review" [RFC5226]. The first sub-registry is: "SRV Protocol Labels". Allocation policy is: "IETF Review" [RFC5226]. The initial content of this sub- registry is specified by Table 1 (Section 3). The second sub-registry is: "SRV Service Labels". Allocation policy is: "First Come First Served [RFC5226], but MUST NOT conflict with service names in the Port Number registry" (see Section 2.3). Rules for Labels to be registered are in Section 4. The initial content of the registry is specified by Table 2 (Section 4.2). A Template for subsequent registrations is in Section 4.1. IANA will archive and make available all accepted registrations via links from the registry. This document updates the allocation procedure of the PORT NUMBERS registry located at http://www.iana.org/assignments/port-numbers such that service names for new registrations MUST NOT conflict with names registered as "SRV Service Labels". 8. References 8.1. Normative References [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Gudmundsson & Hoenes Expires April 29, 2010 [Page 10] Internet-Draft IANA SRV registry October 2009 8.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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2219] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network Services", BCP 17, RFC 2219, October 1997. [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. [RFC3861] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004. [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4386] Boeyen, S. and P. Hallam-Baker, "Internet X.509 Public Key Infrastructure Repository Locator Service", RFC 4386, February 2006. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007. [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design Choices When Expanding the DNS", RFC 5507, April 2009. [RFC5509] Loreto, S., "Internet Assigned Numbers Authority (IANA) Gudmundsson & Hoenes Expires April 29, 2010 [Page 11] Internet-Draft IANA SRV registry October 2009 Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP)", RFC 5509, April 2009. 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 29, 2010 [Page 12]