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. Best, A -- Andrew Sullivan a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
