Re: [DNSOP] Questions about draft-adpkja-dnsop-special-names-problem-00

Alain Durand <alain.durand@icann.org> Wed, 04 November 2015 13:34 UTC

Return-Path: <alain.durand@icann.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 857351B2F6A for <dnsop@ietfa.amsl.com>; Wed, 4 Nov 2015 05:34:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.431
X-Spam-Level:
X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 1NueEIzYAzjS for <dnsop@ietfa.amsl.com>; Wed, 4 Nov 2015 05:34:34 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09B31B2F66 for <dnsop@ietf.org>; Wed, 4 Nov 2015 05:34:34 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 4 Nov 2015 05:34:32 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Wed, 4 Nov 2015 05:34:32 -0800
From: Alain Durand <alain.durand@icann.org>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Thread-Topic: [DNSOP] Questions about draft-adpkja-dnsop-special-names-problem-00
Thread-Index: AQHRFv/WpTvV9ANyX0ukZ4IQeuh0056MYyyA
Date: Wed, 04 Nov 2015 13:34:32 +0000
Message-ID: <55F083E9-8881-47F3-AA73-7A4F09DEA0C7@icann.org>
References: <20151104032027.GA28629@laperouse.bortzmeyer.org> <20151104125217.GA26421@laperouse.bortzmeyer.org>
In-Reply-To: <20151104125217.GA26421@laperouse.bortzmeyer.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.236]
Content-Type: multipart/signed; boundary="Apple-Mail=_190AA87F-6997-447D-9B9B-168E7DE8A2F4"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/D2ALjzccpY_F-mTo5mgpUJ4nJmU>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] Questions about draft-adpkja-dnsop-special-names-problem-00
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 04 Nov 2015 13:34:36 -0000

Stephane,

The following paragraph in section 2 was an attempt at capturing your point:

"   Such usage, which a few commenters have referred to as "protocol
   switching," is not limited to "protocol switch" in the strict sense
   of indicating specific protocols on the wire.  It could indicate to
   switch to another name space (eg .onion), use a different protocol
   (eg tor, or mdns), or indicate to use a local DNS scope by not using
   the DNS root for name resolution (eg .home in homenet) or something
   else altogether.”

Alain.


> On Nov 4, 2015, at 7:52 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
> 
> On Wed, Nov 04, 2015 at 12:20:27PM +0900,
> Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote 
> a message of 73 lines which said:
> 
>> draft-adpkja-dnsop-special-names-problem-00 raises several issues,
> 
> And I forgot one of the most important ones, but I remembered it
> during a discussion over sashimi this evening (the sashimi were good,
> thanks).
> 
> The entire section 2, about "switches" is questionable because using
> .bit or .onion is not only to change the *resolution* protocol but
> also (and specially) to change the *registration* process.
> 
> These are two different systems. Of course, they have some links (the
> fact that domain names are organized into a tree is used by the DNS
> protocol for fast resolution) but not identical. The current version
> of the draft says "any TLD registered in IANA-maintained root-zone
> (use DNS)" which is not quite exact. Names registered in the
> RFC2826-root are often looked up through the DNS but not always (some
> people use local hosts file or LDAP to do it). And, more important,
> some TLDs outside of the RFC2826-root do not always indicate a
> switch. This is the case of .bit (if you already know Namecoin, you
> can skip the next paragraph).
> 
> Namecoin uses a blockchain to store registered names. That way, you
> can have meaningful names without a registry. Because few clients
> speak the Namecoin API, most of the times, name resolution is done
> through the DNS: you set up a local authoritative name server to
> export data from the blockchain into a .bit zone that you load.
> 
> This example clearly shows that the TLD is not a "protocol
> switch". That's because Namecoin is intended to address perceived
> problems with the registration system, not with the DNS.
> 
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop