One document matched: draft-gudmundsson-dns-srv-iana-registry-04.txt
Differences from draft-gudmundsson-dns-srv-iana-registry-03.txt
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
<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 [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
<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 [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]
| PAFTECH AB 2003-2026 | 2026-04-24 04:50:21 |