doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc5507.txt b/doc/rfc/rfc5507.txt
new file mode 100644
index 0000000..a286d90
--- /dev/null
+++ b/doc/rfc/rfc5507.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                                IAB
+Request for Comments: 5507                             P. Faltstrom, Ed.
+Category: Informational                                  R. Austein, Ed.
+                                                            P. Koch, Ed.
+                                                              April 2009
+
+
+                 Design Choices When Expanding the DNS
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+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
+
+   This note discusses how to extend the DNS with new data for a new
+   application.  DNS extension discussions too often focus on reuse of
+   the TXT Resource Record Type.  This document lists different
+   mechanisms to extend the DNS, and concludes that the use of a new DNS
+   Resource Record Type is the best solution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB, et al.                  Informational                      [Page 1]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Background ......................................................4
+   3. Extension Mechanisms ............................................5
+      3.1. Place Selectors inside the RDATA of Existing
+           Resource Record Types ......................................5
+      3.2. Add a Prefix to the Owner Name .............................6
+      3.3. Add a Suffix to the Owner Name .............................7
+      3.4. Add a New Class ............................................8
+      3.5. Add a New Resource Record Type .............................8
+   4. Zone Boundaries are Invisible to Applications ...................9
+   5. Why Adding a New Resource Record Type Is the Preferred
+      Solution .......................................................10
+   6. Conclusion and Recommendation ..................................14
+   7. Creating a New Resource Record Type ............................14
+   8. Security Considerations ........................................15
+   9. Acknowledgements ...............................................15
+   10. IAB Members at the Time of This Writing .......................16
+   11. References ....................................................16
+      11.1. Normative References .....................................16
+      11.2. Informative References ...................................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB, et al.                  Informational                      [Page 2]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+1.  Introduction
+
+   The DNS stores multiple categories of data.  The two most commonly
+   used categories are infrastructure data for the DNS system itself (NS
+   and SOA Resource Records) and data that have to do with mappings
+   between domain names and IP addresses (A, AAAA, and PTR Resource
+   Records).  There are other categories as well, some of which are tied
+   to specific applications like email (MX Resource Records), while
+   others are generic Resource Record Types used to convey information
+   for multiple protocols (SRV and NAPTR Resource Records).
+
+   When storing data in the DNS for a new application, the goal must be
+   to store data in such a way that the application can query for the
+   data it wants, while minimizing both the impact on existing
+   applications and the amount of extra data transferred to the client.
+   This implies that a number of design choices have to be made, where
+   the most important is to ensure that a precise selection of what data
+   to return must be made already in the query.  A query consists of a
+   triple: {Owner (or name), Resource Record Class, Resource Record
+   Type}.
+
+   Historically, extending the DNS to store application data tied to a
+   domain name has been done in different ways at different times.  MX
+   Resource Records were created as a new Resource Record Type
+   specifically designed to support electronic mail.  SRV records are a
+   generic type that use a prefixing scheme in combination with a base
+   domain name.  NAPTR records add selection data inside the RDATA.  It
+   is clear that the methods used to add new data types to the DNS have
+   been inconsistent, and the purpose of this document is to attempt to
+   clarify the implications of each of these methods, both for the
+   applications that use them and for the rest of the DNS.
+
+   This document talks extensively about use of DNS wildcards.  Many
+   people might think use of wildcards is not something that happens
+   today.  In reality though, wildcards are in use, especially for
+   certain application-specific data such as MX Resource Records.
+   Because of this, the choice has to be made with the existence of
+   wildcards in mind.
+
+   Another overall issue that must be taken into account is what the new
+   data in the DNS are to describe.  In some cases, they might be
+   completely new data.  In other cases, they might be metadata tied to
+   data that already exist in the DNS.  Examples of new data are key
+   information for the Secure SHell (SSH) Protocol and data used for
+   authenticating the sender of email messages (metadata tied to MX
+   Resource Records).  If the new data are tied to data that already
+   exist in the DNS, an analysis should be made as to whether having
+   (for example) address records and SSH key information in different
+
+
+
+IAB, et al.                  Informational                      [Page 3]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   DNS zones is a problem or if it is a bonus, and if it is a problem,
+   whether the specification must require all of the related data to be
+   in the same zone.  One specific difference between having the records
+   in the same zone or not has to do with maintenance of the records.
+   If they are in the same zone, the same maintainer (from a DNS
+   perspective) manages the two records.  Specifically, they must be
+   signed with the same DNSSEC keys if DNSSEC is in use.
+
+   This document does not talk about what one should store in the DNS.
+   It also doesn't discuss whether the DNS should be used for service
+   discovery, or whether the DNS should be used for storage of data
+   specific to the service.  In general, the DNS is a protocol that,
+   apart from holding metadata that makes the DNS itself function (NS,
+   SOA, DNSSEC Resource Record Types, etc.), only holds references to
+   service locations (SRV, NAPTR, A, AAAA Resource Record Types) --
+   though there are exceptions, such as MX Resource Records.
+
+2.  Background
+
+   See RFC 5395 [RFC5395] for a brief summary of the DNS query
+   structure.  Readers interested in the full story should start with
+   the base DNS specification in RFC 1035 [RFC1035] and continue with
+   the various documents that update, clarify, and extend the base
+   specification.
+
+   When composing a DNS query, the parameters used by the protocol are a
+   {owner, class, type} triple.  Every Resource Record matching such a
+   triple is said to belong to the same Resource Record Set (RRSet), and
+   the whole RRSet is always returned to the client that queries for it.
+   Splitting an RRSet is a protocol violation (sending a partial RRSet,
+   not truncating the DNS response), because it can result in coherency
+   problems with the DNS caching mechanism.  See Section 5 of [RFC2181]
+   for more information.
+
+   Some discussions around extensions to the DNS include arguments
+   around MTU size.  Note that most discussions about DNS and MTU size
+   are about the size of the whole DNS packet, not about the size of a
+   single RRSet.
+
+   Almost all DNS query traffic is carried over UDP, where a DNS message
+   must fit within a single UDP packet.  DNS response messages are
+   almost always larger than DNS query messages, so message size issues
+   are almost always about responses, not queries.  The base DNS
+   specification limits DNS messages over UDP to 512 octets; EDNS0
+   [RFC2671] specifies a mechanism by which a client can signal its
+   willingness to receive larger responses, but deployment of EDNS0 is
+   not universal, in part because of firewalls that block fragmented UDP
+   packets or EDNS0.  If a response message won't fit in a single
+
+
+
+IAB, et al.                  Informational                      [Page 4]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   packet, the name server returns a truncated response, at which point
+   the client may retry using TCP.  DNS queries over TCP are not subject
+   to this length limitation, but TCP imposes significantly higher per-
+   query overhead on name servers than UDP.  It is also the case that
+   the policies in deployed firewalls far too often are such that they
+   block DNS over TCP, so using TCP might not in reality be an option.
+   There are also risks (although possibly small) that a change of
+   routing while a TCP flow is open creates problems when the DNS
+   servers are deployed in an anycast environment.
+
+3.  Extension Mechanisms
+
+   The DNS protocol is intended to be extensible to support new kinds of
+   data.  This section examines the various ways in which this sort of
+   extension can be accomplished.
+
+3.1.  Place Selectors inside the RDATA of Existing Resource Record Types
+
+   For a given query name, one might choose to have a single RRSet (all
+   Resource Records sharing the same {owner, class, type} triple) shared
+   by multiple applications, and have the different applications use
+   selectors within the Resource Record data (RDATA) to determine which
+   records are intended for which applications.  This sort of selector
+   mechanism is usually referred to "subtyping", because it is in effect
+   creating an additional type subsystem within a single DNS Resource
+   Record Type.
+
+   Examples of subtyping include NAPTR Resource Records [RFC3761] and
+   the original DNSSEC KEY Resource Record Type [RFC2535] (which was
+   later updated by RFC 3445 [RFC3445], and obsoleted by RFC 4033
+   [RFC4033], RFC 4034 [RFC4034] and RFC 4035 [RFC4035]).
+
+   All DNS subtyping schemes share a common weakness: with subtyping
+   schemes, it is impossible for a client to query for just the data it
+   wants.  Instead, the client must fetch the entire RRSet, then select
+   the Resource Records in which it is interested.  Furthermore, since
+   DNSSEC signatures operate on complete RRSets, the entire RRSet must
+   be re-signed if any Resource Record in it changes.  As a result, each
+   application that uses a subtyped Resource Record incurs higher
+   overhead than any of the applications would have incurred had they
+   not been using a subtyping scheme.  The fact the RRSet is always
+   passed around as an indivisible unit increases the risk the RRSet
+   will not fit in a UDP packet, which in turn increases the risk that
+   the client will have to retry the query with TCP, which substantially
+   increases the load on the name server.  More precisely: having one
+   query fail over to TCP is not a big deal, but since the typical ratio
+
+
+
+
+
+IAB, et al.                  Informational                      [Page 5]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   of clients to servers in today's deployed DNS is very high, having a
+   substantial number of DNS messages fail over to TCP may cause the
+   queried name servers to be overloaded by TCP overhead.
+
+   Because of the size limitations, using a subtyping scheme to list a
+   large number of services for a single domain name risks triggering
+   truncation and fallback to TCP, which may in turn force the zone
+   administrator to announce only a subset of available services.
+
+3.2.  Add a Prefix to the Owner Name
+
+   By adding an application-specific prefix to a domain name, we get a
+   different {owner, class, type} triple, and therefore a different
+   RRSet.  One problem with adding prefixes has to do with wildcards,
+   especially if one has records like:
+
+   *.example.com. IN MX 1 mail.example.com.
+
+   and one wants records tied to those names.  Suppose one creates the
+   prefix "_mail".  One would then have to say something like:
+
+   _mail.*.example.com. IN X-FOO A B C D
+
+   but DNS wildcards only work with the "*" as the leftmost token in the
+   domain name (see also RFC 4592 [RFC4592]).
+
+   There have been proposals to deal with the problem that DNS wildcards
+   are always terminal records.  These proposals introduce an additional
+   set of trade-offs that would need to be taken into account when
+   assessing which extension mechanism to choose.  Aspects of extra
+   response time needed to perform the extra queries, costs of pre-
+   calculation of possible answers, or the costs induced to the system
+   as a whole come to mind.  At the time of writing, none of these
+   proposals has been published as Standards Track RFCs.
+
+   Even when a specific prefix is chosen, the data will still have to be
+   stored in some Resource Record Type.  This Resource Record Type can
+   be either a new Resource Record Type or an existing Resource Record
+   Type that has an appropriate format to store the data.  One also
+   might need some other selection mechanism, such as the ability to
+   distinguish between the records in an RRSet, given they have the same
+   Resource Record Type.  Because of this, one needs to both register a
+   unique prefix and define what Resource Record Type is to be used for
+   this specific service.
+
+
+
+
+
+
+
+IAB, et al.                  Informational                      [Page 6]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   If the record has some relationship with another record in the zone,
+   the fact that the two records can be in different zones might have
+   implications on the trust the application has in the records.  For
+   example:
+
+   example.com.      IN MX    10 mail.example.com.
+   _foo.example.com. IN X-BAR "metadata for the mail service"
+
+   In this example, the two records might be in two different zones, and
+   as a result might be administered by two different organizations, and
+   signed by two different entities when using DNSSEC.  For these two
+   reasons, using a prefix has recently become a very interesting
+   solution for many protocol designers.  In some cases, e.g.,
+   DomainKeys Identified Mail Signatures [RFC4871], TXT records have
+   been used.  In others, such as SRV, entirely new Resource Record
+   Types have been added.
+
+3.3.  Add a Suffix to the Owner Name
+
+   Adding a suffix to a domain name changes the {owner, class, type}
+   triple, and therefore the RRSet.  In this case, since the query name
+   can be set to exactly the data one wants, the size of the RRSet is
+   minimized.  The problem with adding a suffix is that it creates a
+   parallel tree within the IN class.  Further, there is no technical
+   mechanism to ensure that the delegation for "example.com" and
+   "example.com._bar" are made to the same organization.  Furthermore,
+   data associated with a single entity will now be stored in two
+   different zones, such as "example.com" and "example.com._bar", which,
+   depending on who controls "_bar", can create new synchronization and
+   update authorization issues.
+
+   One way of solving the administrative issues is by using the DNAME
+   Resource Record Type specified in RFC 2672 [RFC2672].
+
+   Even when using a different name, the data will still have to be
+   stored in some Resource Record Type that has an appropriate format to
+   store the data.  This implies that one might have to mix the prefix
+   based selection mechanism with some other mechanism so that the right
+   Resource Record can be found out of many in a potential larger RRSet.
+
+   In RFC 2163 [RFC2163] an infix token is inserted directly below the
+   Top-Level Domain (TLD), but the result is equivalent to adding a
+   suffix to the owner name (instead of creating a TLD, one is creating
+   a second level domain).
+
+
+
+
+
+
+
+IAB, et al.                  Informational                      [Page 7]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+3.4.  Add a New Class
+
+   DNS zones are class-specific in the sense that all the records in
+   that zone share the same class as the zone's SOA record and the
+   existence of a zone in one class does not guarantee the existence of
+   the zone in any other class.  In practice, only the IN class has ever
+   seen widespread deployment, and the administrative overhead of
+   deploying an additional class would almost certainly be prohibitive.
+
+   Nevertheless, one could, in theory, use the DNS class mechanism to
+   distinguish between different kinds of data.  However, since the DNS
+   delegation tree (represented by NS Resource Records) is itself tied
+   to a specific class, attempting to resolve a query by crossing a
+   class boundary may produce unexpected results because there is no
+   guarantee that the name servers for the zone in the new class will be
+   the same as the name servers in the IN class.  The MIT Hesiod system
+   [Dyer87] used a scheme like this for storing data in the HS class,
+   but only on a very small scale (within a single institution), and
+   with an administrative fiat requiring that the delegation trees for
+   the IN and HS trees be identical.  The use of the HS class for such
+   storage of non-sensitive data was, over time, replaced by use of the
+   Lightweight Directory Access Protocol (LDAP) [RFC4511].
+
+   Even when using a different class, the data will still have to be
+   stored in some Resource Record Type that has an appropriate format.
+
+3.5.  Add a New Resource Record Type
+
+   When adding a new Resource Record Type to the system, entities in
+   four different roles have to be able to handle the new Type:
+
+   1.  There must be a way to insert the new Resource Records into the
+       zone at the Primary Master name server.  For some server
+       implementations, the user interface only accepts Resource Record
+       Types that it understands (perhaps so that the implementation can
+       attempt to validate the data).  Other implementations allow the
+       zone administrator to enter an integer for the Resource Record
+       Type code and the RDATA in Base64 or hexadecimal encoding (or
+       even as raw data).  RFC 3597 [RFC3597] specifies a standard
+       generic encoding for this purpose.
+
+   2.  A slave authoritative name server must be able to do a zone
+       transfer, receive the data from some other authoritative name
+       server, and serve data from the zone even though the zone
+       includes records of unknown Resource Record Types.  Historically,
+       some implementations have had problems parsing stored copies of
+       the zone file after restarting, but those problems have not been
+       seen for a few years.  Some implementations use an alternate
+
+
+
+IAB, et al.                  Informational                      [Page 8]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+       mechanism (e.g., LDAP) to transfer Resource Records in a zone,
+       and are primarily used within corporate environments; in this
+       case, name servers must be able to transfer new Resource Record
+       Types using whatever mechanism is used.  However, today this
+       alternative mechanism may not support unknown Resource Record
+       Types.  Hence, in Internet environments, unknown Resource Record
+       Types are supported, but in corporate environments they are
+       problematic.
+
+   3.  A caching resolver (most commonly a recursive name server) will
+       cache the records that are responses to queries.  As mentioned in
+       RFC 3597 [RFC3597], there are various pitfalls where a recursive
+       name server might end up having problems.
+
+   4.  The application must be able to get the RRSet with a new Resource
+       Record Type.  The application itself may understand the RDATA,
+       but the resolver library might not.  Support for a generic
+       interface for retrieving arbitrary DNS Resource Record Types has
+       been a requirement since 1989 (see Section 6.1.4.2 of [RFC1123]).
+       Some stub resolver library implementations neglect to provide
+       this functionality and cannot handle unknown Resource Record
+       Types, but implementation of a new stub resolver library is not
+       particularly difficult, and open source libraries that already
+       provide this functionality are available.
+
+   Historically, adding a new Resource Record Type has been very
+   problematic.  The review process has been cumbersome, DNS servers
+   have not been able to handle new Resource Record Types, and firewalls
+   have dropped queries or responses with Resource Record Types that are
+   unknown to the firewall.  This is, for example, one of the reasons
+   the ENUM standard reuses the NAPTR Resource Record, a decision that
+   today might have gone to creating a new Resource Record Type instead.
+
+   Today, there is a requirement that DNS software handle unknown
+   Resource Record Types, and investigations have shown that software
+   that is deployed, in general, does support it, except in some
+   alternate mechanisms for transferring Resource Records such as LDAP,
+   as noted above.  Also, the approval process for new Resource Record
+   Types has been updated [RFC5395] so the effort that is needed for
+   various Resource Record Types is more predictable.
+
+4.  Zone Boundaries are Invisible to Applications
+
+   Regardless of the possible choices above, we have seen a number of
+   cases where the application made assumptions about the structure of
+   the namespace and the location where specific information resides.
+   We take a small sidestep to argue against such approaches.
+
+
+
+
+IAB, et al.                  Informational                      [Page 9]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   The DNS namespace is a hierarchy, technically speaking.  However,
+   this only refers to the way names are built from multiple labels.
+   DNS hierarchy neither follows nor implies administrative hierarchy.
+   Because of that, it cannot be assumed that data attached to a node in
+   the DNS tree is valid for the whole subtree.  Technically, there are
+   zone boundaries partitioning the namespace, and administrative
+   boundaries (or policy boundaries) may even exist elsewhere.
+
+   The false assumption has lead to an approach called "tree climbing",
+   where a query that does not receive a positive response (either the
+   requested RRSet was missing or the name did not exist) is retried by
+   repeatedly stripping off the leftmost label (climbing towards the
+   root) until the root domain is reached.  Sometimes these proposals
+   try to avoid the query for the root or the TLD level, but still this
+   approach has severe drawbacks:
+
+   o  Technically, the DNS was built as a query-response tool without
+      any search capability [RFC3467].  Adding the search mechanism
+      imposes additional burden on the technical infrastructure, in the
+      worst case on TLD and root name servers.
+
+   o  For reasons similar to those outlined in RFC 1535 [RFC1535],
+      querying for information in a domain outside the control of the
+      intended entity may lead to incorrect results and may also put
+      security at risk.  Finding the exact policy boundary is impossible
+      without an explicit marker, which does not exist at present.  At
+      best, software can detect zone boundaries (e.g., by looking for
+      SOA Resource Records), but some TLD registries register names
+      starting at the second level (e.g., CO.UK), and there are various
+      other "registry" types at second, third, or other level domains
+      that cannot be identified as such without policy knowledge
+      external to the DNS.
+
+   To restate, the zone boundary is purely a boundary that exists in the
+   DNS for administrative purposes, and applications should be careful
+   not to draw unwarranted conclusions from zone boundaries.  A
+   different way of stating this is that the DNS does not support
+   inheritance, e.g., an MX RRSet for a TLD will not be valid for any
+   subdomain of that particular TLD.
+
+5.  Why Adding a New Resource Record Type Is the Preferred Solution
+
+   By now, the astute reader might be wondering what conclusions to draw
+   from the issues presented so far.  We will now attempt to clear up
+   the reader's confusion by following the thought processes of a
+   typical application designer who wishes to store data in the DNS.
+   We'll show how such a designer almost inevitably hits upon the idea
+   of just using a TXT Resource Record, why this is a bad thing, and why
+
+
+
+IAB, et al.                  Informational                     [Page 10]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   a new Resource Record Type should be allocated instead.  We'll also
+   explain how the reuse of an existing Resource Record, including TXT,
+   can be made less harmful.
+
+   The overall problem with most solutions has to do with two main
+   issues:
+
+   o  No semantics to prevent collision with other use
+
+   o  Space considerations in the DNS message
+
+   A typical application designer is not interested in the DNS for its
+   own sake, but rather regards it as a distributed database in which
+   application data can be stored.  As a result, the designer of a new
+   application is usually looking for the easiest way to add whatever
+   new data the application needs to the DNS in a way that naturally
+   associates the data with a DNS name and does not require major
+   changes to DNS servers.
+
+   As explained in Section 3.4, using the DNS class system as an
+   extension mechanism is not really an option, and in fact, most users
+   of the system don't even realize that the mechanism exists.  As a
+   practical matter, therefore any extension is likely to be within the
+   IN class.
+
+   Adding a new Resource Record Type is the technically correct answer
+   from the DNS protocol standpoint (more on this below), but doing so
+   requires some DNS expertise, due to the issues listed in Section 3.5.
+   Consequently, this option is often rejected.  Note that according to
+   RFC 5395 [RFC5395], some Types require IETF Consensus, while others
+   only require a specification.
+
+   There is a drawback to defining new RR types that is worth
+   mentioning.  The Resource Record Type (RRTYPE) is a 16-bit value and
+   hence is a limited resource.  In order to prevent hoarding the
+   registry has a review-based allocation policy [RFC5395]; however,
+   this may not be sufficient if extension of the DNS by addition of new
+   RR types takes up significantly and the registry starts nearing
+   completion.  In that case, the trade-offs with respect to choosing an
+   extension mechanism may need to change.
+
+   The application designer is thus left with the prospect of reusing
+   some existing DNS Types within the IN class, but when the designer
+   looks at the existing Types, almost all of them have well-defined
+   semantics, none of which quite match the needs of the new
+   application.  This has not completely prevented proposals from
+
+
+
+
+
+IAB, et al.                  Informational                     [Page 11]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   reusing existing Resource Record Types in ways incompatible with
+   their defined semantics, but it does tend to steer application
+   designers away from this approach.
+
+   For example, Resource Record Type 40 was registered for the SINK
+   Resource Record Type.  This Resource Record Type was discussed in the
+   DNSIND working group of the IETF, and it was decided at the 46th IETF
+   to not move the I-D forward to become an RFC because of the risk of
+   encouraging application designers to use the SINK Resource Record
+   Type instead of registering a new Resource Record Type, which would
+   result in infeasibly large SINK RRsets.
+
+   Eliminating all of the above leaves the TXT Resource Record Type in
+   the IN class.  The TXT RDATA format is free form text, and there are
+   no existing semantics to get in the way.  Some attempts have been
+   made, for example, in [DNSEXT-DNS-SD], to specify a structured format
+   for TXT Resource Record Types, but no such attempt has reached RFC
+   status.  Furthermore, the TXT Resource Record can obviously just be
+   used as a bucket in which to carry around data to be used by some
+   higher-level parser, perhaps in some human-readable programming or
+   markup language.  Thus, for many applications, TXT Resource Records
+   are the "obvious" choice.  Unfortunately, this conclusion, while
+   understandable, is also problematic, for several reasons.
+
+   The first reason why TXT Resource Records are not well suited to such
+   use is precisely what makes them so attractive: the lack of pre-
+   defined common syntax or structure.  As a result, each application
+   that uses them creates its own syntax/structure, and that makes it
+   difficult to reliably distinguish one application's record from
+   others, and for its parser to avoid problems when it encounters other
+   TXT records.
+
+   Arguably, the TXT Resource Record is misnamed, and should have been
+   called the Local Container record, because a TXT Resource Record
+   means only what the data producer says it means.  This is fine, so
+   long as TXT Resource Records are being used by human beings or by
+   private agreement between data producer and data consumer.  However,
+   it becomes a problem once one starts using them for standardized
+   protocols in which there is no prior relationship between data
+   producer and data consumer.  If TXT records are used without one of
+   the naming modifications discussed earlier (and in some cases even if
+   one uses such naming mechanisms), there is nothing to prevent
+   collisions with some other incompatible use of TXT Resource Records.
+
+   This is even worse than the general subtyping problem described in
+   Section 3.1 because TXT Resource Records don't even have a
+   standardized selector field in which to store the subtype.  RFC 1464
+   [RFC1464] tried, but it was not a success.  At best, a definition of
+
+
+
+IAB, et al.                  Informational                     [Page 12]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   a subtype is reduced to hoping that whatever scheme one has come up
+   with will not accidently conflict with somebody else's subtyping
+   scheme, and that it will not be possible to mis-parse one
+   application's use of TXT Resource Records as data intended for a
+   different application.  Any attempt to impose a standardized format
+   within the TXT Resource Record format would be at least fifteen years
+   too late, even if it were put into effect immediately; at best, one
+   can restrict the syntax that a particular application uses within a
+   TXT Resource Record and accept the risk that unrelated TXT Resource
+   Record uses will collide with it.
+
+   Using one of the naming modifications discussed in Section 3.2 and
+   Section 3.3 would address the subtyping problem, (and have been used
+   in combinations with reuse of TXT record, such as for the dns/txt
+   lookup mechanism in Domain Keys Identified Mail (DKIM)) but each of
+   these approaches brings in new problems of its own.  The prefix
+   approach (that for example SRV Resource Records use) does not work
+   well with wildcards, which is a particular problem for mail-related
+   applications, since MX Resource Records are probably the most common
+   use of DNS wildcards.  The suffix approach doesn't have wildcard
+   issues, but, as noted previously, it does have synchronization and
+   update authorization issues, since it works by creating a second
+   subtree in a different part of the global DNS namespace.
+
+   The next reason why TXT Resource Records are not well suited to
+   protocol use has to do with the limited data space available in a DNS
+   message.  As alluded to briefly in Section 3.1, typical DNS query
+   traffic patterns involve a very large number of DNS clients sending
+   queries to a relatively small number of DNS servers.  Normal path MTU
+   discovery schemes do little good here because, from the server's
+   perspective, there isn't enough repeat traffic from any one client
+   for it to be worth retaining state.  UDP-based DNS is an idempotent
+   query, whereas TCP-based DNS requires the server to keep state (in
+   the form of TCP connection state, usually in the server's kernel) and
+   roughly triples the traffic load.  Thus, there's a strong incentive
+   to keep DNS messages short enough to fit in a UDP datagram,
+   preferably a UDP datagram short enough not to require IP
+   fragmentation.
+
+   Subtyping schemes are therefore again problematic because they
+   produce larger Resource RRSets than necessary, but verbose text
+   encodings of data are also wasteful since the data they hold can
+   usually be represented more compactly in a Resource Record designed
+   specifically to support the application's particular data needs.  If
+   the data that need to be carried are so large that there is no way to
+   make them fit comfortably into the DNS regardless of encoding, it is
+   probably better to move the data somewhere else, and just use the DNS
+   as a pointer to the data, as with NAPTR.
+
+
+
+IAB, et al.                  Informational                     [Page 13]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+6.  Conclusion and Recommendation
+
+   Given the problems detailed in Section 5, it is worth reexamining the
+   oft-jumped-to conclusion that specifying a new Resource Record Type
+   is hard.  Historically, this was indeed the case, but recent surveys
+   suggest that support for unknown Resource Record Types [RFC3597] is
+   now widespread in the public Internet, and because of that, the DNS
+   infrastructure can handle new Resource Record Types.  The lack of
+   support for unknown Types remains an issue for relatively old
+   provisioning software and in corporate environments.
+
+   Of all the issues detailed in Section 3.5, provisioning the data is
+   in some respects the most difficult.  Investigations with zone
+   transfers show that the problem is less difficult for the
+   authoritative name servers themselves than the front-end systems used
+   to enter (and perhaps validate) the data.  Hand editing does not work
+   well for maintenance of large zones, so some sort of tool is
+   necessary, and the tool may not be tightly coupled to the name server
+   implementation itself.  Note, however, that this provisioning problem
+   exists to some degree with any new form of data to be stored in the
+   DNS, regardless of data format, Resource Record type (even if TXT
+   Resource Record Types are in use), or naming scheme.  Adapting front-
+   end systems to support a new Resource Record Type may be a bit more
+   difficult than reusing an existing type, but this appears to be a
+   minor difference in degree rather than a difference in kind.
+
+   Given the various issues described in this note, we believe that:
+
+   o  there is no magic solution that allows a completely painless
+      addition of new data to the DNS, but
+
+   o  on the whole, the best solution is still to use the DNS Resource
+      Record Type mechanism designed for precisely this purpose,
+      whenever possible, and
+
+   o  of all the alternate solutions, the "obvious" approach of using
+      TXT Resource Records for arbitrary names is almost certainly the
+      worst, especially for the two reasons outlined above (lack of
+      semantics and its implementations, and size leading to the need to
+      use TCP).
+
+7.  Creating a New Resource Record Type
+
+   The process for creating a new Resource Record Type is specified in
+   RFC 5395 [RFC5395].
+
+
+
+
+
+
+IAB, et al.                  Informational                     [Page 14]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+8.  Security Considerations
+
+   DNS RRSets can be signed using DNSSEC.  DNSSEC is almost certainly
+   necessary for any application mechanism that stores authorization
+   data in the DNS.  DNSSEC signatures significantly increase the size
+   of the messages transported, and because of this, the DNS message
+   size issues discussed in Sections 3.1 and 5 are more serious than
+   they might at first appear.
+
+   Adding new Resource Record Types (as discussed in Section 3.5) can
+   create two different kinds of problems: in the DNS software and in
+   applications.  In the DNS software, it might conceivably trigger bugs
+   and other bad behavior in software that is not compliant with RFC
+   3597 [RFC3597], but most such DNS software is old enough and insecure
+   enough that it should be updated for other reasons in any case.  In
+   applications and provisioning software, the changes for the new
+   features that need the new data in the DNS can be updated to
+   understand the structure of the new data format (regardless of
+   whether a new Resource Record Type is used or some other mechanism is
+   chosen).  Basic API support for retrieving arbitrary Resource Record
+   Types has been a requirement since 1989 [RFC1123].
+
+   Any new protocol that proposes to use the DNS to store data used to
+   make authorization decisions would be well advised not only to use
+   DNSSEC but also to encourage upgrades to DNS server software recent
+   enough not to be riddled with well-known exploitable bugs.
+
+9.  Acknowledgements
+
+   This document has been created over a number of years, with input
+   from many people.  The question on how to expand and use the DNS is
+   sensitive, and a document like this can not please everyone.  The
+   goal is instead to describe the architecture and tradeoffs, and make
+   some recommendations about best practices.
+
+   People that have helped include: Dean Anderson, Mark Andrews, John
+   Angelmo, Roy Badami, Dan Bernstein, Alex Bligh, Nathaniel Borenstein,
+   Stephane Bortzmeyer, Brian Carpenter, Leslie Daigle, Elwyn Davies,
+   Mark Delany, Richard Draves, Martin Duerst, Donald Eastlake, Robert
+   Elz, Jim Fenton, Tony Finch, Jim Gilroy, Olafur Gudmundsson, Eric
+   Hall, Phillip Hallam-Baker, Ted Hardie, Bob Hinden, Paul Hoffman,
+   Geoff Houston, Christian Huitema, Johan Ihren, John Klensin, Ben
+   Laurie, William Leibzon, John Levine, Edward Lewis, David MacQuigg,
+   Allison Mankin, Bill Manning, David Meyer, Pekka Nikander, Mans
+   Nilsson, Masataka Ohta, Douglas Otis, Michael Patton, Jonathan
+   Rosenberg, Anders Rundgren, Miriam Sapiro, Carsten Strotmann, Pekka
+   Savola, Chip Sharp, James Snell, Michael Thomas, Paul Vixie, Sam
+   Weiler, Florian Weimer, Bert Wijnen, and Dan Wing.
+
+
+
+IAB, et al.                  Informational                     [Page 15]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+10.  IAB Members at the Time of This Writing
+
+   Loa Andersson
+   Gonzalo Camarillo
+   Stuart Cheshire
+   Russ Housley
+   Olaf Kolkman
+   Gregory Lebovitz
+   Barry Leiba
+   Kurtis Lindqvist
+   Andrew Malis
+   Danny McPherson
+   David Oran
+   Dave Thaler
+   Lixia Zhang
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC1035]        Mockapetris, P., "Domain names - implementation and
+                    specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1464]        Rosenbaum, R., "Using the Domain Name System To
+                    Store Arbitrary String Attributes", RFC 1464,
+                    May 1993.
+
+   [RFC2535]        Eastlake, D., "Domain Name System Security
+                    Extensions", RFC 2535, March 1999.
+
+   [RFC2671]        Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+                    RFC 2671, August 1999.
+
+   [RFC3597]        Gustafsson, A., "Handling of Unknown DNS Resource
+                    Record (RR) Types", RFC 3597, September 2003.
+
+   [RFC5395]        Eastlake, D., "Domain Name System (DNS) IANA
+                    Considerations", BCP 42, RFC 5395, November 2008.
+
+11.2.  Informative References
+
+   [DNSEXT-DNS-SD]  Cheshire, S. and M. Krochmal, "DNS-Based Service
+                    Discovery", Work in Progress, September 2008.
+
+   [Dyer87]         Dyer, S. and F. Hsu, "Hesiod, Project Athena
+                    Technical Plan - Name Service", Version 1.9,
+                    April 1987.
+
+
+
+
+IAB, et al.                  Informational                     [Page 16]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   [RFC1123]        Braden, R., "Requirements for Internet Hosts -
+                    Application and Support", STD 3, RFC 1123,
+                    October 1989.
+
+   [RFC1535]        Gavron, E., "A Security Problem and Proposed
+                    Correction With Widely Deployed DNS Software",
+                    RFC 1535, October 1993.
+
+   [RFC2163]        Allocchio, C., "Using the Internet DNS to Distribute
+                    MIXER Conformant Global Address Mapping (MCGAM)",
+                    RFC 2163, January 1998.
+
+   [RFC2181]        Elz, R. and R. Bush, "Clarifications to the DNS
+                    Specification", RFC 2181, July 1997.
+
+   [RFC2672]        Crawford, M., "Non-Terminal DNS Name Redirection",
+                    RFC 2672, August 1999.
+
+   [RFC3445]        Massey, D. and S. Rose, "Limiting the Scope of the
+                    KEY Resource Record (RR)", RFC 3445, December 2002.
+
+   [RFC3467]        Klensin, J., "Role of the Domain Name System (DNS)",
+                    RFC 3467, February 2003.
+
+   [RFC3761]        Faltstrom, P. and M. Mealling, "The E.164 to Uniform
+                    Resource Identifiers (URI) Dynamic Delegation
+                    Discovery System (DDDS) Application (ENUM)",
+                    RFC 3761, April 2004.
+
+   [RFC4033]        Arends, R., Austein, R., Larson, M., Massey, D., and
+                    S. Rose, "DNS Security Introduction and
+                    Requirements", RFC 4033, March 2005.
+
+   [RFC4034]        Arends, R., Austein, R., Larson, M., Massey, D., and
+                    S. Rose, "Resource Records for the DNS Security
+                    Extensions", RFC 4034, March 2005.
+
+   [RFC4035]        Arends, R., Austein, R., Larson, M., Massey, D., and
+                    S. Rose, "Protocol Modifications for the DNS
+                    Security Extensions", RFC 4035, March 2005.
+
+   [RFC4511]        Sermersheim, J., "Lightweight Directory Access
+                    Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4592]        Lewis, E., "The Role of Wildcards in the Domain Name
+                    System", RFC 4592, July 2006.
+
+
+
+
+
+IAB, et al.                  Informational                     [Page 17]
+
+RFC 5507         Design Choices When Expanding the DNS        April 2009
+
+
+   [RFC4871]        Allman, E., Callas, J., Delany, M., Libbey, M.,
+                    Fenton, J., and M. Thomas, "DomainKeys Identified
+                    Mail (DKIM) Signatures", RFC 4871, May 2007.
+
+Authors' Addresses
+
+   Internet Architecture Board
+
+   EMail: iab@iab.org
+
+
+   Patrik Faltstrom (editor)
+
+   EMail: paf@cisco.com
+
+
+   Rob Austein (editor)
+
+   EMail: sra@isc.org
+
+
+   Peter Koch (editor)
+
+   EMail: pk@denic.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB, et al.                  Informational                     [Page 18]
+