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

David Conrad <> Mon, 09 December 2013 01:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 93DB41AE198 for <>; Sun, 8 Dec 2013 17:20:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QBHecIXtk4-u for <>; Sun, 8 Dec 2013 17:20:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5AE411AE195 for <>; Sun, 8 Dec 2013 17:20:00 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B746A848F1; Sun, 8 Dec 2013 20:19:54 -0500 (EST)
Received: from ([]) by localhost ( []) (maiad, port 10024) with ESMTP id 56961-05; Sun, 8 Dec 2013 20:19:54 -0500 (EST)
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 18A0F8445C; Sun, 8 Dec 2013 20:19:53 -0500 (EST)
Content-Type: multipart/signed; boundary="Apple-Mail=_79CA7282-8FFE-4003-92FC-E90571333F2E"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: David Conrad <>
In-Reply-To: <>
Date: Sun, 8 Dec 2013 20:19:46 -0500
Message-Id: <>
References: <> <> <> <> <> <>
To: Christian Grothoff <>
X-Mailer: Apple Mail (2.1822)
Cc: dnsop WG <>
Subject: Re: [DNSOP] [ I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt]
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Dec 2013 01:20:03 -0000


On Dec 6, 2013, at 3:34 PM, Christian Grothoff <> 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, 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?