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

David Conrad <drc@virtualized.org> Fri, 06 December 2013 23:03 UTC

Return-Path: <drc@virtualized.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 C377D1ADE87 for <dnsop@ietfa.amsl.com>; Fri, 6 Dec 2013 15:03:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DT3U5MIS9j2l for <dnsop@ietfa.amsl.com>; Fri, 6 Dec 2013 15:03:07 -0800 (PST)
Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id C51741AE02E for <dnsop@ietf.org>; Fri, 6 Dec 2013 15:03:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id DCC48848F1; Fri, 6 Dec 2013 18:03:01 -0500 (EST)
Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 28981-10; Fri, 6 Dec 2013 18:03:01 -0500 (EST)
Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id 3033084438; Fri, 6 Dec 2013 18:02:54 -0500 (EST)
Content-Type: multipart/signed; boundary="Apple-Mail=_B2173D29-692A-49DB-9A2F-BB9ADC389EB5"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: David Conrad <drc@virtualized.org>
In-Reply-To: <52A244EC.5040104@grothoff.org>
Date: Fri, 06 Dec 2013 15:02:48 -0800
Message-Id: <37B27FD9-C0BB-4178-84F3-FD6BA6402AFB@virtualized.org>
References: <529B75A2.10703@appelbaum.net> <529B7E4A.2070600@grothoff.org> <73387529-308B-424D-807C-D41E59B1D5E8@virtualized.org> <52A244EC.5040104@grothoff.org>
To: Christian Grothoff <christian@grothoff.org>
X-Mailer: Apple Mail (2.1822)
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:03:10 -0000

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.

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

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

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

Thanks,
-drc