Re: [DNSOP] [internet-drafts@ietf.org: I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt]

Christian Grothoff <christian@grothoff.org> Fri, 06 December 2013 23:34 UTC

Return-Path: <christian@grothoff.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799BE1AE137 for <dnsop@ietfa.amsl.com>; Fri, 6 Dec 2013 15:34:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM2NqdAZkrW6 for <dnsop@ietfa.amsl.com>; Fri, 6 Dec 2013 15:34:37 -0800 (PST)
Received: from smtp1.informatik.tu-muenchen.de (smtp1.informatik.tu-muenchen.de [131.159.0.99]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8821AE0EA for <dnsop@ietf.org>; Fri, 6 Dec 2013 15:34:37 -0800 (PST)
Received: from [192.168.178.20] (pd95c0f92.dip0.t-ipconnect.de [217.92.15.146]) by mail.net.in.tum.de (Postfix) with ESMTPSA id ECBB8192201C; Sat, 7 Dec 2013 00:34:31 +0100 (CET)
Message-ID: <52A25F03.3070502@grothoff.org>
Date: Sat, 07 Dec 2013 00:34:27 +0100
From: Christian Grothoff <christian@grothoff.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10
MIME-Version: 1.0
To: David Conrad <drc@virtualized.org>
References: <529B75A2.10703@appelbaum.net> <529B7E4A.2070600@grothoff.org> <73387529-308B-424D-807C-D41E59B1D5E8@virtualized.org> <52A244EC.5040104@grothoff.org> <37B27FD9-C0BB-4178-84F3-FD6BA6402AFB@virtualized.org>
In-Reply-To: <37B27FD9-C0BB-4178-84F3-FD6BA6402AFB@virtualized.org>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="----enig2PXWBIQMSTUBMKSDLNNTU"
X-Mailman-Approved-At: Sat, 07 Dec 2013 04:45:33 -0800
Cc: dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] [internet-drafts@ietf.org: I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt]
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 23:34:39 -0000

On 12/07/2013 12:02 AM, David Conrad wrote:
> Christian,
> 
> On Dec 6, 2013, at 1:43 PM, Christian Grothoff <christian@grothoff.org> wrote:
>> I meant 'management' in the sense of assigning names under .alt to
>> groups/organizations/software.  We'd effectively need another process to
>> decide who gets to implement a mechanism for ".com.alt".  
> 
> The RFC 6761 registry (http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.txt) would not designate who gets to implement a mechanism for .onion/.gnu/.i2p, it would merely state those strings are reserved so that they aren't allocated as DNS top-level domains and provide a reference to the (first) specification that reserved the name. I see no difference between the suffix being "." and ".alt" in the context of management. Indeed, the registry already lists non-TLD strings.

My point is that many issues some people were raising here would still
not be solved by .alt, such as trademark issues.

>> Besides, as
>> was already pointed out, RFC 6761 rejected the idea of ".alt",
> 
> RFC 6761 says nothing regarding ".alt".  To be clear, the idea is to provide a namespace alternative to the root that reduces the risk of name collisions for applications that do not make use of the DNS (the choice of ".alt" is mostly arbitrary -- it could be pretty much anything).  As I've asked before, beyond aesthetics, what arguments are there against ".alt"?

Beyond aesthetics, what arguments are there again against appending
".icann" to reference the
ICANN-managed root zone? Aesthetics is important, as any Apple fan will
tell you (hence .local,
and not local.apple.com, I'm sure).

>> and I
>> agree with Stephane that, as RFC 6761 has consensus, we should not
>> reopen that discussion just because we're trying to use it for the first
>> time.
> 
> By this logic, we should have stuck with RFC 2065 for DNSSEC. It is not unusual for RFCs to not survive their first interaction with the real world.

Well, naturally nothing is final. But I'm not volunteering to revise RFC
6761 ;-).

>>>> The case is even stronger for GNS, where DNS queries can even be
>>>> intercepted at the network layer by a dedicated DNS2GNS gateway.
>>> Sorry, I'm confused. The point of the RFC 6761 reservation scheme is that the names are _NOT_ intended for use in DNS resolution. What do you mean by "DNS queries can be intercepted at the network layer"?
>> The GNS queries won't go to the DNS resolver hierarchy; however,
>> applications may use the DNS protocol initially (for legacy reasons),
>> and then at a 'personal' DNS resolver might decide to forward ".gnu" to
>> GNS and other queries to DNS.
> 
> 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?

Well, "unmodified operating system" might be a bit restrictive, as you
may at least have to configure
your resolver IP (i.e. in /etc/resolv.conf) to point to something that
you don't usually get via DHCP
from your traditional ISP.  But that's nitpicking about the definition
of 'unmodified' OS.  Other
than that, yes, that's pretty much how gnunet-dns2gns works (it also
does something special for '.zkey').
This is one of the main reasons why the notion of using a different
class for GNS is rather silly.

Note that there are _other_ ways to access GNS, but this is likely to be
a popular method until
DNS is completely replaced ;-).


Happy hacking

Christian