Network Working Group J. Klensin
Internet-Draft
Intended status: Informational A. Sullivan
Expires: March 03, 2014 Dyn
P. Faltstrom
Netnod
August 30, 2013
An IANA Registry for Protocol Uses of Data with the DNS TXT RRTYPE
draft-klensin-iana-txt-rr-registry-00
Abstract
Some protocols use the RDATA field of the DNS TXT RRTYPE for holding
data to be parsed, rather than for unstructured free text. This
document specifies the creation of an IANA registry for protocol-
specific structured data to minimize the risk of conflicting or
inconsistent uses of that RRTYPE and data field.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 03, 2014.
Copyright Notice
Copyright (c) 2013 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Klensin, et al. Expires March 03, 2014 [Page 1]
Internet-Draft TXT RR Data Registry August 2013
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Registry Contents . . . . . . . . . . . . . . . . . . . . . . 3
3. Adding New Registry Entries . . . . . . . . . . . . . . . . . 3
4. Updating Registry Entries . . . . . . . . . . . . . . . . . . 4
5. Registraton Template . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. DNS Parameter and Registry Loose Ends . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The TXT RRTYPE was defined as part of the initial domain name system
(DNS) specification [RFC1035] to hold descriptive text the semantics
of which was to be dependent on the domain in which the TXT record
was found (paraphrase of part of Section 3.3.14 of RFC 1035). In
more recent years, several protocols have used the TXT RRTYPE for
structured information to be used by particular protocols, sometimes
to avoid creating a separate and specific RRTYPE. There have been
extensive discussions about whether that type of use of the TXT
RRTYPE is appropriate or desirable; design choices about DNS
extensions and some of their consequences are discussed in RFC 5507
[RFC5507]. However, independent of how one feels about those issues,
the reality is that the RDATA field of TXT RRs are in use for
protocol-specific information that is interpreted by the protocols
themselves. Those uses are not going to disappear. It is even
possible that tradeoffs between established uses, conversion costs,
and related issue might justify standardization of the practice,
however problematic and/or distasteful that might be in principle.
Having structured information that is protocol-specific without a
registry increases the risk of different parties using the same
identifying information for different purposes, thereby creating
security and operational risks. This document specifies the relevant
registry.
It might be argued that a registry is inappropriate, because it is in
effect a subtyping of the TXT RRTYPE. While the position has merit,
Klensin, et al. Expires March 03, 2014 [Page 2]
Internet-Draft TXT RR Data Registry August 2013
without a registry and with continued uses of TXT to support pieces
of protocol, it is only a matter of time before overlapping or
confusable uses turn into an attack. While such an outcome might be
accidental, it would still be bad. If there were a registry, then
one might dream of zone-checking tools that would warn about
apparently-structured information that didn't reflect any of the
registered entries.
It is important to stress that this registry is intrinsically about
what is being done and not about what risks exist and whether
particular measures or considerations might mitigate those risks.
This document specifies creation of that registry and the means by
while it is populated.
2. Registry Contents
Each registry entry consists of a reference to the protocol that
identifies specific information in the TXT Resource Record's RDATA
field and that indicates what information is used to make that
identification. For example, if the "foo" protocol were described in
RFC 9999 and used the presence of the string "foo=" at the beginning
of the first character string in the TXT Resource Record RDATA to
identify information that applied to it, the registry would identify
the protocol ("foo"), the submitter, the reference that described it
("RFC 9999") and the association-determining string ("foo="). The
registry also allows for comment information. That information might
include information about prefixes or suffixes for the DNS owner name
that are used with the particular protocol at issue.
For tracking purposes, each entry also contains date created and date
last modified information.
3. Adding New Registry Entries
As discussed when the IETF concluded that there should be fewer
barriers to the creation and use of new RRTYPES [RFC6895] best
practices today generally call for creating new, protocol- or
application-specific types rather than overloading information onto
the TXT RRTYPE. Consequently, this registry is expected to reflect
deployed existing practices rather than new uses for TXT. Its use to
make the latter more acceptable would contradict the intent of both
this specification and the registry itself.
Consistent with that principle, the procedure for accepting new
entries into the registry will be review by a Designated Expert
[RFC5226] as modified below.
Klensin, et al. Expires March 03, 2014 [Page 3]
Internet-Draft TXT RR Data Registry August 2013
The Expert is expected to determine that the particular use of TXT is
in established use and, ideally, is documented with a stable
specification as defined by RFC 5226 and the RFC Editor. The
existence of a standards track RFC or equivalent specification is
always sufficient to meet those conditions. In less common cases,
the Expert should consider the explanation above and apply good
judgment, favoring adding entries to the registry in cases of doubt.
Cases that cannot be resolved adequately by discussion between the
applicant and the Expert may be referred to the IESG.
4. Updating Registry Entries
Registries may be updated using the same mechanisms used to create
new ones. The expert reviewer should attempt to ensure that updates
are limited to corrections or consistent expansions of earlier
information and that the party proposing the update is at least as
authoritative about the original protocol as the party who submitted
the original registration request.
5. Registraton Template
A registration request should supply the following information,
ideally in this form:
1. Name and contact information for the submitter.
2. Protocol identification and, where feasible, documentation
reference.
3. Distinguishing characteristics of the TXT RDATA content that
permit identifying information for this protocol.
4. Any special considerations for multiple TXT records with the same
owner name.
5. Other special constraint or identifying information. For
example, if the protocol being registered requires special
prefixes or suffixes for the owner name, a discussion of that
requirement.
6. IANA Considerations
This memo specifies the creation of a new registry in the Domain Name
System (DNS) Parameters group [IANA-DNS-Parameters]. The details for
the contents and registration requirements for that registry appear
in Section 2 and Section 3 above.
Klensin, et al. Expires March 03, 2014 [Page 4]
Internet-Draft TXT RR Data Registry August 2013
The registry should have explicit text referencing this document.
The text should be similar to the following:
"This registry exists to decrease the risk for overlapping use of
the TXT Resource Record Type for structured data instead of having
the RDATA for that type contain only descriptive text without
specified semantics (as described in RFC 1035. See RFC 5507 and
the Security Considerations section of RFC NNNN for more
information."
While it is common practice for registry-creating documents to
specify the initial content of the registry, this one deliberately
does not do so in order to allow the actual users of the relevant
types to identify them and provide explanations for their use.
[[Note in draft (JcK): The surveys conducted in conjunction with the
SPFbis work identified a good number of uses of TXT data. Some of
them might belong in the registry. But the decisions as to which
ones should be are more appropriately left to the expert review
process rather than becoming matters of IETF debate or publication in
the RFC Series.]] [[AJS: I'm by no means sure that this is the right
way to go. Why not just identify them and create the initial
registry? Is this simple expedience?]] [[JcK: A little more than
that. Since a lot of overloaded uses of TXT have been identified for
which we lack documentation and can only guess about meaning, it
would be inappropriate for anyone other than parties who are willing
to claim responsibility to ask that they be put into the registry
(those parties might be able to identify documentation too). Not
creating initial entries for the particular uses that are described
in IETF documents is somewhat expedient, but it also helps emphasize
that, as far as the registry is concerned, those entries are not in
any way special.]] [[PAF: I think it is fair to expect all initial
entries to the registry is passing Expert Review. If it already
exists in the SPF review, the work for The Expert will be easy.]]
7. Security Considerations
The creation and use of this registry should help to minimize the
risks of different protocols inadvertently using data embedded in TXT
Resource Records in incompatible ways. Consequently, it should have
a positive effect on security. Because this document and the
registry do not address the question of what protocols, if any,
should use TXT RDATA in this way, questions associated with the usage
and structure of particular protocols lie outside its scope.
There is a general (although by no means unanimous) view among DNS
experts that overloading RRTYPEs, especially the TXT type, is a bad
practice that could lead, not only to the sort of conflicts that this
Klensin, et al. Expires March 03, 2014 [Page 5]
Internet-Draft TXT RR Data Registry August 2013
registry might help prevent, but to requirements for multiple queries
and even an increased risk from amplification attacks. While caution
is always appropriate when documenting a risky practice lest the
documentation be taken as endorsement, the arguments for providing
documentation for deployed protocol uses of TXT RRs seems very
similar to the historical arguments for documenting security risks:
being secretive about them won't prevent either their being exploited
or prevent new ones from being invented.
8. Acknowledgements
The requirement for this registry became obvious as a result of the
discussion of handing records for SPF in the DNS. The comments of
the participants on all sides of that discussion are gratefully
acknowledged.
Specific comments and text for this draft were provided by Eliot Lear
and Subramanian Moonesamy.
[[Several useful comments about the general approach taken in the
document were received in private notes whose authors may or may not
want to be linied to the draft. The originators of such comments
should contact the first-listed author if they would like to be
listed explicitly.]]
9. References
9.1. Normative References
[IANA-DNS-Parameters]
IANA, "Domain Name System (DNS) Parameters", 2013, <http:/
/www.iana.org/assignments/dns-parameters/dns-
parameters.xhtml>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
9.2. Informative References
[RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design
Choices When Expanding the DNS", RFC 5507, April 2009.
[RFC6895] Eastlake, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, April 2013.
Klensin, et al. Expires March 03, 2014 [Page 6]
Internet-Draft TXT RR Data Registry August 2013
Appendix A. DNS Parameter and Registry Loose Ends
[[RFC Editor: please remove this appendix before publication.]]
The discussions surrounding this draft suggest that one or two
additional DNS registries may be needed and that the current IANA
structure for DNS-related information may not be optimal. In
particular, there is no registry for SRV mechanisms or protocols, nor
for two of the five extension mechanisms described in RFC 5507 as
adding prefix or suffixes to owner names. In that context, the
registry proposed in this specification can be seen as essentially a
subtype registry for the TXT RRTYPE altnough it is deliberately
designed to include TXT-related prefixes and suffix approaches as
well. It would, however, probably be useful for someone to
investigate and, if appropriate, specify additional subtype, prefix,
and suffix registries as appropriate.
As part of that effort, it may be useful to advise IANA as to whether
some or all of the registries at
<https://www.iana.org/assignments/s-naptr-parameters/s-naptr-
parameters.xhtml>,
<https://www.iana.org/assignments/sip-table/sip-table.xhtml>,
<https://www.iana.org/assignments/enum-services/enum-
services.xhtml>,
<https://www.iana.org/assignments/im-srv-labels/im-srv-
labels.xhtml>,
<https://www.iana.org/assignments/pres-srv-labels/pres-srv-
labels.xhtml>,
and
<https://www.iana.org/assignments/pkix-parameters/pkix-
parameters.xhtml>
Should be incorporated into, or have crossreference links from, the
IANA "Domain Name System (DNS) Parameters" page.
Authors' Addresses
Klensin, et al. Expires March 03, 2014 [Page 7]
Internet-Draft TXT RR Data Registry August 2013
John C Klensin
1770 Massachusetts Ave, Ste 322
Cambridge, MA 02140
USA
Phone: +1 617 245 1457
Email: john-ietf@jck.com
Andrew Sullivan
Dyn
150 Dow St
Manchester, NH 03101
USA
Email: asullivan@dyn.com
Patrik Faltstrom
Netnod
Franzengatan 5
112 51 Stockholm
Sweden
Email: paf@netnod.se
Klensin, et al. Expires March 03, 2014 [Page 8]