IETF                                                         A. Sullivan
Internet-Draft                                                       Dyn
Intended status: Informational                         February 14, 2014
Expires: August 18, 2014

 By Any Other Name: Considerations on DNS, Other Naming Protocols, and
                   the Hierarchical Domain Name Space


   You should probably not read this.  It's not done.

   Not every domain name is intended to appear in the global DNS.  It is
   also possible that not everything that looks like a domain name is
   intended to be one.  Regardless of whether a given name is intended
   to appear in the DNS, such names often turn up in domain name slots.
   When choosing a naming scheme that is not intended to be part of the
   global DNS, it is necessary to understand the architectural
   implications of using domain names or a domain-name-like syntax.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 18, 2014.

Copyright Notice

   Copyright (c) 2014 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.  Please review these documents

Sullivan                 Expires August 18, 2014                [Page 1]

Internet-Draft             Namespaces and DNS              February 2014

   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  PseudoTLDs, Real Names  . . . . . . . . . . . . . . . . . . .   3
   3.  Is a Common Namespace a Good Idea?  . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Informative References  . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Not every domain name appears in the global DNS, and many domain
   names are not intended for use in the global DNS.  At the very least,
   as [RFC6590] acknowledges, it is only pragmatic to recognize the
   existence of split-horizon DNS deployments; these often include so-
   called "private names".

   At the same time, as [RFC2826] is at pains to say, the global DNS
   requires a globally unique public name space.  This means that the
   set of labels near the root of the tree need to be shared by
   everyone, or the root itself becomes suspect.  Private namespaces are
   fine, but not if they conflict with the public namespace.

   Some recent developments have revealed the deep tension in this
   approach to the namespace.  Three factors in particular seem to be

   First, while historically the DNS root zone was mostly stable and
   changed quite slowly when it did change, the decision to expand the
   root zone dramatically does away with that historic stability.  More
   than a thousand new TLDs are expected in the root zone as of this
   writing.  In some cases, the changes make old assumptions about what
   is or is not a top-level domain obsolete; but in any case, the new
   root zone management policy makes keeping static lists of TLDs even
   worse than it used to be.

   Second, the arrival of IDNA in the root zone means that protocols
   that rely on plain UTF-8 labels in the DNS may lead to ambiguous
   results, if the IDNA version of a zone and the "raw UTF-8" version of
   a zone become somehow unsynchronized.  While from the DNS point of

Sullivan                 Expires August 18, 2014                [Page 2]

Internet-Draft             Namespaces and DNS              February 2014

   view, these zones are unrelated to one another, from any user's point
   of view the zones should be the same thing.

   Finally, and perhaps most importantly, a number of protocols have
   emerged that use either domain names, or else strings that appear to
   be just like domain names in most contexts, without relying on the
   public DNS.  (There is an argument to be made that in at least some
   cases these names are not domain names, because they do not actually
   have the same restrictions.  They may not, for example, restrict
   length to 63 octets per label.  For the purposes of the present
   discussion, this distinction makes no difference.)  For the present
   purpose, the most interesting of these cases are the ones which use
   so-called pseudo-top-level-domains (pseudoTLDs) to call out that a
   namespace has been shifted out of the DNS space and into some other

   These different threads suggest that some careful thinking about name
   spaces is in order.  This text, alas, is not that; indeed, at the
   moment it's little more than a jumble of ill-organized thoughts
   around this topic, and groping towards some coherence.  But I hope to
   initiate some thoughts about whether domain names, and the domain
   name system, provide the right foundation for future name space use.

2.  PseudoTLDs, Real Names

   The idea of a pseudoTLD is fetching.  With such a top level domain
   (TLD), one uses the right-most label of a domain name as a sort of
   protocol shifter, to indicate that while the namespace is still the
   same domain name space, the name is not to be looked up in the DNS.
   This strategy is not novel.  For instance, Multicast DNS [RFC6762]
   uses the "local" TLD as such an indicator.  Prior to the registration
   of local as a Special-Use Domain Name [RFC6761], local was a

   In the era of a dynamic DNS root zone, the idea that pseudoTLDs can
   be used safely without co-ordination with the public root zone is a
   delusion.  If a given pseudo use for a TLD takes off, it seems likely
   that there will be commercial pressures in favour of registration of
   the pseudoTLD in the root zone (i.e. as a "real" TLD) in an effort to
   gain automatic traffic.  At the same time, some of the pseudoTLDs
   appear to be attempts to undermine the operation of the existing root
   either with alternative resolution systems riding atop the DNS
   (sometimes with claims about additional security or privacy as a
   concomitant benefit).

   None of the issues with pseudoTLDs would matter, except that the
   expansion of the root zone has itself been fraught with political
   disagreements, and disputes about the costs of registrations.  There

Sullivan                 Expires August 18, 2014                [Page 3]

Internet-Draft             Namespaces and DNS              February 2014

   have also been the sorts of commercial tensions apparent whenever a
   scarce resource is divided up by commercial means.

   At least some of the pseudoTLDs could as easily be accommodated in a
   tree elsewhere in the DNS.  These cases would still be candidates for
   the Special-Use Domain Name registration; it is not clear why these
   cases need a top-level domain.  This issue may be a red herring,

3.  Is a Common Namespace a Good Idea?

   The basic issue that we are facing is not collisions with the DNS
   root namespace.  It is obvious that we could reserve chunks of the
   DNS namespace for private use in exactly the way number spaces do
   this (e.g., [RFC6890]).  The deeper architectural question is why, if
   there is such desire to do away with the limitations of the DNS, such
   systems start from the premise that the DNS and its namespace are the
   right foundation.  Oddly, the design of the DNS would appear to
   suggest another approach.

   Conceptually [RFC1034], the DNS name space is divided up not only by
   name, but also by class.  As a practical matter, on the Internet only
   the IN class is used.  But in principle, the DNS design permits a
   given namespace to be classed such that the same name could have
   completely different RDATA at every owner name, for the same RRTYPE,
   in each of two different classes.

   Unfortunately, because of the way CNAME is defined, the DNS classes
   do not really work.  CNAME processing does not restart the processing
   of a given name in a given class, but rather restarts the processing
   of a name alone.  For that reason, two DNS classes are not really
   completely separate name spaces.

   The resort to a pseudoTLD as a kind of shift bit to indicate a new
   resolution protocol signifies that what is really wanted is a new
   resolution class.  We have been down this road before.  The use of
   so-called underscore labels in DNS names as a mechanism for
   subdividing space under a TXT RRTYPE was in effect an attempt to lift
   the burden of deploying a new RRTYPE.  In that case, however, the
   desire was to publish data in the existing global DNS, without the
   hassle of making the global DNS work the way it was supposed to (by
   making it easy to deploy new RRTYPEs).

   The present case, of alternative name resolution systems, is
   different.  In this case, new resolution libraries all use the
   pseudoTLD as a trigger to spring into action.  The pseudoTLD isn't
   there for compatibility with the DNS; some proposals are in fact
   inimical to the DNS.  Instead, the DNS name space pattern is used

Sullivan                 Expires August 18, 2014                [Page 4]

Internet-Draft             Namespaces and DNS              February 2014

   because it is familiar.  This seems a poor reason to use an old-
   fashioned naming system that does not even support its own entire
   feature set.  And the fact that the pseudoTLDs are a flag that new
   resolution systems need to be used suggests that in fact new code to
   be deployed across systems is acceptable in these cases.  If true,
   that means that the traditional argument in favour of retaining the
   DNS -- its existing universal deployment -- is lost.  After all, if
   the new naming system does not work except for those who have
   installed the new system, what reason is there to saddle the new
   system with the compromises (and long, crufty history) of the DNS?

   The above suggests that a better goal would be to undertake the
   design of an improved naming system, incorporating lessons from the
   DNS as well as ideas from the new naming technologies and proposal.

4.  IANA Considerations

   This memo makes no requests of IANA.

5.  Security Considerations

   The security implications of the foregoing are as yet unknown.

6.  Informative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC2826]  Internet Architecture Board, "IAB Technical Comment on the
              Unique DNS Root", RFC 2826, May 2000.

   [RFC6590]  Falk, J. and M. Kucherawy, "Redaction of Potentially
              Sensitive Data from Mail Abuse Reports", RFC 6590, April

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, February 2013.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              February 2013.

   [RFC6890]  Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
              "Special-Purpose IP Address Registries", BCP 153, RFC
              6890, April 2013.

Sullivan                 Expires August 18, 2014                [Page 5]

Internet-Draft             Namespaces and DNS              February 2014

Author's Address

   Andrew Sullivan
   150 Dow St.
   Manchester, NH  03101


Sullivan                 Expires August 18, 2014                [Page 6]