Christian, On Dec 6, 2013, at 3:34 PM, Christian Grothoff <[email protected]> wrote: > My point is that many issues some people were raising here would still not be > solved by .alt, such as trademark issues.
I actually think it would (since the use of <trademark>.alt would not need to be exclusive as .<trademark> in the DNS must be), but since as you say neither of us are trademark lawyers, let's leave that argument to others. > Beyond aesthetics, what arguments are there again against appending > ".icann" to reference the ICANN-managed root zone? We can't even get new RR types deployed on the Internet (e.g., see type 99) and you're suggesting we try to change pretty much every existing domain name on the planet? Technically, however, in accordance with RFC 2860, ICANN manages the root zone on behalf of the IETF. If the IETF were to decide that ICANN must append ".icann" to every existing TLD, I suppose ICANN would have to do that or risk a cancellation of the IETF MoU. I'll let you make the argument that the current DNS hierarchy needs to be renamed to the IETF :). Do you have any statistics on how many deployments of GNS there are? > Aesthetics is important, as any Apple fan will tell you (hence .local, and > not local.apple.com, I'm sure). I would assume Apple chose ".local" for Rendezvous/Bonjour for functional reasons, e.g., because the resources addressable via mdns were, you know, local to the LAN and it would make sense even to Pointy Haired Bosses to reference local resources as "printer.local". If it were for aesthetic purposes, they'd probably have chosen ".apple" or maybe ".mac". I'm not sure I see how this functional argument would apply to ".gnu"/".zkey". I could, however, see a functional argument for ".p2p". >> To be sure I understand: you're saying that if I take my favorite unmodified >> browser on my favorite unmodified operating system and point it at (say) >> gcc.gnu, a DNS query sent out by my machine to my local resolver using the >> standard DNS protocol would be received on UDP (or TCP?) port 53 by the >> special GNS resolver which would notice the trailing string ".gnu" and do >> something special with it, throwing everything else to the regular DNS >> resolution process? > yes, that's pretty much how gnunet-dns2gns works (it also does something > special for '.zkey'). Thanks for the explanation. > This is one of the main reasons why the notion of using a different > class for GNS is rather silly. It would mean revising the stub resolver on each client system that is using GNS, which would be necessary in environments without the "gnunet-dns2gns" proxy, right? Regards, -drc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
