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

Doug Barton <dougb@dougbarton.us> Tue, 08 March 2011 21:20 UTC

Return-Path: <dougb@dougbarton.us>
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 67CEE3A63CA for <dnsext@core3.amsl.com>; Tue, 8 Mar 2011 13:20:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level:
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 HoN1xkG3G2-j for <dnsext@core3.amsl.com>; Tue, 8 Mar 2011 13:20:56 -0800 (PST)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id C190E3A63C9 for <dnsext@ietf.org>; Tue, 8 Mar 2011 13:20:55 -0800 (PST)
Received: (qmail 28966 invoked by uid 399); 8 Mar 2011 21:22:06 -0000
Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 8 Mar 2011 21:22:06 -0000
X-Originating-IP: 75.60.237.91
X-Sender: dougb@dougbarton.us
Message-ID: <4D769DFD.2070507@dougbarton.us>
Date: Tue, 08 Mar 2011 13:22:05 -0800
From: Doug Barton <dougb@dougbarton.us>
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9
MIME-Version: 1.0
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
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>
In-Reply-To: <E9EAA80C-78FF-4246-869F-CCB49A4AC1AD@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
Cc: 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:20:57 -0000

On 03/08/2011 07:53, Nicholas Weaver wrote:
>
> On Mar 7, 2011, at 5:33 PM, Doug Barton wrote:
>>> The more important configuration is probably the model of
>>>
>>> CARNS STUB<---->   Non-CARNS Resolver<--->   CARNS Auth.
>>
>> I hadn't considered the idea of making a stub CLONE-Aware, but I
>> like it. :)
>
> This came up in private discussion when it was clear I had a
> different model (resolver change) vs I can't remember who (stub
> change).
>
> The result was I was convinced I was wrong:  I was convinced that
> Stub change is actually far more likely.
>
> 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?

> But with stub changes, ONLY those who actually benefit substantially
> need to change.

I think that concept has a lot of validity. OTOH the reason I'm 
suggesting a method that only requires authoritative server updates for 
all of the benefit other than DNSSEC.

>>> As it is far more likely that clients will upgrade (EG, as part
>>> of the browser or OS) rather than resolver authorities in many
>>> cases.
>>>
>>> I do not know if unknown EDNS0 options are likely to be passed
>>> from the stub to the authority through the intermediary
>>> resolver,
>>
>> I'm not sure what the default behavior is there, but if the actual
>> resolver is not CLONE-Aware then sending the option wouldn't help
>> since it wouldn't understand any CLONE RRs that it received back.
>
> Hmmm, which again makes me think the model might need to be more like
> how AAAA records are handeled: Do a parallel fetch for CLONE and use
> the result if it arrives within X ms of the cached record you were
> looking for, as unknown RTYPEs (mostly) work, and when they don't,
> the stub should be bypassing the configured recursive resolver
> anyway.

This method of operation is very different than what I'm proposing, but 
I'd be interested in whether other people think that it would be an 
improvement.

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


Doug

-- 

	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.  :)  http://SupersetSolutions.com/