On Mon, Feb 03, 2014 at 08:08:59PM -0500, Ted Lemon wrote:
>
> purely on the basis that some of us don't like what they did. We
> need a better reason than that, and thus far none has been stated.
In the particular case of .onion, I'm not sure I agree none has been
stated. But let me try again:
If you want to use a name in DNS protocol slots, then you need a DNS
name. You didn't get a DNS name, and instead you used a label
that wasn't under your control. That's been against the rules in the
DNS since forever. Now you want to short-circuit the allocation
mechanism. But we have an allocation mechanism for this. In the
normal case, you apply to ICANN. In an unusual case where the
protocol depends on this, then you can use this special-use
registry. So you need to show that your protocol needs to depend
on this special-use label, and then we can register it under the
special use mechanism. Otherwise go to ICANN.
What we ought to be arguing about, in effect, is precisely why this
needs a special-names registration. Now, _maybe_ there is an argument
that this is a DNS-looking series of labels but it never goes into the
DNS namespace (that's what I've heard once). In that case, there
might be an argument. ("Put this in the default local zones, always
NXDOMAIN, because we want to protect the DNS.") Maybe the argument is
instead that sometimes these names are handed to DNS resolvers and are
supposed to resolve. In _that_ case, it seems to me that the "this is
a DNS name" consideration is also pretty high. I'm unsure we've had
clear and consistent arguments about this for each of the cases.
In the chapin draft, the argument is different, and it appears to be
purely a local-resolution-only one -- that is, always "protection of
the DNS" because of de facto resolution and security decisions
deployed on the Net. I haven't read it closely enough to decide
whether this is true for every label in the list.
Best,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
