[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                       P. Faltstrom
Internet-Draft                                                     Cisco
Expires: November 12, 2004                                    R. Austein
                                                                      ISC
                                                             May 14, 2004


                    Design Choices When Expanding DNS
                      draft-ymbk-dns-choices-00.txt

Status of this Memo

    By submitting this Internet-Draft, I certify that any applicable
    patent or other IPR claims of which I am aware have been disclosed,
    and any of which I become aware will be disclosed, in accordance with
    RFC 3668.

    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 November 12, 2004.

Copyright Notice

    Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

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






Faltstrom & Austein    Expires November 12, 2004                [Page 1]


Internet-Draft     Design Choices When Expanding DNS            May 2004


Table of Contents

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
    2.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  3
    3.  Extension mechanisms . . . . . . . . . . . . . . . . . . . . .  3
      3.1   Place selectors inside the RDATA . . . . . . . . . . . . .  4
      3.2   Add a prefix to the owner name . . . . . . . . . . . . . .  4
      3.3   Add a suffix to the owner name . . . . . . . . . . . . . .  5
      3.4   Add a new Class  . . . . . . . . . . . . . . . . . . . . .  5
      3.5   Add a new Resource Record Type . . . . . . . . . . . . . .  6
    4.  The case against protocol use of TXT RRs . . . . . . . . . . .  6
    5.  Conclusion and Recommendation  . . . . . . . . . . . . . . . .  8
    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
    7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
        Intellectual Property and Copyright Statements . . . . . . . . 11


































Faltstrom & Austein    Expires November 12, 2004                [Page 2]


Internet-Draft     Design Choices When Expanding DNS            May 2004


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

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

    Historically, extension of DNS to store data for applications tied to
    a domain name has been done in different ways at different times.  MX
    records were created as a new 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 the way of adding
    new data to the DNS has 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.

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 update, clarify, and extend the base specification.

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

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.




Faltstrom & Austein    Expires November 12, 2004                [Page 3]


Internet-Draft     Design Choices When Expanding DNS            May 2004


3.1  Place selectors inside the RDATA

    For a given query name, one might choose to have a single RRset (all
    sharing the same name, type, and class) shared by multiple
    applications, and have the different applications use selectors
    within the RR 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.

    Examples of subtyping include NAPTR RRs (see RFC 2916 [RFC2916]) and
    the original DNSSEC KEY RR type (RFC 2535 [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 in which it is interested.  Furthermore, since DNSSEC
    signatures operate on complete RRsets, the entire RRset must be
    re-signed if any RR in it changes.  As a result, each application
    that uses a subtyped RR 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 of clients to servers in the
    DNS system is very high, having a substantial number of DNS messages
    fail over to TCP it will cause the relevant name servers to be
    "nibbled to death by ducks".

    The final result of using a subtyping scheme might be that the zone
    administrator has to choose which of the services tied to one domain
    name can actually be used, because not all of them will be usable at
    the same time.

3.2  Add a prefix to the owner name

    By adding an application-specific prefix to a domain name, we will
    get different name/class/type triples, and therefore different
    RRsets.  The 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", but DNS wildcards only work with the "*"
    as the leftmost token in the domain name.




Faltstrom & Austein    Expires November 12, 2004                [Page 4]


Internet-Draft     Design Choices When Expanding DNS            May 2004


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

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.  The query name can be set to exactly the
    data one wants, and the size of the RRset is minimized.  The problem
    with adding a suffix is that it creates a parallel tree within the IN
    class.  There will be 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.

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

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) 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 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 or another.  This RR type can either be a



Faltstrom & Austein    Expires November 12, 2004                [Page 5]


Internet-Draft     Design Choices When Expanding DNS            May 2004


    "kitchen-sink record" or a new RR 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 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 in a
        Master authoritative name servers.  For some server
        implementations, the user interface only accepts record 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 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.  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 resolver 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 be able to get the record 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 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 and cannot handle unknown RR 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.  The case against protocol use of TXT RRs

    By now, the astute reader will be wondering about the apparent
    disconnect between the title of this note and 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 stuff in the DNS, showing how such a designer almost
    inevitably hits upon the idea of just using TXT RR, and why this is a



Faltstrom & Austein    Expires November 12, 2004                [Page 6]


Internet-Draft     Design Choices When Expanding DNS            May 2004


    bad thing.

    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 is the technically correct answer from the DNS
    protocol standpoint (more on this below), doing so requires some DNS
    expertise, due to the issues listed in Section 3.5.  As a result,
    this option is usually considered too hard.

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

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

    The first reason why TXT RRs are not well suited to such use is
    precisely the lack of defined semantics that make them so attractive.
    Arguably, the TXT RR is misnamed, and should have been called the
    Humpty Dumpty record, because the lack of defined semantics means
    that a TXT RR means precisely what the data producer says it means.
    This is fine, so long as TXT RRs are being used by human beings or by
    private agreement between data producer and data consumer.  However,
    once one starts using them for standardized protocols in which there
    is no prior relationship between data producer and data consumer, the
    lack of defined semantics becomes a problem, because there is nothing



Faltstrom & Austein    Expires November 12, 2004                [Page 7]


Internet-Draft     Design Choices When Expanding DNS            May 2004


    to prevent collisions some other incompatible use of TXT RRs.  This
    is even worse than the general subtyping problem described in Section
    3.1, because TXT RRs don't even have a standardized selector field in
    which to store the subtype.  At best one is reduced to hoping that
    whatever subtyping 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 as data
    intended for a different application.  Any attempt to come up with a
    standardized format within the TXT RR format would be at least
    fifteen years too late even if it were put into effect immediately.

    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 SRV RRs use) does not work well with wildcards, which is a
    particular problem for mail-related applications, since MX RRs 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 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
    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.

5.  Conclusion and Recommendation

    Given the problems detailed in Section 4, it is worth reexamining the



Faltstrom & Austein    Expires November 12, 2004                [Page 8]


Internet-Draft     Design Choices When Expanding DNS            May 2004


    oft-jumped-to conclusion that specifying a new RR type is hard.
    Historically, this was indeed the case, but recent surveys suggest
    that support for unknown RR types [RFC3597] is now widespread, and
    that lack of support for unknown 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.  In particular, 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.

    Of all the issues detailed in Section 3.5, provisioning the data is
    in some respects the most difficult.  The problem here is less 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 type, or naming scheme.  Adapting
    front-end systems to support a new RR 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.

6.  IANA Considerations

    This document does not require any IANA actions.

7.  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 itself.  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 are more
    serious than they might at first appear.

    Adding new RR types (as discussed in Section 3.5 might conceivably
    trigger bugs and other bad behavior in software which is not
    compliant with RFC 3597 [RFC3597], but most such software is old



Faltstrom & Austein    Expires November 12, 2004                [Page 9]


Internet-Draft     Design Choices When Expanding DNS            May 2004


    enough and insecure enough that it should be updated for other
    reasons in any case.  Basic API support for retrieving arbitrary RR
    types has been a requirement since RFC 1123 [RFC1123].

8  References

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

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

    [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
               RFC 2535, March 1999.

    [RFC2916]  Faltstrom, P., "E.164 number and DNS", RFC 2916, September
               2000.

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

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

    [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
               (RR) Types", RFC 3597, September 2003.


Authors' Addresses

    Patrik Faltstrom
    Cisco Systems, Inc.
    Ledasa
    Lovestad  273 71
    Sweden

    EMail: paf@cisco.com


    Rob Austein
    Internet Systems Consortium
    950 Charter Street
    Redwood City, CA  94063
    USA

    EMail: sra@isc.org




Faltstrom & Austein    Expires November 12, 2004               [Page 10]


Internet-Draft     Design Choices When Expanding DNS            May 2004


Intellectual Property Statement

    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.


Disclaimer of Validity

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


Copyright Statement

    Copyright (C) The Internet Society (2004).  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.


Acknowledgment

    Funding for the RFC Editor function is currently provided by the
    Internet Society.




Faltstrom & Austein    Expires November 12, 2004               [Page 11]