Network Working Group O. Gudmundsson Internet-Draft OGUD Consulting LLC Expires: January 14, 2010 A. Hoenes TR-Sys July 13, 2009 Creation of a registry for DNS SRV record protocol names draft-gudmundsson-dns-srv-iana-registry-01 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 January 14, 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. Gudmundsson & Hoenes Expires January 14, 2010 [Page 1] Internet-Draft IANA SRV registry July 2009 Abstract The DNS SRV record was been specified in RFC 2052 and RFC 2782. These two RFCs did not specify an IANA registry for names of the protocols using SRV records. This document creates such a registry and populates it. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SRV registry considerations . . . . . . . . . . . . . . . . . 5 2.1. To _ or not to _ . . . . . . . . . . . . . . . . . . . . . 5 2.2. Name collisions in service registrations . . . . . . . . . 5 3. SRV Transport protocols . . . . . . . . . . . . . . . . . . . 6 4. SRV Service identifiers . . . . . . . . . . . . . . . . . . . 7 4.1. SRV Service identifiers registration template . . . . . . 7 4.2. SRV Service identifiers registry contents . . . . . . . . 7 4.3. Relationship to Other IANA Registries . . . . . . . . . . 10 5. Security considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Gudmundsson & Hoenes Expires January 14, 2010 [Page 2] Internet-Draft IANA SRV registry July 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 "_" 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: 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, and "Name" is the domain name that is offering the service. The PORT field is the port number the service is provide 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 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 out most 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. 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 Gudmundsson & Hoenes Expires January 14, 2010 [Page 3] Internet-Draft IANA SRV registry July 2009 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 and put it in 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 MUST NOT be a name conflict between what is registered in the SRV registry defined in this document and the port numbers registry. 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. 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 January 14, 2010 [Page 4] Internet-Draft IANA SRV registry July 2009 2. SRV registry considerations Registering a new service should be easy and a painless process, all that is needed is a pointer to a service description, but in some cases applicants may not want to release 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 "_" in front of all names for both transports and services. The argument for following this nomenclature for transports is clear and needed. On the other hand, having a full DNS name space created on the left of each transport name, the argument for name collision in the services does not apply. Arguments that the presence of the "_" character makes it easier to spot this is a service are not convincing. 2.2. Name collisions in service registrations As this document allows registrations of NEW services without the the "_" prefix, these registrations MUST NOT collide with pre-existing registrations that start with the prefix "_". Gudmundsson & Hoenes Expires January 14, 2010 [Page 5] Internet-Draft IANA SRV registry July 2009 3. SRV Transport protocols This section contains the known Transport protocol identifiers List of Transport protocols registered to be used with DNS SRV records. +---------------+--------------------+ | Protocol name | References | +---------------+--------------------+ | _tcp | RFC 793 [RFC0793] | | | | | _udp | RFC 768 [RFC0768] | | | | | _sctp | RFC 4960 [RFC4960] | +---------------+--------------------+ TODO: Are there other transports protocols defined Table 1 In number of RFC there have been examples where protocols are defined to work over "overlay" protocols such as xmpp and http. Should these be added to the table above or do the remain in a different table ? List of higher layer protocols registered to be used with DNS SRV records. +--------------+--------------------+ | Overlay name | References | +--------------+--------------------+ | _http | RFC 4386 [RFC4386] | | | | | _ipv6 | RFC 5026 [RFC5026] | | | | | _ldap | RFC 4386 [RFC4386] | | | | | _sip | RFC 5509 [RFC5509] | | | | | _ocsp | RFC 4386 [RFC4386] | | | | | _xmpp | RFC 3921 [RFC3921] | +--------------+--------------------+ TODO: are there other transport/overlay protocols that use SRV records? Table 2 Gudmundsson & Hoenes Expires January 14, 2010 [Page 6] Internet-Draft IANA SRV registry July 2009 4. SRV Service identifiers 4.1. SRV Service identifiers registration template Submit registrations to TDB@TDB Registration of SRV Service identifier a. Registrant name: b. Organization: c. Contact e-mail and international phone number: d. Name of Service: e. Transport used: f. Reference for implementing the service, (optional): g. Short Service description (optional): h. Delay publication: Y/N IANA will archive the accepted templates and make the available via links in the registry. IANA will accept and act upon applications for application identifiers. 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. SRV Service identifiers registry contents This section is expected to contain all known identifiers that are in use with and without "_" prefix. Registry format: +-----------------+---------------------+--------------------+ | Service name | Protocol name(s) | Reference(s): | +-----------------+---------------------+--------------------+ | _aaa | _tcp | RFC 3588 | | | | | | _apex-edge | _tcp | RFC 3340 | | | | | | _apex-mesh | _tcp | RFC 3340 | | | | | Gudmundsson & Hoenes Expires January 14, 2010 [Page 7] Internet-Draft IANA SRV registry July 2009 | _beep | _tcp | RFC 3620 | | | | | | _capwap-control | _upd | RFC 5415 | | | | | | _certificates | _tcp | RFC 4387 | | | | | | _crls | _tcp | RFC 4387 | | | | | | _dns-llq-tls | _tcp | | | | | | | _dns-sd | _upd | | | | | | | _dns-update | _upd | | | | | | | _dvbservdsc | _udp, _tcp | RFC 5328 | | | | | | _im | _xmpp, _sip | RFC 3921, RFC 5509 | | | | | | _iris-.* | _udp, _tcp | RFC 3981 | | | | | | _jabber | _tcp | | | | | | | _kerberos | _upd, _tcp | RFC 4120 | | | | | | _ldap | _tcp | RFC 3088 | | | | | | _mail | _tcp | RFC 4985 (?) | | | | | | _mip6 | _ipv6 | RFC 5026 | | | | | | _msrps | _tcp | RFC 4976 | | | | | | _mtqp | _tcp | RFC 3887 | | | | | | _ntp | _udp | RFC 4085 (?) | | | | | | _pigen | _udp, _tcp | RFC 3091 | | | | | | _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 | | | | | Gudmundsson & Hoenes Expires January 14, 2010 [Page 8] Internet-Draft IANA SRV registry July 2009 | _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 | | | | | | _ssh | _tcp | RFC 4592 (?) | | | | | | _stun | _udp, _tcp | RFC 4389 | | | | | | _stuns | _tcp | RFC 4389 | | | | | | _syslog | _tcp | RFC 3195 | | | | | | _telnet | _tcp | RFC 3620 | | | | | | _tunnel | _tcp | RFC 3620 | | | | | | _xmlrpc-beepp | _tcp | RFC 3529 | | | | | | _xmpp | _tcp | RFC 3921 | | | | | | _xmpp-client | _tcp | RFC 3920 | | | | | | _xmpp-server | _tcp | RFC 3920 | +-----------------+---------------------+--------------------+ List based on DNS server logs from September 2008 and strings found in RFCs (up to July 2009); missing Active Directory names; missing: Full list of Apple service names. Note: The iris- names need to be clarified. Table 3 Notes: o RFC 4123 says: ITU-T H3.23 Annex O also defines SRV use. o RFC 4280 points to 3GPP specs defining use(s?) of SRV. Gudmundsson & Hoenes Expires January 14, 2010 [Page 9] Internet-Draft IANA SRV registry July 2009 4.3. Relationship to Other IANA Registries Note: The SRV Service Identifiers 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 target="Presence SRV Protocol Label Registry" currently located at Currently, there is only one registration ("_xmpp") in each of these registries, performed by RFC 3921 [RFC3921], and this is reflected above. To avoid service name collisions, future registrations in the above two registries should always be accompanied by registrations in the SRV Service Name registry. Gudmundsson & Hoenes Expires January 14, 2010 [Page 10] Internet-Draft IANA SRV registry July 2009 5. Security considerations TDB Gudmundsson & Hoenes Expires January 14, 2010 [Page 11] Internet-Draft IANA SRV registry July 2009 6. IANA considerations This document creates a new IANA registry with 2 sub registries. The registry is named "DNS SRV protocol strings". Policy for creating sub-registries is "IETF consensus". First sub-registry is: "DNS SRV transport protocol names" Allocation policy is "IETF consensus" Initial Contents of the registry are in section 3. NOTE: Need to decide if Overlay is sub-registry or part of transport registry Second sub-registry is: "SRV Service identifiers" Allocation policy is "First Come First Served but can not conflict with port number registry". Rules for registration names are in section 4. Template for registrations is in section 4.1, IANA will archive and make available all accepted registrations via links from the registry. Initial contents of the registry is in section 4.2 Gudmundsson & Hoenes Expires January 14, 2010 [Page 12] Internet-Draft IANA SRV registry July 2009 7. References 7.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. 7.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. [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. [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. [RFC5509] Loreto, S., "Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP)", RFC 5509, Gudmundsson & Hoenes Expires January 14, 2010 [Page 13] Internet-Draft IANA SRV registry July 2009 April 2009. Gudmundsson & Hoenes Expires January 14, 2010 [Page 14] Internet-Draft IANA SRV registry July 2009 Authors' Addresses Olafur Gudmundsson OGUD Consulting LLC 3821 Village Park Drive Chevy Chase, MD 20815 USA Email: ogud@ogud.com Alfred Hoenes TR-Sys Gerlinger Str. 12 Ditzingen D-81254 Germany Email: ah@TR-Sys.de Gudmundsson & Hoenes Expires January 14, 2010 [Page 15]