Re: DNS heirarchy, multiple roots, etc [was Re: Split the IANA functions?]

John C Klensin <john-ietf@jck.com> Tue, 07 January 2014 23:00 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5431AE0DA for <ietf@ietfa.amsl.com>; Tue, 7 Jan 2014 15:00:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.838
X-Spam-Level:
X-Spam-Status: No, score=-2.838 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpsO7ynrRNZk for <ietf@ietfa.amsl.com>; Tue, 7 Jan 2014 15:00:10 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 30FC61AE015 for <ietf@ietf.org>; Tue, 7 Jan 2014 15:00:10 -0800 (PST)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1W0fcs-000604-70; Tue, 07 Jan 2014 17:59:58 -0500
Date: Tue, 07 Jan 2014 17:59:53 -0500
From: John C Klensin <john-ietf@jck.com>
To: Patrik Fältström <paf@frobbit.se>, Thomas Narten <narten@us.ibm.com>
Subject: Re: DNS heirarchy, multiple roots, etc [was Re: Split the IANA functions?]
Message-ID: <C73014CDDA02050C322DC7F9@JcK-HP8200.jck.com>
In-Reply-To: <F1995B65-C462-45CB-A761-FD325FC77697@frobbit.se>
References: <CAMm+LwinAb6+7BoMzwBWyu63vofndxK9VY6DSNN0Ykza4SxuMQ@mail.gmail.com> <52CB0010.5010407@gmail.com> <CAMm+LwhN8+z9q4KQXVY9bWA6TAqxx1=Qg0OUfK=VGCSDg5uWEA@mail.gmail.com> <DD618936-0D13-41F1-8D89-2E3171D864B5@istaff.org> <52CB31F4.3090703@cs.tcd.ie> <52CB987A.20300@cisco.com> <20140107144412.GB11068@mx1.yitter.info> <CAMm+Lwiqtsp13NeR0kXeWaN3SAn7856_5VtopwMP1JWw0ohzVg@mail.gmail.com> <20140107173942.GE11538@mx1.yitter.info> <201401071848.s07ImHqx004058@cichlid.raleigh.ibm.com> <F1995B65-C462-45CB-A761-FD325FC77697@frobbit.se>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: "ietf@ietf.org Discussion" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2014 23:00:12 -0000

--On Tuesday, January 07, 2014 20:20 +0100 Patrik Fältström
<paf@frobbit.se> wrote:

> On 7 jan 2014, at 19:48, Thomas Narten <narten@us.ibm.com>
> wrote:
> 
>> So any talk about having a different/better naming scheme is
>> really just wishful thinking and a mostly a waste of
>> everybody's time. If there was a better system, some set of
>> smart folk would surely have already clued the rest of us in
>> on what that was. Anyone remember Tim Bass?
> 
> On top of that (if you look at some arguments that "change is
> needed") I would like to know what the problem really is. And
> yes, I am happy(?) to, and have tried to, understand what the
> problem is.
> 
> As others have explained, often "the problem" has to do with
> misunderstanding of how Internet and DNS works. In other cases
> it has to do with real issues, like the actual decision making
> process for what strings can exist.
> 
> When knowing what the problem is, there is often not much
> disagreement on the fact improvements can be made. But more
> disagreements in what the best path forward is. But THAT
> discussion is much more fruitful and effective than just
> saying "things must change".

While agreeing with this and with most of Thomas's and Andrew's
comments, I think there are a few substantive problems that can
be easily identified and that keep coming back (I do not
consider arguments about who controls the root of a strict
hierarchy to be substantive, no matter how entertaining they
become).   Most of them are associated with expectations of the
DNS that it, as a strictly hierarchical system with one name per
node, one-way links, and fairly weak aliases, cannot satisfy.  

For example, we see repeated requests (or "requirements",
demands, or fantasies) about treating two (or more) names as so
identical that retrievals or actions that affect one of them
affect the others.  It is certainly within the state of the art
to do that in a strictly hierarchical  system.  Hierarchical
database and file systems with support for those relationships
have been around for close to 50 years if not longer.  But it
isn't a modification that can be patched into the DNS -- it just
isn't going to happen without replacing the DNS.  Some of the
people who make those requests can be educated; others prefer to
believe that, if only they repeat their demands often enough and
loudly enough, they will get their way.

Similarly, we see repeated requests (etc.) for search and
matching systems that are context-dependent based on either
locations in the hierarchy or hints/ specifications stored in
the hierarchy itself.  Again, it is possible to design a
hierarchical system to do that but almost certainly not possible
to retrofit it into the current DNS.  

There are other examples, typically involving other types of
search and matching procedures, that can't be done in the DNS
because they are incompatible with a strict hierarchy.  Using
them would either require replacing the DNS with something
entirely different (and probably less suitable for unique
identifiers of network objects) or layering a separate system on
top of the DNS (depending on one's perspective, it could be
argued that contemporary search engines serve that role and the
problem is solved).

I suggest that the things that these examples and others have in
common are:

(i) They cannot be realized within the DNS as we know it, even
if some hypothetical replacement system could accommodate some
or all of them.

(ii) Under the best of circumstances, deploying a replacement
system would be a long, slow, and painful process.  Independent
of the difficulty of deploying such a system (including thinking
through transition issues), it is almost certain that taking
advantage of the requested features of a new system would
require different parameters in the query/lookup process and
that would, in turn, require updating every application on the
Internet.

(iii) The people advocating the changes implied by those
examples are either ignorant of the reasons for (i) and (ii) or
aren't willing to admit to and deal with those reasons.

(iv) When we have tried to stimulate interest in the community
about various solutions and approaches, including the "above
DNS" ones that are, IMO, the most plausible from a deployment
and adoption standpoint, we generally discover that there isn't
any such interest, especially once people understand what would
actually be involved.

best,
   john