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

[Ted Hardie <[e-mail]>]

Howdy,

On Wed, Jul 15, 2015 at 12:13 PM, John C Klensin <[e-mail]> wrote:

>
>
> --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 went through the same experiment, and I even considered how to adapt a
long-ago dropped proposal for cross-class pointers​
<https://www.ietf.org/archive/id/draft-hardie-out-rr-00.txt>​to adapt Ted
Lemon's NSEC method (essentially, using DNSSEC to secure the cross-class
pointer record instead of the NXDOMAIN).  I think it could work, but as you
say, there are a lot of potential issues with making this deployable.
There are a *lot* of things (and organizations) that presume IN is the only
class, and it's not clear that they would go along.  If CABrowser Forum did
not, for example, much of the reason the .onion folks want a DNS special
name would not work.

regards,

Ted





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