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 Monday, July 20, 2015 4:14 PM +0200 Andrew Sullivan
<[e-mail]> wrote:

> Hi,
> 
> On Wed, Jul 15, 2015 at 09:56:27AM -0700, Ted Hardie wrote:
> 
>> 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.
>...
> On Wed, Jul 15, 2015 at 03:13:35PM -0400, John C Klensin wrote:
> 
>> 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
>...

> We have some features in the DNS that are also duplicated as
> work-arounds that are widely deployed.  The obvious example is
> RRTYPEs.  In lots of cases, rather than using a nice
> special-purpose type designed to carry the kind of data a
> conforming application wants, people have created one or more
> "underscore labels" and put structured RDATA in a TXT record.
> This is a kind of in-band signalling that is ugly, but which
> worked around the deplpoyability issues with new RRTYPEs.
> 
> It seems to me that local and onion are another example of
> this, only either for classes, or else for resolution protocol
> switching (I suspect these two boil down to the same thing).
> Basically, local was a way of communicating, "Don't query me
> in the IANA DNS root name space."  Since classes mostly didn't
> work anywhere, rather than starting a new class to do this,
> mDNS and now Tor use the end-most non-null label to signal,
> "Don't look this up in the IANA root."
> 
> But it seems to me that the fact people are inventing ways to
> do the things the protocol already offers, and doing violence
> to the overall system at the same time, suggests that we're
> doing something fundamentally wrong with DNS.  I wish I had a
> clue what to do about this, because I think there's faint hope
> that we're going to be able to prevent these continued
> innovations: RRTYPEs are not a great deal easier to deploy
> (though they're easy in nameservers themselves), and CLASSes
> still don't really work[1].  I don't know whether what this
> shows is that we just have to put up with the mess that all of
> this is making, or whether what it's really telling us is that
> DNS's seams are finally bursting from all the stuff we have
> tried to stick in there (cf.
> http://www.cafepress.com/nxdomain/8592477 Note: possibly
> offensive term).

Andrew,

I agree with your analysis, modulo one question.  You make the
comment that CLASSes don't really work, as have others.  I'd
like to understand it better.  We've had some experience in
which they have worked to support namespaces that are not really
part of the global/public Internet. Yes, using them at scale
would require we think about roots , root location, and root
management, etc., in new contexts. QCLASS=ANY is conceptually
impossible, but the fishing expedition it implies should never
actually be needed. I would not be surprised if you told me that
CLASS has been botched in some implementations and there has
been no incentive to fix it, that shouldn't surprise me at all.
However, if there were an important application, I assume those
implementations could be fixed.  So what do you see as the
issue?   Is it that we have needs to intermix ordinary public
names with "don't try to resolve this there" stuff in the same
environments?  I agree that would be a problem for CLASS, but
note some very strong analogies with the IDNA kludge.

I am, However, getting increasingly concerned with another
aspect of the problem.  It may be worth sharing that concern.
While I think it is entirely reasonable for the IETF to write
rules about categories of DNS labels or restrictions on them
("don't use "xn--... for anything but IDNA" or "labels with
leading underscore are reserved for protocol and service
location use" are reasonable examples), our being in the
business of allocating (or blocking) labels one at a time
impresses me as a bad idea, inviting both misunderstandings and
getting the IETF dragged into the sorts of ICANN policy debates
that few people in our community really enjoy and fewer seem
equipped to really understand and engage with.

Rather than engaging in a drama that looks from a distance like
"ICANN asserts that they are in charges of everything, including
the IETF" and "IETF asserts they can grab whatever names they
want, whenever they like". why can't we take the Special Names
problem to them, say "look, we understand that these names look
like names in the public DNS root and that confusion that would
have bad effects is a real risk, how about you devise a
procedure for dealing with them that recognizes the importance
of existing deployment and use and considers the low likelihood
that people who are using these names will stop because you tell
them too.  Clearly the procedure you use for new gTLD
applications won't work.  And, because some of these names won't
wait, if you can't get that procedure together immediately, we'd
be willing to let you delegate things to us on some reasonable
basis until you do."

It seems to me something like that, rather than continual
testing of boundaries, is how two peer organizations led by
adults treat each other.  It also allows us to take the position
that we are ICANN's customers for the IANA function but are
otherwise an independent entity that can work with them when
that is in the best interests of both of us and of the Internet,
but that is not, in any respect, responsible for them or their
operational or governance models.

best,
    john