TOC 
Network Working GroupO. Gudmundsson
Internet-DraftShinkuro Inc.
Intended status: Standards TrackA. Hoenes
Expires: April 29, 2010TR-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 services using SRV records as defined by various protocols. This document creates such a registry and populates it.



Table of Contents

1.  Introduction
    1.1.  Terminology
2.  SRV Service Prefix Registry Considerations
    2.1.  To _ or Not To _
    2.2.  Service Name Maintenance
    2.3.  Name Collisions in Service Registrations
3.  SRV Protocol Labels
4.  SRV Service Labels
    4.1.  SRV Service Prefix Registration Template
    4.2.  Initial SRV Service Labels Registry Contents
    4.3.  RFC Examples and Pointers
5.  Relationship to Other IANA Registries
6.  Security Considerations
7.  IANA Considerations
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses




 TOC 

1.  Introduction

The SRV resource record (RR) was originally introduced in RFC 2052 (Gulbrandsen, A. and P. Vixie, “A DNS RR for specifying the location of services (DNS SRV),” October 1996.) [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 (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.) [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] (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.):

_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 (Reynolds, J., “Assigned Numbers: RFC 1700 is Replaced by an On-line Database,” January 2002.) [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:

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 (Name Collisions in Service Registrations) for elaborations on such name conflicts.

In the spirit of BCP 17, RFC 2219 (Hamilton, M. and R. Wright, “Use of DNS Aliases for Network Services,” October 1997.) [RFC2219], this registry should also help providing an orderly substitute for the poorly specified Well-Known Network Service Alias names.

Note: RFC 5507 (IAB, Faltstrom, P., Austein, R., and P. Koch, “Design Choices When Expanding the DNS,” April 2009.) [RFC5507], discusses the use of "underscore labels" in the DNS more generally, from the architectural point of view of the IAB.



 TOC 

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119] .



 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

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.

New registraions in the "PORT NUMBERS" MUST NOT create a name confict with the SRV registry.



 TOC 

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.



ProtocolReferences
Transport protocols
_tcp RFC 793 (Postel, J., “Transmission Control Protocol,” September 1981.) [RFC0793]
_udp RFC 768 (Postel, J., “User Datagram Protocol,” August 1980.) [RFC0768]
_dccp RFC 4340 (Kohler, E., Handley, M., and S. Floyd, “Datagram Congestion Control Protocol (DCCP),” March 2006.) [RFC4340]
_sctp RFC 4960 (Stewart, R., “Stream Control Transmission Protocol,” September 2007.) [RFC4960]
Overlay protocols
_http RFC 4386 (Boeyen, S. and P. Hallam-Baker, “Internet X.509 Public Key Infrastructure Repository Locator Service,” February 2006.) [RFC4386]
_ipv6 RFC 5026 (Giaretta, G., Kempf, J., and V. Devarapalli, “Mobile IPv6 Bootstrapping in Split Scenario,” October 2007.) [RFC5026]
_ldap RFC 4386 (Boeyen, S. and P. Hallam-Baker, “Internet X.509 Public Key Infrastructure Repository Locator Service,” February 2006.) [RFC4386]
_sip RFC 5509 (Loreto, S., “Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP),” April 2009.) [RFC5509]
_ocsp RFC 4386 (Boeyen, S. and P. Hallam-Baker, “Internet X.509 Public Key Infrastructure Repository Locator Service,” February 2006.) [RFC4386]
_xmpp RFC 3921 (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” October 2004.) [RFC3921]

 Table 1 

NOTE #1: For the purpose of the _Protocol labels and this registry, UDP-Lite [RFC3828] (Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, “The Lightweight User Datagram Protocol (UDP-Lite),” July 2004.) is treated as indistinguishable from UDP [RFC0768] (Postel, J., “User Datagram Protocol,” August 1980.).

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 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.



 TOC 

4.  SRV Service Labels



 TOC 

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.



 TOC 

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).



Service labelProtocol(s) definedReference(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 



 TOC 

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.

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.



 TOC 

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 (Peterson, J., “Address Resolution for Instant Messaging and Presence,” August 2004.) [RFC3861], the "Instant Messaging SRV Protocol Label Registry" currently located at http://www.iana.org/assignments/im-srv-labels and the "Presence SRV Protocol Label Registry" currently located at http://www.iana.org/assignments/pres-srv-labels

Currently, there is one registration ("_xmpp") in each of these registries, performed by RFC 3921 (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” October 2004.) [RFC3921], and another, more recent registration ("_sip"), performed by RFC 5509 (Loreto, S., “Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP),” April 2009.) [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 http://www.iana.org/assignments/pkix-parameters contains a single entry for the service label "_pkixrep" in combination with three protocols, based on RFC 4386 (Boeyen, S. and P. Hallam-Baker, “Internet X.509 Public Key Infrastructure Repository Locator Service,” February 2006.) [RFC4386], which has been included in Table 2. Arguably, that sub-registry might be abandoned by a future update of [RFC4386] (Boeyen, S. and P. Hallam-Baker, “Internet X.509 Public Key Infrastructure Repository Locator Service,” February 2006.), 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.



 TOC 

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.



 TOC 

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] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.).

The first sub-registry is: "SRV Protocol Labels". Allocation policy is: "IETF Review" [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.). The initial content of this sub-registry is specified by Table 1 (Section 3 (SRV Protocol Labels)).

The second sub-registry is: "SRV Service Labels". Allocation policy is: "First Come First Served [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.), but MUST NOT conflict with service names in the Port Number registry" (see Section 2.3 (Name Collisions in Service Registrations)). Rules for Labels to be registered are in Section 4. The initial content of the registry is specified by Table 2 (Section 4.2 (Initial SRV Service Labels Registry Contents)). 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".



 TOC 

8.  References



 TOC 

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 (TXT).
[RFC5226] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 5226, May 2008 (TXT).


 TOC 

8.2. Informative References

[RFC0768] Postel, J., “User Datagram Protocol,” STD 6, RFC 768, August 1980 (TXT).
[RFC0793] Postel, J., “Transmission Control Protocol,” STD 7, RFC 793, September 1981 (TXT).
[RFC2052] Gulbrandsen, A. and P. Vixie, “A DNS RR for specifying the location of services (DNS SRV),” RFC 2052, October 1996 (TXT).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2219] Hamilton, M. and R. Wright, “Use of DNS Aliases for Network Services,” BCP 17, RFC 2219, October 1997 (TXT).
[RFC3232] Reynolds, J., “Assigned Numbers: RFC 1700 is Replaced by an On-line Database,” RFC 3232, January 2002 (TXT).
[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 (TXT).
[RFC3861] Peterson, J., “Address Resolution for Instant Messaging and Presence,” RFC 3861, August 2004 (TXT).
[RFC3921] Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” RFC 3921, October 2004 (TXT, HTML, XML).
[RFC4340] Kohler, E., Handley, M., and S. Floyd, “Datagram Congestion Control Protocol (DCCP),” RFC 4340, March 2006 (TXT).
[RFC4386] Boeyen, S. and P. Hallam-Baker, “Internet X.509 Public Key Infrastructure Repository Locator Service,” RFC 4386, February 2006 (TXT).
[RFC4960] Stewart, R., “Stream Control Transmission Protocol,” RFC 4960, September 2007 (TXT).
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, “Mobile IPv6 Bootstrapping in Split Scenario,” RFC 5026, October 2007 (TXT).
[RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, “Design Choices When Expanding the DNS,” RFC 5507, April 2009 (TXT).
[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, April 2009 (TXT).


 TOC 

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