--On Monday, July 20, 2015 4:14 PM +0200 Andrew Sullivan <ajs@xxxxxxxxxxxxxxxxxx> 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