Re: new DNS classes or anything else

John C Klensin <> Wed, 05 July 2017 12:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60F521329C5 for <>; Wed, 5 Jul 2017 05:32:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a01bhhQC7FAg for <>; Wed, 5 Jul 2017 05:32:04 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6D1D131CD4 for <>; Wed, 5 Jul 2017 05:32:04 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1dSjTK-000DF3-4p; Wed, 05 Jul 2017 08:31:58 -0400
Date: Wed, 05 Jul 2017 08:31:53 -0400
From: John C Klensin <>
To: John Levine <>,
Subject: Re: new DNS classes or anything else
Message-ID: <>
In-Reply-To: <20170705013931.67812.qmail@ary.lan>
References: <20170705013931.67812.qmail@ary.lan>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Jul 2017 12:32:06 -0000

--On Wednesday, July 05, 2017 1:39 AM +0000 John Levine
<> wrote:

> In article <> you
> write:
>> Having enough of the world get aggravated enough at ICANN (or
>> some other entity of one's choice) to make general adoption of
>> an alternate root plausible is another matter and I don't
>> think we are there, at least yet.
> Here in the IETF we are so close to ICANN that we suffer from
> sample bias.  To the extent the outside world is even aware of
> ICANN, they see that .com, .org, .net, and the large ccTLDs
> all work, registering in them is straightforward and not too
> expensive, and everything else is noise.  One advantage of
> ICANN's turgid bureaucratic processes is that it makes it
> unlikely that they will do anything seriously destructive
> because it would be too hard.

Were ICANN be the source of a serious problem (see below), I
think it would be far more likely to be the result of a "can't
say 'no'" failure of those processes that allows something
seriously destructive to occur than the result of an affirmative
decision to do something.  I think we've had some near-misses in
that regard, YMMD.  Beyond that, I could quibble, but, in the
interest of brevity, won't.

> We all know how to run our own roots if that's what we want to
> do, but I continue to observe approximately none of us doing
> it.

Completely consistent with my earlier comment.  I think. or at
least hope, that we all understand the advantages of a single
and unique root (those who don't might want to review RFC 2826).
An alternate root is a tipping-point problem.  For one to be
plausible, there would have to be a rather large number of
committed adopters (my guess is that it would take a collection
of significant state actors, but there are other scenarios).
Your making the switch, my making the switch, even every
participant in the IETF making the switch wouldn't amount to

If one asks the question of what it would take for a collection
of significant state actors to make the move, my guess it that
it would take a crisis event that would either be very
disruptive or get a lot of bad publicity.  "Aggravated enough at
ICANN" was shorthand for the most likely collection of sources
of (or blame for) such an event I could think of quickly.   I do
not consider that likely.  Indeed, I think it is more likely
that assorted IETF work to expand DNS capabilities beyond their
rational limits are more likely to cause serious problems.  But
that doesn't seem to be the topic of this thread.