On Wed, Feb 26, 2014 at 2:34 PM, Joe Abley <jab...@hopcount.ca> wrote: > > On 26 Feb 2014, at 5:03, Mark Andrews <ma...@isc.org> wrote: > >> In message <d0ac0015-63c3-4c03-a8d0-888c435d2...@virtualized.org>, David >> Conrad >> writes: >> >>> On Feb 25, 2014, at 9:51 AM, Stuart Cheshire <chesh...@apple.com> wrote: >>>> If we have *some* pseudo-TLDs reserved for local-use names, >>> >>> I would think = >>> http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#User-assigned_code_element= >>> s would be appropriate for this purpose. >>> >>> Regards, >>> -drc >> >> Whatever is used needs to be insecurely delegated so that in app >> validation will work. > > I still don't see why we need a TLD, or a delegation/reservation under ARPA. > > There are many, many TLDs under which an application/protocol implementer can > reserve some namespace for their exclusive use at low cost ($10/year, say). > Why is this approach not preferred for a new application/protocol? It seems > far simpler.
Yes, and it is -- but it means that leakages hit more folk. > > Perhaps all that is missing is some guidance that says "you shouldn't hijack > namespaces that you don't control, even for non-DNS applications; register a > domain instead". Because for some things, people specifically do *not* want it to hit / go through the DNS -- this is why they have done this, and *not* just registered e.g onion.com... For example, I'm a *huge* Justin Beiber fan. I, and a bunch of my fellow closet Bieberites hang out on the-bieb-is-cool.onion. (you don't really think we want everyone to know that we obsess over every little antic, do you?) Last week I emailed my friend a link to http://www.the-bieb-is-cool.onion/Justins_New_Shoes.html. Unfortunately, he was just *so* excited to see that the Bieb has new sneakers that he clicked on the link from his phone (which doesn't have the ToR interceptor software installed). This, of course, means that the "DNS like" name, which should not really be used in a DNS context suddenly hit the DNS. Only his recursive and the root saw this, and that's embarrassing enough, thank you. This is bad enough, but if people built stuff like this under .onion.eff.org (or foo.onion.arpa), there would now be many more people in the list who knew our shameful little secret. Obviously this is a somewhat contrived example (after all, who wouldn't want to make it widely known that they *love* Justin Bieber!), but lets instead pretend I'm using an overlay network as a political dissident, or to discuss my sexual orientation, or... This is some of the justification behind the .ALT TLD proposal (http://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-00) -- create a special label to be used to denote that this is not actually a name in the DNS context. By reserving it as a special use name: A: It creates a "safe" namespace, secure from collision for people to root namespaces that have no meaning in a DNS context. B: when one of these names *does* leak (as they will), iterative resolvers will be authoritative, with an empty zone, so the-bieb-is-cool.onion.alt only gets seen by the iterative and goes no further. C: When one does go further (as they will), the root can delegate to AS112, while can squash it. D: 4 years from now, when someone comes along and says "I created a shiny new directory system. I used something that looks like DNS names, and I placed it under .pony. Please reserve that for me" the IESG can at least say "But we told you not to do that..." They can also a: reserve it, b: not, or c: we can have another thread about this all again, but now at least we can nod knowingly and feel all superior... W P.S: Note: I did *not* say what should happen with the current pseudo-TLDs / colliding names. They can move under .ALT or they can not. The IESG can reserve them, or not, or bury them in peat, or paint them purple and dress them in wellies. I have views on what I think makes sense, but that's a separate mail..... > > Joe > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dn _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
