Network Working Group                                       P. Faltstrom                                                IAB
Internet-Draft                                                     Cisco                                         P. Faltstrom, Ed.
Intended status: Informational                          October 23, 2006 Standards Track                         R. Austein, Ed.
Expires: April 26, 2007 August 21, 2008                                    P. Koch, Ed.
                                                       February 18, 2008

                   Design Choices When Expanding DNS
                      draft-iab-dns-choices-04.txt
                        draft-iab-dns-choices-05

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 26, 2007. August 21, 2008.

Copyright Notice

   Copyright (C) The Internet Society (2006). IETF Trust (2008).

Abstract

   This note discusses how to extend the DNS with new data for a new
   application.  DNS extension discussion discussions too often circulates around focus on reuse of
   the TXT record. Resource Record Type.  This document lists different
   mechanisms to
   accomplish extend the extension to DNS, and comes to the conclusion concludes that the use of a new RR DNS
   Resource Record Type is the best solution.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Extension mechanisms . . . . . . . . . . . . . . . . . . . . .  4  5
     3.1.  Place selectors inside the RDATA of existing Resource
           Record Types . . . . . . . . . . . . .  4 . . . . . . . . . .  5
     3.2.  Add a prefix to the owner name . . . . . . . . . . . . . .  5
     3.3.  Add a suffix to the owner name . . . . . . . . . . . . . .  6
     3.4.  Add a new Class  . . . . . . . . . . . . . . . . . . . . .  6  7
     3.5.  Add a new Resource Record Type . . . . . . . . . . . . . .  7
   4.  Conclusion (why  Zone boundaries are invisible to applications  . . . . . . . .  8
   5.  Why adding a new RR type Resource Record Type is the answer) preferred
       solution . . . . . . .  8
   5.  Conclusion and Recommendation . . . . . . . . . . . . . . . . 10
   6.  New Resource Record Type . . . .  9
   6.  Conclusion and Recommendation  . . . . . . . . . . . . . . . . 11 12
   7.  Creating A New Resource Record Type  . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8. 13
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   9. 13
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   10. 13
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. 14
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     10.2. 14
     11.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Author's Address . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 15 16

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 records) Resource Records) and data which have to do with mappings
   between domain names and IP addresses (A, AAAA and PTR). PTR Resource
   Records).  There are other categories as well, some of which are tied
   to specific applications like email (MX), (MX Resource Records), while
   others are generic record types Resource Record Types used to convey information
   for multiple protocols (SRV, NAPTR). (SRV and NAPTR Resource Records).

   When storing data in the DNS for a new application, the data are
   usually tied to a "normal" domain name, so that the application can
   query for the data it wants, while minimizing the impact on existing
   applications.

   Historically, extending DNS to store application data for applications tied to a
   domain name has been done in different ways at different times.  MX
   records
   Resource Records were created as a new resource record type Resource Record Type
   specifically designed to support electronic mail.  SRV records are a
   generic type which use a prefixing scheme in combination with a base
   domain name.  Records associated with ENUM use a suffixing scheme.
   NAPTR records add selection data inside the RDATA.  It is clear that
   the way of adding methods used to add new data types to the DNS has 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 system.

   Many parts of this DNS.

   This document talk talks extensively about use of wildcards, and many DNS wildcards.  Many
   people might think use of wildcards is not something that happens
   today.  In reality thoug, though, wildcards are in use, especially for some
   specific usages like
   certain application-specific data such as MX records. Resource Records.
   Because of this, the choice have has to be made with existence of
   wildcards in mind.

   Another overall issue that have to must be taken into account is what the new
   data in the DNS is are to describe.  In some cases it they might be
   completely new data.  In other cases it they might be meta-data that is metadata tied to
   data that already exists exist in the DNS.  An example of new data is key
   information for SSH and data used for fighting spam (meta data that
   is connected (metadata tied to the
   MX record). Resource Records).  If the new data has connection are tied to data that already exists
   exist in the DNS, an analysis should be made as to whether having
   (for example) A record address records and SSH key information in different
   DNS zones is a problem, and if it is, whether the owner for the
   records by design specification must
   require all of the related data to be in the same for both records. zone.

   This document does not talk about what one should store in the DNS.
   It also doesn't discuss whether DNS is should be used for service
   discovery, or whether DNS is (also) should be used for storage of data specific
   for the service.  In general, DNS is a protocol that that, apart from
   holding metadata that makes the DNS itself function (NS, SOA, DS RR Types etc) DNSSEC
   Resource Record Types, etc), only holds references to where services are located service
   locations (SRV, NAPTR, A, AAAA RR types). Resource Record Types), but there are
   exceptions (such as MX Resource Records).

2.  Background

   See RFC 2929 [RFC2929] for a brief summary of 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 which
   that update, clarify, and extend the base specification.

   When composing a query against the DNS system, query, the parameters
   actually used by the protocol are a
   triple: a DNS name, a DNS class, and a DNS record type. Type.  Every resource record (RR)
   Resource Record matching a particular name, type and class is said to
   belong to the same
   resource record set (RRSet), "RRSet", and the whole RRSet is always returned to
   the client which that queries for it.  Splitting an RRSet is a protocol
   violation, because it results in coherency problems with the DNS
   caching mechanism.

   Some discussions around extensions to the DNS include arguments
   around MTU size.  Note that most of the discussions around about DNS and MTU size is
   are about the size of the whole DNS packet, and not about the size of an RRSet
   explicitly.  A a
   single RRSet.

   Almost all DNS packet query traffic is to carried over UDP, where a DNS message
   must fit in the MTU within a single UDP packet.  DNS response messages are
   almost always larger than DNS query messages, so message size when using UDP, 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 else EDNS0.  If a truncated response is given back from message won't fit in a single
   packet, the name server (at returns a truncated response, at which point
   the client can reissue the 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 is such that it
   blocks DNS over TCP). 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 create 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 name, type, and class) shared by
   multiple applications, and have the different applications use
   selectors within the RR 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 RR type. Resource
   Record Type.

   Examples of subtyping include NAPTR RRs Resource Records (see RFC 3761 [RFC3761])
   and the original DNSSEC KEY RR type (RFC 2535 [RFC2535]) Resource Record Type ([RFC2535]) (before
   it was updated by RFC 3445 [RFC3445]).

   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 RRs Resource Records in which it is interested.  Furthermore, since
   DNSSEC signatures operate on complete RRSets, the entire RRSet must
   be re-
   signed re-signed if any RR Resource Record in it changes.  As a result, each
   application that uses a subtyped RR 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 having one
   query fail over to TCP is not a big deal, but since the typical ratio
   of clients to servers in the today's deployed DNS system 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.

   To conclude, because of the limitations

   Because of the size limitations, using a subtyping scheme to list a
   large number of one RRSet is
   that not all services tied to for a single domain can be announced, but instead
   selected (by name risks triggering
   truncation and fallback to TCP, which may in turn force the zone administrator).  This because all
   administrator to announce only a subset of them can
   not be announced at the same time. 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 name/class/type triples, triple, and therefore a different RRSets. 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. name (see also [RFC4592]).

   Even when a specific prefix is chosen, the data will still have to be
   stored in some RR type. Resource Record Type.  This RR type Resource Record Type can
   either be a record type Type that can has an appropriate format to store arbitrary the
   data or a new RR type. Resource Record Type.  This implies that some other
   selection mechanism has to be applied as well, such as ability to
   distinguish between the records in an RR set RRSet given they have the same RR type (see also draft-ietf-dnsext-wcard-clarify
   [wcardclarify] regarding use of wildcards and DNS).
   Resource Record Type.  Because of this, one needs to both register a
   unique prefix and define what RR type Resource Record Type is to be used for
   this specific service.

   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 have has in the records.
   Example:  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
   because of this might be signed by two different organizations when
   using DNSSEC.

3.3.  Add a suffix to the owner name

   Adding a suffix to a domain name changes the name/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
   Resource Record Type specified in RFC 2672 [RFC2672].

   Even when using a different name, the data will still have to be
   stored in some RR type. Resource Record Type.  This RR type Resource Record Type can
   either be a "kitchen-sink record" or a new RR type. Resource Record Type.
   This implies that some other mechanism has to be applied as well,
   with implications detailed in other parts of this note.

   In RFC 2163 [RFC2163] an infix token is inserted directly below the TLD, but
   the result is the same as equivalent to adding a suffix to the owner name
   (and because of that creation
   (instead of creating a new TLD). TLD one is creating a second level domain).

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 RRs) Resource Records) is itself tied
   to a specific class, attempting to resolve a query by crossing a
   class boundary may produce unexpected results, 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
   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.

   Even when using a different class, the data will still have to be
   stored in some RR type Resource Record Type or another.  This RR type Resource Record
   Type can either be a "kitchen-sink record" or a new RR type. Resource Record
   Type.  This implies that some other mechanism has to be applied as
   well, with implications detailed in other parts of this note.

3.5.  Add a new Resource Record Type

   When adding a new Resource Record type Type to the system, entities in
   four different roles have to be able to handle the new type: Type:

   1.  There must be a way to insert the new resource records Resource Records into the
       zone of the Primary Master name server.  For some server
       implementations, the user interface only accepts record types Types
       which 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 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 types. 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.
   3.  A full service caching resolver (most commonly a recursive name server) will
       cache the records which 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 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 [RFC1123] Section 6.1.4.2).
       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.

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.

   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.
   That said, 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, 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 able identified as such without policy knowledge external to get the record with a new
       resource record type.  The application itself may understand
      the
       RDATA, but DNS.

   To restate, the resolver library might not.  Support for zone boundary is purely a generic
       interface for retrieving arbitrary boundary that exists in the
   DNS RR types has been a
       requirement since 1989 (see RFC 1123 [RFC1123] Section 6.1.4.2).

       Some stub resolver library implementations neglect to provide
       this functionality for administrative purposes, and cannot handle unknown RR types, but
       implementation applications should be careful
   not to draw unwarranted conclusions from zone boundaries.  A
   different way of a new stub resolver library stating this is that the DNS does not particularly
       difficult, and open source libraries support
   inheritance, e.g. a wildcard MX RRSet for a TLD will not be valid for
   any subdomain of that already provide this
       functionality are available.

4.  Conclusion (why particular TLD.

5.  Why adding a new RR type Resource Record Type is the answer) preferred solution

   By now, the astute reader will might be be wondering how what conclusions to use
   draw from all 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,
   showing how such a designer almost inevitably hits upon the idea of
   just using TXT RR, and Resource Record, why this is a bad thing, and instead why a
   new RR type is to Resource Record Type should be
   allocated. allocated instead.

   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 in the DNS message) message

   A typical application designer is not interested in the DNS for its
   own sake, but rather 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.

   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 RR type 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.
   As a result, this option is usually not considered.  Note that
   according to RFC2929 [RFC2929], some types Types require IETF Consensus, while
   others only require a specification.

   The application designer is thus left with the prospect of reusing
   some existing DNS type Type within the IN class, but when the designer
   looks at the existing types, 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 to reuse from
   reusing existing RR types Resource Record Types in ways incompatible with
   their defined semantics, but it does tend to steer application
   designers away from this approach.

   RR

   For example, Resource Record Type 40 was registered for the SINK
   record type. Type.  This RR 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.
   Reason was RFC because of the risk for large RR sets and the ability for of
   encouraging application
   creators designers to use the SINK RR Resource Record
   Type instead of registering a new RR
   Type. Resource Record Type, which would
   result in infeasibly large SINK RRsets.

   Eliminating all of the above leaves the TXT RR type 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.  Furthermore, the TXT RR
   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 RRs Resource Records are the "obvious" choice.
   Unfortunately, this conclusion, while understandable, is also wrong,
   for several reasons.

   The first reason why TXT RRs Resource Records are not well suited to such
   use is precisely the lack of defined semantics that make them so
   attractive.  Arguably, the TXT RR Resource Record is misnamed, and
   should have been called the Local Container record, because the lack
   of defined semantics means that a TXT RR Resource Record means precisely
   what the data producer says it means.  This is fine, so long as TXT RRs
   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.  Reason  The reason for this is that there is
   nothing to prevent collisions with some other incompatible use of TXT RRs.
   Resource Records.  This is even worse than the general subtyping
   problem described in Section 3.1, because TXT RRs Resource Records don't
   even have a standardized selector field in which to store the
   subtype.  RFC1464  [RFC1464] tried, but it was not a success.  At best a
   definition of 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 RRs Resource Records as data intended for a
   different application.  Any attempt to come up with impose a standardized format
   within the TXT RR Resource Record format would be at least fifteen years
   too late even if it were put into effect immediately. 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, but each of these
   approaches brings in new problems of its own.  The prefix approach
   (such as
   (that for example SRV RRs Resource Records use) does not work well with
   wildcards, which is a particular problem for mail-related
   applications, since MX RRs 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 name space.

   The next reason why TXT RRs 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, 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, 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 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.

5.

6.  Conclusion and Recommendation

   Given the problems detailed in Section 4, 5, it is worth reexamining the
   oft-jumped-to conclusion that specifying a new RR type Resource Record Type
   is hard.  Historically, this was indeed the case, but recent surveys
   suggest that support for unknown RR types Resource Record Types [RFC3597] is
   now widespread, and that lack of support for unknown types Types is mostly
   an issue for relatively old software that would probably need to be
   upgraded in any case as part of supporting a new application.  One
   should also remember that deployed DNS software today should support
   DNSSEC, and software recent enough to do so will have higher chance of being able
   to also likely support RFC3597. both
   unknown Resource Record Types [RFC3597] and EDNS0 [RFC2671].

   Of all the issues detailed in Section 3.5, provisioning the data is
   in some respects the most difficult.  The problem here 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, RR
   Resource Record type, or naming scheme.  Including the TXT Resource
   Record Type.  Adapting front-end systems to support a new RR 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 which 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 type
      mechanism designed for precisely this purpose, and
   o  of all the alternate solutions, the "obvious" approach of using
      TXT RRs is almost certainly the worst.
   This especially for the two reasons outlined above (lack of semantics
   and its implications, and size leading to the need to use TCP).

6.  New Resource Record Type

   Creation of a new resource record type is specified in RFC 2929
   [RFC2929].  Terminology is from RFC 2434 [RFC2434].  It is specified
   in RFC 2929 that not only standards track documents can specify new
   resource record types.  Also experimental or informational RFC is ok,
   and for some numbers "...RFC or other permanent and readily available
   reference...".

   The following are the rules applicable at the time of writing from
   BCP 42 and BCP 26 for various ranges of Resource Record Types.

   Type number 1-32767 require IETF Consensus:

      IETF Consensus - New values are assigned through the IETF
      consensus process.  Specifically, new assignments are made via
      RFCs approved by the IESG.  Typically, the IESG will seek input on
      prospective assignments from appropriate persons (e.g., a relevant
      Working Group if one exists).

      Examples: A record is number 1, and AXFR number 252.

   Type number 32768-65279 require specification:

      Specification Required - Values and their meaning must be
      documented in an RFC or other permanent and readily available
      reference, in sufficient detail so that interoperability between
      independent implementations magic solution which allows a completely painless
      addition of new data to the DNS, but
   o  on the whole, the best solution is possible.

      No still to use the DNS Resource
      Record types are registered in this range. Type number 65280-65535 is mechanism designed for private use:

      Private Use - For private or local use only, with the type precisely this purpose, and
      purpose defined by
   o  of all the local site.  No attempt alternate solutions, the "obvious" approach of using
      TXT Resource Records is made almost certainly the worst.
   This especially for the two reasons outlined above (lack of semantics
   and its implications, and size leading to prevent
      multiple sites from using the same value in different (and
      incompatible) ways.  There is no need for IANA to review such
      assignments and assignments are not generally useful use TCP).

7.  Creating A New Resource Record Type

   The process for
      interoperability. creating a new Resource records in this range Record Type is not registered centrally at
      IANA, and collissions may exist.

7. specified in
   [I-D.ietf-dnsext-2929bis].

8.  IANA Considerations

   This document does not require any IANA actions.

8.

9.  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 Section 3.1 and Section 4 5 are more serious
   than they might at first appear.

   Adding new RR types Resource Record Types (as discussed in Section 3.5) might
   conceivably trigger bugs and other bad behavior in software which that is
   not compliant with RFC 3597 [RFC3597], but most such software is old enough
   and insecure enough that it should be updated for other reasons in
   any case.  Basic API support for retrieving arbitrary RR
   types Resource Record
   Types has been a requirement since 1989 (see RFC 1123 [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.  Because
   of this, support for new RR Resource Record Types will not be as hard as
   people might think at first.

9.

10.  Acknowledgements

   This document has been created during 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, architecture and given this IAB have
   based a number of recommendations. tradeoffs, and make
   some recommendations about best practices.

   People that have helped include: Dean Andersson, Loa Andersson, Mark
   Andrews, Rob Austein, 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, Philip Hallam-Baker, Ted Hardie, Bob
   Hinden, Paul Hoffman, Geoff Houston, Christian Huitema, Johan Ihren,
   John Klensin, Peter
   Koch, Olaf Kolkman, Ben Laurie, William Leibzon, John Levine,
   Edward Lewis, David MacQuigg, Allison Manking, Bill Manning, Danny
   McPherson, David Meyer, Pekka Nikander, Masataka Ohta, Douglas Otis,
   Michael Patton, Jonathan Rosenberg, Anders Rundgren, Miriam Sapiro,
   Pekka Savola, Chip Sharp, James Snell, Dave Thaler, Michael Thomas,
   Paul Vixie, Sam Weiler, Florian Weimer, Bert Wijnen, and Dan Wing Wing.

   Members of the IAB when this document was made available were:
   Bernard Aboba, Loa Andesson, Brian Carpender,
   Andersson, Leslie Daigle, Elwyn Davies, Kevin Fall, Russ Housley,
   Olaf Kolkman, Barry Leiba, Kurtis Lindqvist, David Meyer, Danny McPherson, David
   Oran, Eric Rescorla, Dave Thaler, and Lixia Zhang.

10.

11.  References

10.1.

11.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, STD 13, November 1987.

   [RFC1464]  Rosenbaum, R., "Using the Domain Name System To Store
              Arbitrary String Attributes", RFC 1464, May 1993.

   [RFC2535]  Eastlake,  Eastlake 3rd, 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.

10.2.

11.2.  Informative References

   [I-D.ietf-dnsext-2929bis]
              3rd, D., "Domain Name System (DNS) IANA Considerations",
              draft-ietf-dnsext-2929bis-06 (work in progress),
              August 2007.

   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
              and Support", STD 3, RFC 1123, STD 3, October 1989.

   [RFC2163]  Allocchio, C., "Using the Internet DNS to Distribute MIXER
              Conformant Global Address Mapping (MCGAM)", RFC 2163,
              January 1998.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
              Names", BCP 32, RFC 2606, June 1999.

   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
              RFC 2672, August 1999.

   [RFC2929]  Eastlake,  Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
              "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
              BCP 42, September 2000.

   [RFC3232]  Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
              an On-line Database", RFC 3232, January 2002.

   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
              Resource Record (RR)", RFC 3445, December 2002.

   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
              Considered Useful", BCP 82,

   [RFC3467]  Klensin, J., "Role of the Domain Name System (DNS)",
              RFC 3692, January 2004. 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.

   [wcardclarify]

   [RFC4592]  Lewis, E., "draft-ietf-dnsext-wcard-clarify-11.txt, The "The Role of Wild Card Domains Wildcards in the Domain Name System, work
              in progress", March
              System", RFC 4592, July 2006.

Author's Address

Authors' Addresses

   Internet Architecture Board

   Email: iab@iab.org

   Patrik Faltstrom
   Cisco (editor)

   Email: paf@cisco.com

   Rob Austein (editor)

   Email: sra@isc.org

   Peter Koch (editor)

   Email: pk@denic.de

Full Copyright Statement

   Copyright (C) The Internet Society (2006). IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).