Re: Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

[John C Klensin <[e-mail]>]

--On Wednesday, July 15, 2015 09:56 -0700 Ted Hardie
<[e-mail]> wrote:

>...
> ​From this point of view the special names registry is
> actually a registry of "labels forbidden to the DNS​ in a
> specific slot".  But my view of the reasoning is that for
> test, invalid, and example "special processing" means "no
> processing, this isn't real".  RFC 6762 wasn't "no processing"
> but instead "no processing in global DNS, process locally
> using mDNS instead." That confirmed that the IETF would be
> willing to register labels forbidden to the DNS in a specific
> slot because it was otherwise resolved, rather than simply
> unresolvable.  And now we have the next such request, which
> once again relies on an installed based to claim necessity.
> 
> From an architectural perspective (but still wearing my hat
> as an
> individual), this method for partitioning the namespace has a
> very poor long-term characteristics.  If we permitted it
> generally, we would be sanctioning a system in which there is
> a single root + some local knowledge required for name
> resolution.  That local knowledge will be at some unknown
> state for the vast majority of devices and implementations for
> a long time (predict for me, if you like,  the date the last
> query for .onion will hit the root, and I'll buy you a donut
> if it occurs within a year of your guess) and if the local
> knowledge required expands over time, essentially forever.
> That's bad, and pretty much needless, as there are lots of
> other ways to partition the namespace.  pseudo-TLDs are not
> required; they look convenient because they hide the costs.
>...

I think this is the right analysis.  I also note that, while
"npr." might not be the best example, it that scenario unfolded,
NPR might have grounds to complain that the IETF's actions
interfered with their use of the ICANN-assigned public root TLD
and hence with their exercise of trademarks, etc. 

Your note motivated a thought experiment.  I don't expect most
people to take this seriously as a suggestion, but thinking
about it a bit might prove helpful.   If the goal is to identify
labels that can be used with the DNS or DNS-like mechanisms but
are not expected or allowed to be allocated in the public root,
we've got a rather good technical mechanism that has _exactly_
that property and that will create names that ICANN will never
consider allocating, at least under its current charter.
Ignoring both special names that that have been in very long
term and popular use (all of which I hope are now in the
registry) and strings associated with squatting as a strategy
for the moment, suppose we decided that all new special names
associated with protocols and intended for special resolution
mechanisms be allocated (and placeholders delegated if needed)
in a separate DNS CLASS, say "SN" for "Special Name".  Zero
impact on the ICANN/IANA root from queries gone bad, no conflict
with names ICANN allocates even if the labels are the same
(remember that QCLASS=ANY has never worked), etc.  It would be
about the clearest signal of the need to do local resolution
possible and it would be name-independent.    If the local folks
use non-DNS resolution mechanisms, it doesn't make any
difference what CLASS the name is in.   If they (deliberately or
accidentally) try to resolve them using the public DNS, they
either need to point to some root structure (other than that for
CLASS=IN) or they get a massive fail.

I can think of several reasons why that might not be practical,
but I believe that thinking through those issues might help to
illuminate the present set of issues.

best,
    john