--On Wednesday, July 15, 2015 12:40 -0700 Ted Hardie <ted.ietf@xxxxxxxxx> wrote: >> 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 >... > 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. Yep. Glad you are ahead of me and that our exploration went down approximately the same path. Keeping in mind that I've far more concerned about where we go next and what the boundaries and criteria are than about any one name, part of my thought was to be able to say to the next applicant who comes along "We can give you, the applicant, four options, two easy and two harder: (i) CLASS=IN, but a subdomain below something (I'll leave whether the current 'ALT.' proposal is the right 'something', or whether even something analogous to it should be 'ALT.ARPA.', for a separate discussion). (ii) CLASS=SP, top-level domain. (iii) CLASS=IN and a TLD, but with _really_ high threshold for justifying that choice. (iv) Go do whatever ICANN specifies for a TLD that you don't intend to resolve in the normal/public DNS. To the best of my knowledge, there is no such procedure today. ICANN could create one, in which case how it works is not an IETF problem. Or they could decline to do so, in which case this option is a no-op. That isn't an IETF problem either." For options (i) or (ii) the IETF probably wouldn't want quite FCFS, but an Expert Review/ Sanity Check would probably be sufficient. Either one requires that people either come to us when the protocol is designed so an appropriate DNS setup can be chosen or negotiated. If things are already deployed, the question would become whether it is easier to upgrade relevant applications or to be pushed over into one of the other options... but that is not an IETF problem. For (iii), I don't know that we always say "no", but, if only because such reservations either interact with ICANN gTLD application procedures or create the kinds of operational and/or security risks that several people have identified, we would presumably need to understand why some other option wasn't appropriate, what was proposed to mitigate the risks, some review or policy model that was hostile to squatting strategies, and lots of deployment (although presumably not up to the level of "localhost." Again, I don't know whether that model should be applied to "onion." or not. Part of the answer obviously depends on whether there is a "good and virtuous cause" exemption because concerns about squatting, etc., obviously arise even though any reasonable minimum deployment criteria are almost certainly met. I think part of the answer to those questions require that the IETF explore how far it is willing to go in support of sociopolitical and/or privacy concerns and where the stopping points are in that direction. However, if the model did apply to "onion.", presumably part of the answer would be to tell the applicants/registrants that the job of convincing the CABrowser Forum or other implementers to do whatever is needed is their problem, not ours. best, john