Network Working Group O. Gudmundsson Internet-Draft OGUD Consulting LLC Expires: April 30, 2009 October 27, 2008 Creation of a registry for DNS SRV record protocol names draft-gudmundsson-dns-srv-iana-registry-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 30, 2009. Gudmundsson Expires April 30, 2009 [Page 1] Internet-Draft IANA SRV registry October 2008 Abstract DNS SRV record was specified in RFC2052 and RFC2782. These two RFC did not specify an IANA registry for names of the protocols using SRV records. This document creates such a registry. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SRV registry considerations . . . . . . . . . . . . . . . . . 4 2.1. To _ or not to _ . . . . . . . . . . . . . . . . . . . . . 4 2.2. Regular expression in service registrations . . . . . . . 4 2.3. Name collisions in service registrations . . . . . . . . . 4 3. SRV Transport protocols . . . . . . . . . . . . . . . . . . . 5 4. SRV Application identifiers . . . . . . . . . . . . . . . . . 6 4.1. SRV Application identifiers registration template . . . . 6 4.2. SRV Application identifiers registry contents . . . . . . 6 5. Security considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Gudmundsson Expires April 30, 2009 [Page 2] Internet-Draft IANA SRV registry October 2008 1. Introduction SRV record was introduced in RFC2052 [RFC2052] an experimental extension, it proved highly valuable addition to the DNS to be used for service location and provisioning. SRV record was thus standardized in RFC2782 [RFC2782]. The main difference between the versions is the use of the "_" prefix character in names to avoid naming conflicts between service names and regular names. The SRV record has a recommended naming structure for its use: _service._Proto.name SRV priority weight PORT Target The "_Proto" field is the name of the transport protocol to be used, the "_service" name on the other hand is a name of the Service/ Application that is being offered. "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. RFC2782 says that the source of names of "services" is "Assigned names" and cites document STD2. STD2 series was obsoleted by RFC3232 [RFC3232] and registration services was handed over to on-line registries maintained by IANA. Unfortunately it is not explicitly explained in RFC2782 which section of STD2 it is referring nor does RFC3232 help. By common knowledge the corresponding IANA registry's are the two "Port Numbers" registries. Upon reflection it does not seem to make sense to have a registered port number for a service that is going to be looked up via SRV record. As the SRV record contains the port at where each server provides the service. The number of ports available is small compared to the possible names that can be registered. For these reasons this document creates a separate registry that is only for SRV services. This explicitly removes the constraint that services need a port number registrations. The registration requirement for this new registry as set low as to make it relatively easy to register a new name. To large extent the requirement to register port numbers can be eliminated by encouraging SRV use in all new application protocols. 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 [1]. Gudmundsson Expires April 30, 2009 [Page 3] Internet-Draft IANA SRV registry October 2008 2. SRV registry considerations Registering a new service should be easy and painless process, but registering a new transport protocol should be hard. For service a pointer to specification is optional, but required for transportation protocol. 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 impossilbe 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 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 same namecollision in the services does not apply. While arguments that the pressence of the "_" character make it easier to spot this is a service are not convincing. 2.2. Regular expression in service registrations There are cases were a registrant may want to register a collection of names that are followed an pattern. Instances like "my-updates- 21yy" or "Producer-model_number". In the first case the registration would be for "My-updates-21[0-9][0-9]" and in the second case "Producer-.+". These registrations should be as specific as possible avoiding cases like "http.+" that collides with https. If a regular expression in a requiest collides with an existing string then it should be rejected. Only registrations with regular expressions at the end of the string are allowed. 2.3. 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 "_". Further more to provide grace period where existing names can be registered, for one calendar year after this document is published as an RFC no registrations without "_" will be accepted. Gudmundsson Expires April 30, 2009 [Page 4] Internet-Draft IANA SRV registry October 2008 3. SRV Transport protocols This section contains the known Transport protocol identifiers List of Transport protocls registerd to be used with DNS SRV records. +---------------+-------------+ | Protocol name | Refereneces | +---------------+-------------+ | _tcp | TDB | | | | | _udp | TDB | +---------------+-------------+ Table 1 TODO: are there other transport protocols that use SRV records? Gudmundsson Expires April 30, 2009 [Page 5] Internet-Draft IANA SRV registry October 2008 4. SRV Application identifiers 4.1. SRV Application identifiers registration template Registration of SRV Application 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 Application description (optional): IANA will archive the accepted templates and make the available via links in the registry. Submit registrations to TDB@TDB 4.2. SRV Application identifiers registry contents This section is expected to contain all known identifiers that are in use with and without "_" prefix. Gudmundsson Expires April 30, 2009 [Page 6] Internet-Draft IANA SRV registry October 2008 Registry format: +-----------------+---------------------+------------+ | Registered name | Transport protocols | reference: | +-----------------+---------------------+------------+ | _dns-llq-tls | _tcp | | | | | | | _dns-sd | _upd | | | | | | | _dns-update | _upd | | | | | | | _kerberos- | _upd | RFC4120 | | | | | | _kerberos- | _tcp | RFC4120 | | | | | | _jabber | _tcp | | | | | | | _ldap | _tcp | RFC3088 | | | | | | _msrps | _tcp | RFC4976 | | | | | | _sip | _udp | RFC3263 | | | | | | _sips | _tcp | | | | | | | _sipfederation | _tcp | | | | | | | _slpda | _tcp | RFC3832 | | | | | | _xmpp | _tcp | RFC3921 | | | | | | _xmpp-client | _tcp | RFC3920 | | | | | | _xmpp-server | _tcp | RFC3920 | +-----------------+---------------------+------------+ List based on my DNS server logs from September and strings found in RFC, missing Active Directory names Table 2 Question: should format be: name - _tcp - _udp - ref ? Gudmundsson Expires April 30, 2009 [Page 7] Internet-Draft IANA SRV registry October 2008 5. Security considerations TDB Gudmundsson Expires April 30, 2009 [Page 8] Internet-Draft IANA SRV registry October 2008 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 in 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. Second sub-registry is: "SRV Application identifiers" Allocation policy is "First Come First Served". 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 Expires April 30, 2009 [Page 9] Internet-Draft IANA SRV registry October 2008 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 [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996. [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. Gudmundsson Expires April 30, 2009 [Page 10] Internet-Draft IANA SRV registry October 2008 Author's Address Olafur Gudmundsson OGUD Consulting LLC 3821 Village Park Drive Chevy Chase, MD 20815 USA Email: ogud@ogud.com Gudmundsson Expires April 30, 2009 [Page 11] Internet-Draft IANA SRV registry October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Gudmundsson Expires April 30, 2009 [Page 12]