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

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:

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

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

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.

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.

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.

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

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.

• _iris-* RFC 3981 appendix A
• _mail RFC 4985
• _ntp RFC 4085
• _pigen RFC 3091
• _telnet RFC 3620
• _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.

• RFC 4123 says: ITU-T H.323 Annex O also defines SRV use.
• 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 (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.

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] (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".

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses