Howdy,
On Wed, Jul 15, 2015 at 12:13 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com>
wrote:
--On Wednesday, July 15, 2015 09:56 -0700 Ted Hardie
<ted(_dot_)ietf(_at_)gmail(_dot_)com> 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