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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Christian Grothoff writes:
> 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". :-)

ip6.int to ip6.arpa would be a more realistic example of moving a
prefix.

You introduce the new domain.  You have software call the new domain
and if not found call the old domain.  Give it 10 years or so and
stop calling the old domain.  Anyone who hasn't transitioned by
then is cut off.

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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]