On Dec 2, 2013, at 7:16 AM, Andrew Sullivan <a...@anvilwalrusden.com> wrote:
> On Sun, Dec 01, 2013 at 12:35:44PM -0500, Paul Wouters wrote: >> >> It would make more sense to me to reserve something like .alt where >> people can plugin onion.alt, gnu.alt, etc, and are guaranteed that >> the .alt domain will never actually be delegated by the root. > > And, behold, we have .arpa already. We could just create anything we > wanted under there. I don't get why some new TLD is needed. > >> And once you go that way, one can wonder why not use the already >> existing .local for that? Perhaps avoid talking to different protocol >> software is a good enough reason not to re-use .local. > > Certainly do not re-use .local for this. The reason mDNS needed a > different TLD is (to drastically oversimplify) because it uses the TLD > as a protocol-shift token: when you're in .local, you're actually > using a different protocol, and this is a way to keep the otherwise > parallel name-space aligned. (This is the fourth extension mechanism > we have in the DNS: we have RRTYPEs, CLASSes, underscore labels, and > TLDs. Hurray!) > >> The traditional reasons for not using any non-IN class is that a lot >> of software would not work well with that, but in these cases, the >> consumers aren't actually interested in real DNS anyway, and using >> a URI that indicates a different class should not be too hard to plug >> into existing browsers? > > The last such proposal was a mechanism to use a new CLASS for IDN > support. It turned out it wouldn't work because (among other reasons) > there were too many resolvers that spit up on any CLASS other than IN. > I am dubious that has improved, though I'd be prepared for evidence > that it had. SLDs under .arpa are cheap and easily managed by the IETF. Forcing someone into a different class (where all sorts of things could block by accident) seems silly. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
