Re: [DNSOP] [[e-mail]: I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt]

[Christian Grothoff <[e-mail]>]

On 12/09/2013 02:19 AM, David Conrad wrote:
>> 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?

Not seriously ;-).  In fact, I think that the idea that changing domain
names that are in use is silly to begin with.  After all, it wasn't me
who suggested to change ".onion" to ".onion.alt" or ".onion.p2p". :-)

> Do you have any statistics on how many deployments of GNS there are?

Given that the code is very new, there'd have to be very few.  There are
certainly way more .i2p, .onion or .bit out there (the Namecoin
community talks about hundreds of thousands, I have not seen stats for
the others anytime recently).  Now, you're never going to really get
statistics for ".gnu" as the system doesn't allow anyone to enumerate
the zones (or records) that exist by design.

>> 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".

.zkey is functional in that in LABEL.zkey, the LABEL is the zone's
(public) key.  .gnu is functional in that GNU gives _you_ the freedom to
(0) use for any purpose, (1) change it so that it does as you wish, (2)
redistribute the information to others, and (3) allows others to make
modifications to their copies.  So if you're familiar with GNU (if not,
please read http://www.gnu.org/philosophy/free-sw.html), you'll find
that ".gnu" is highly descriptive from a functional perspective.  That
it internally uses a P2P system is a technical artifact, which in fact
hardly matters to the users (ditto for .onion, and .bit, btw. -- there
have in fact been people arguing with me if one should consider
Tor/Namecoin P2P systems to begin with).  I believe all of the proposed
pTLDs were picked to be descriptive from the _user's_ perspective.

>>> 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?

Actually, even on systems with the gnunet-dns2gns proxy that would be
needed. However, on systems where GNS is locally installed, we can
intercept in say the libc NSS code via a plugin, and then that'd be
before the 'class' is ever set.  So in that case the stub resolver would
be modified in a different way that still doesn't involve DNS classes
(see https://gnunet.org/svn/gnunet/src/gns/nss/nss_query_gns.c)