[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                       J.C. Klensin
Internet-Draft                                               A. Sullivan
Intended status: Informational                                       Dyn
Expires: September 25, 2014                                 P. Faltstrom
                                                                  Netnod
                                                          March 26, 2014

   An IANA Registry for Protocol Uses of Data with the DNS TXT RRTYPE
                 draft-klensin-iana-txt-rr-registry-02

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 September 25, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the















Klensin, Sullivan & FalExpires September 25, 2014               [Page 1]

Internet-Draft            TXT RR Data Registry                March 2014

   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 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
     2.1.  General Usage Information  . . . . . . . . . . . . . . . .  3
     2.2.  Character Sets, Codes, and Restrictions  . . . . . . . . .  4
   3.  Adding New Registry Entries  . . . . . . . . . . . . . . . . .  4
   4.  Updating Registry Entries  . . . . . . . . . . . . . . . . . .  4
   5.  Registration Template  . . . . . . . . . . . . . . . . . . . .  5
   6.  Internationalization Considerations  . . . . . . . . . . . . .  5
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     10.1.  Normative References  . . . . . . . . . . . . . . . . . .  7
     10.2.  Informative References  . . . . . . . . . . . . . . . . .  7
   Appendix A. DNS Parameter and Registry Loose Ends  . . . . . . . .  8
   Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . .  9
     Appendix B.1.  Changes from version -00 to -01 . . . . . . . . .  9
     Appendix B.2.  Changes from version -01 to -02 . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9

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













Klensin, Sullivan & FalExpires September 25, 2014               [Page 2]

Internet-Draft            TXT RR Data Registry                March 2014

   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 DATA fields 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,
   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

2.1.  General Usage Information

   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=").  In
   addition, the registry will identify any constraints on or special
   properties of the RDATA, such as whether it is restricted to ASCII,
   expected to be in UTF-8 characters, may contain more than one string,
   or represents some other type of information.  The registry also
   allows for comment information.  That information might include



Klensin, Sullivan & FalExpires September 25, 2014               [Page 3]

Internet-Draft            TXT RR Data Registry                March 2014

   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.

2.2.  Character Sets, Codes, and Restrictions

   Section 3.3.14 of the DNS Specification [RFC1035] specifies only that
   the RRDATA for TXT consists of "One or more <character-string>s".
   Section 3.2 specifies that a <character-string> "is a single length
   octet followed by that number of characters.  <character-string> is
   treated as binary information, and can be up to 256 characters in
   length (including the length octet).".   If more that one string is
   allowed for the particular TXT record, the registration record should
   indicate that fact and how the multiple strings are interpreted.
   Similarly, if the character strings are not restricted to ASCII
   characters, the registration record should discuss how they are to be
   interpreted, what constraints are applied, and, if the strings are
   likely to be compared to others, what collation sequences or other
   rules apply.

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.

   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







Klensin, Sullivan & FalExpires September 25, 2014               [Page 4]

Internet-Draft            TXT RR Data Registry                March 2014


   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.  Registration 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.  Character set information and limitations on the RDATA field or
       an indication that the RDATA are not in character form and
       whether more than character string is permitted.  If more than
       one character string is permitted, this section of the template
       should note that and discuss how multiple strings are to be
       interpreted.  This field may be a reference to a stable external
       document.

   5.  Any special considerations for multiple TXT records with the same
       owner name.

   6.  If feasible, an explanation of why the TXT RRTYPE is preferred
       for this particular use over a dedicated, purpose-specific
       RRTYPE.

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

   As discussed above, the DNS protocol does not restrict TXT RDATA
   fields to ASCII characters.  If appropriate, other character
   repertoires and encodings, or even octets interpreted as non-
   character binary information, may be used.  For reasons discussed in
   detail elsewhere, if non-ASCII character data is needed, Unicode
   encoded in UTF-8 is strongly preferred to other encoding forms or
   script-specific encodings.  Because the use of non-ASCII characters
   often raises multiple issues, specifically including string
   comparison choices, registration information should ideally include a
   discussion of relevant issues (or why there is no issue).


Klensin, Sullivan & FalExpires September 25, 2014               [Page 5]

Internet-Draft            TXT RR Data Registry                March 2014


   For readers needing further information on this subject, different
   aspects of the string comparison problem for non-ASCII text appear in
   RFC 2130 [RFC2130], RFC 4790 [RFC4790], RFC 5894 [RFC5894], RFC 6055
   [RFC6055], and RFC 6885 [RFC6885].

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

   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: The authors disagree as to whether this document
      should include all known uses of TXT RRTYPE DATA (specifically
      including all of those discovered in the surveys conducted in
      conjunction with the SPFbis work) or should create an empty
      registry and await addition of entries as described in this
      specification.  The advantage of the former is that the registry
      will contain a useful list of applications of TXT much more
      quickly.  Via the expert review process, the latter would
      presumably yield better descriptions and information about
      responsible parties for many entries.  A possible middle ground
      would be to try to identify all uses that are explicitly
      identified in IETF standards track documents and include them
      initially, leaving other uses to the registration process.]]

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




Klensin, Sullivan & FalExpires September 25, 2014               [Page 6]

Internet-Draft            TXT RR Data Registry                March 2014


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

9.  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.  Dick Francis pointed out the need for a
   discussion of non-ASCII characters.

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

10.  References

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

10.2.  Informative References

   [RFC2130]  Weider, C., Preston, C., Simonsen, K., Alvestrand, H.T.,
              Atkinson, R., Crispin, M. and P. Svanberg, "The Report of
              the IAB Character Set Workshop held 29 February - 1 March,
              1996", RFC 2130, April 1997.



Klensin, Sullivan & FalExpires September 25, 2014               [Page 7]

Internet-Draft            TXT RR Data Registry                March 2014


   [RFC4790]  Newman, C., Duerst, M. and A. Gulbrandsen, "Internet
              Application Protocol Collation Registry", RFC 4790, March
              2007.

   [RFC5507]  IAB, Faltstrom, P., Austein, R. and P. Koch, "Design
              Choices When Expanding the DNS", RFC 5507, April 2009.

   [RFC5894]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Background, Explanation, and
              Rationale", RFC 5894, August 2010.

   [RFC6055]  Thaler, D., Klensin, J. and S. Cheshire, "IAB Thoughts on
              Encodings for Internationalized Domain Names", RFC 6055,
              February 2011.

   [RFC6885]  Blanchet, M. and A. Sullivan, "Stringprep Revision and
              Problem Statement for the Preparation and Comparison of
              Internationalized Strings (PRECIS)", RFC 6885, March 2013.

   [RFC6895]  Eastlake, D., "Domain Name System (DNS) IANA
              Considerations", BCP 42, RFC 6895, April 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 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,


Klensin, Sullivan & FalExpires September 25, 2014               [Page 8]

Internet-Draft            TXT RR Data Registry                March 2014


      https://www.iana.org/assignments/pres-srv-labels/pres-srv-
      labels.xhtml,

      https://www.iana.org/assignments/service-names-port-numbers/
      service-names-port-numbers.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.

Appendix B.  Change Log

   [[RFC Editor: Please remove this appendix before publication.]]

Appendix B.1.  Changes from version -00 to -01

   o  Added this appendix

   o  Corrected the statement about the absence of an SRV label registry
      and added that registry to the Appendix Appendix A list.

   o  Small formatting changes to improve readability.

   o  Replaced the discussion among the authors in Section 7 with a
      summary note.  Community input is needed.

Appendix B.2.  Changes from version -01 to -02

   o  Added provision for identifying character set or similar
      information and "Internationalization" section.

   o  Added discussion about the contents of RDATA fields.

Authors' Addresses

   John C Klensin
   1770 Massachusetts Ave, Ste 322
   Cambridge, MA 02140
   USA

   Phone: +1 617 245 1457
   Email: john-ietf@jck.com








Klensin, Sullivan & FalExpires September 25, 2014               [Page 9]

Internet-Draft            TXT RR Data Registry                March 2014


   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, Sullivan & FalExpires September 25, 2014              [Page 10]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/