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

Doug Barton <> Tue, 08 March 2011 22:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 376023A659B for <>; Tue, 8 Mar 2011 14:11:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.555
X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DCTXEPQO4AmX for <>; Tue, 8 Mar 2011 14:11:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 30A1F3A672F for <>; Tue, 8 Mar 2011 14:11:31 -0800 (PST)
Received: (qmail 29337 invoked by uid 399); 8 Mar 2011 22:12:42 -0000
Received: from (HELO ( by with ESMTPAM; 8 Mar 2011 22:12:42 -0000
Message-ID: <>
Date: Tue, 08 Mar 2011 14:12:41 -0800
From: Doug Barton <>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv: Gecko/20110304 Thunderbird/3.1.9
MIME-Version: 1.0
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
References: <> <> <> <E9EAA80C-78FF-4246-869F-CCB49A4AC1AD@ICSI.Berkeley.EDU> <> <9A985005-F13E-4165-A008-479FF92F3FFA@ICSI.Berkeley.EDU>
In-Reply-To: <9A985005-F13E-4165-A008-479FF92F3FFA@ICSI.Berkeley.EDU>
X-Enigmail-Version: 1.1.2
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Mar 2011 22:11:34 -0000

On 03/08/2011 13:37, Nicholas Weaver wrote:
> 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.

I think I understand what you're saying about incentive, I just want to 
be clear that there is nothing special about Arabic as it directly 
relates to the stub.

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

I agree with you, to some extent.

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

The solution I'm proposing does allow for validation of the variant 
labels, but it requires a CLONE-Aware resolver (and/or perhaps stub).

I think now I'm seeing more about what you mean in regards to a CLONE 
method utilizing dynamic signing, but what I don't understand is how you 
handle the DNSKEY problem for CLONEs at the zone level?

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

We'll have to agree to disagree on this. My proposal provides a 
mechanism for handling DNSSEC for the variants without dynamic signing, 
albeit it does require the resolver to be upgraded for it to work.

Meanwhile, I'm going to reply to your reply to my other thread here 
because I think it's relevant. If you're right that a non-CLONE-Aware 
resolver would pass the unknown RR if it's requested directly, then 
applications that are concerned about DNSSEC validation for the variants 
_could_ request the CLONES RR first, then handle the "transformation" to 
using the preferred version internally itself, or we could put that 
logic in the stub. If I understand other things you've written correctly 
you're saying that you don't want the stub/application layer to 
"pre-canonicalize" which I think what I'm suggesting in this paragraph 
would be, but I'm wondering why? To take IDNs as an example, we already 
require a "transformation" for U-label to A-label, so this wouldn't be 
that much different.

So how hard are things going to break if stubs start requesting an RR 
that the RNS doesn't understand?



	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)