Hi, Excerpts from Peter Thomassen's message of 2022-08-01 16:57:45 -0400: > > On 8/1/22 12:01, Paul Vixie wrote: > >> > >> I agree and I think publication of these drafts would be a good idea > >> (may be with status Experimental since, as Joe Abley said, there is > >> clearly no IETF consensus). Note that I am skeptical about their use: > >> most people who "preempt" .eth, .bitcoin, .web3 or .myownprotocol will > >> not read the RFC and, if they do, won't follow it. But at least we > >> will be able to say that we tried and we have a solution (and not a > >> ridiculous one such as "pay ICANN 185 000 US $"). > > > > +1. the namespace will be locally augmented. we should describe a way. > > I agree, too. > > > i'm particularly interested in whether the root zone should have an NS for > > the private-label tld(s) (.alt or ._alt or whatever) > > Not sure if ._alt vs .alt has been discussed (in that case I've missed it.) > > I'd like to use the opportunity to refer to using _* labels (such as > ._myownprotocol): > https://mailarchive.ietf.org/arch/msg/dnsop/vQCi5ibTXw6Vfr2gbTnk-D5jcW0/ It > addresses some (not all) of Martin's concerns. > > The OP wrote: > > TLD labels that begin with _ > > (Note the plural.) Perhaps that was intended to mean those _*-style TLDs. > > > with an NS of "localhost" and a dnssec "opt out" indicator so that these > > private tlds can fit into the authenticity infrastructure. > > That's one way. OTOH, if we specify _* as non-DNS use, resolver could just > "know". (That does not preclude also doing what you're suggesting.) >
While _* is _a_ solution to the problem resulting in shorter suffixes, it is also much worse in another aspect: usability. 1. "_" is not very legible and easily confused with a space or faulty rendering of a character. 2. "_" is (on most keyboards) a lot more effort to input as it requires the shift key. This is why ".", "#" and "/" are chosen so often. A usable suffix should support the user in understanding it. Which is also why (as pointed by in this thread) ".alt" is problematic because of the "alternative" implications. Apart from dedicated TLD for name systems (e.g. ".ens", ".eth", ".gns" etc etc) the next best thing would be a subdomain/TLD combination such as: g.ns (.ns is already taken I know) e.ns onio.ns OR g.ads (.ads is already taken <irony>for a very useful purpose</irony> I know) e.ads (GADS was the name of GNS in the very beginning and stood for "GNU Alternative Domain System) Maybe a nicer alternative could be found. ".nrs" for "Name Resolution System"? Or ".dns"? g.nrs? e.nrs? Anyway. You should also take into account that effectively ".alt" or whatever it would become is effectively also giving GNS a special-use TLD for now as we do not see any other systems standing in line at any IETF WG/ISE and GNS could simply squat "*.alt". So the question would also be: If ".alt" can be done, why not ".gns". IMO, IF the ".alt" TLD exists, I would really apprectiate an IANA registry for the subdomains limited to name systems that can demonstrate either specifications or large scale deployments. "Anything goes under .alt" makes any suffix even more unattractive. Finally, draft-schanzen-gns will likely still allow to "squat" DNS names. Just like "/etc/hosts"/NSS will always allow to squat any DNS name. It is just something that cannot be avoided by design and this reality should be acknowledged. Saying "www.example.com" MUST always resolve to whatever it is in DNS does not map to OS capabilities in practice. Probably not even to all DNS deployments. So, is "squatting" actually the problem here? And if it is, is it a problem of alternative name systems or a general problem with how name resolution is implemented on common OSes? I have also read [1] and quite agree with it. So if a general statement on namespaces should be pursued maybe this can be used as a starting point. It does, however, IMO reinforce the notion that RFC6761 should (can?) be used for non-DNS name systems. [1] https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/ BR Martin > ~Peter > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
