Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Tue, 08 March 2011 21:36 UTC

Return-Path: <nweaver@ICSI.Berkeley.EDU>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00A823A6452 for <dnsext@core3.amsl.com>; Tue, 8 Mar 2011 13:36:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level:
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWYkvw2AKvzn for <dnsext@core3.amsl.com>; Tue, 8 Mar 2011 13:36:17 -0800 (PST)
Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 05B283A63C9 for <dnsext@ietf.org>; Tue, 8 Mar 2011 13:36:17 -0800 (PST)
Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 9CCA236A413; Tue, 8 Mar 2011 13:37:32 -0800 (PST)
References: <4D74E409.1060409@dougbarton.us> <79987316-C80C-4015-A3D3-77F8D2F33351@icsi.berkeley.edu> <4D758753.3090900@dougbarton.us> <E9EAA80C-78FF-4246-869F-CCB49A4AC1AD@ICSI.Berkeley.EDU> <4D769DFD.2070507@dougbarton.us>
In-Reply-To: <4D769DFD.2070507@dougbarton.us>
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
Message-Id: <9A985005-F13E-4165-A008-479FF92F3FFA@ICSI.Berkeley.EDU>
Content-Transfer-Encoding: quoted-printable
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Date: Tue, 8 Mar 2011 13:37:32 -0800
To: Doug Barton <dougb@dougbarton.us>
X-Mailer: Apple Mail (2.1082)
Cc: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>, dnsext@ietf.org
Subject: Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Mar 2011 21:36:18 -0000

On Mar 8, 2011, at 1:22 PM, Doug Barton wrote:
>> EG, take arabic.  With a resolver change model, every resolver which
>> has at least a few arabic clients needs to upgrade, which is
>> effectively everyone.  But most resolvers won't substantially
>> benefit, so why bother upgrading?
> 
> I'm not sure how stub change relates to Arabic, can you please expand on that? Specifically my understanding is that the "hard parts" of dealing with Arabic are located in the application layer so that what gets handed to the stub is the punycode. At the punycode layer what differentiates Arabic from other issues?

Its just the incentive issue.  The stub is located on the system that has 100% benefit or none, so those who want the benefit do the upgrade and get it.

The recursive resolver only benefits for the few fraction of the clients behind it, so less incentive to upgrade.

>>>> The CLONE RR really needs to be a "canonicalization program",
>>>> describing a set of character/word transformations that should
>>>> be applied, NOT just a simple pointer.[1]
>>> 
>>> How would you represent the canonicalization?
>> 
>> Basically, it boils down to the following requirement space for
>> DNSSEC to work with CLONE-type operations:
> 
> I'm sorry, I didn't understand your answer at all. I see dynamic signing as orthogonal to what I'm proposing, but if someone else wants to try and illuminate me, please feel free. :)

I'm of the opinion "If it can't do DNSSEC, we shouldn't do it".

Yes, DNSSEC makes life more complicated, but if we believe DNSSEC has ANY value, we MUST ensure that any proposed extensions to DNS, especially in how names are resolved, works with DNSSEC.  We shouldn't say "DNSSEC works only for ASCII" or "only for precanonicalized names".


Thus by that assumption and the assumption that this is for large-space canonicalization (so just static aliasing can't work), you MUST either do dynamic signing or have your CLONE RRs be a canonicalization program, not just a mapping from A->B. 

And there are some (NOT ME, but some) who don't like the idea of anything which requires dynamic signing.

And thus, dynamic signing is not orthoginal, as your current proposal requires dynamic signing for DNSSEC to work.