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

Doug Barton <dougb@dougbarton.us> Tue, 08 March 2011 01:32 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 299083A69E0 for <dnsext@core3.amsl.com>; Mon, 7 Mar 2011 17:32:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.566
X-Spam-Level:
X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 2QN8rzG97Hct for <dnsext@core3.amsl.com>; Mon, 7 Mar 2011 17:31:58 -0800 (PST)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id A68553A69DF for <dnsext@ietf.org>; Mon, 7 Mar 2011 17:31:58 -0800 (PST)
Received: (qmail 13466 invoked by uid 399); 8 Mar 2011 01:33:08 -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 01:33:08 -0000
X-Originating-IP: 75.60.237.91
X-Sender: dougb@dougbarton.us
Message-ID: <4D758753.3090900@dougbarton.us>
Date: Mon, 07 Mar 2011 17:33:07 -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>
In-Reply-To: <79987316-C80C-4015-A3D3-77F8D2F33351@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 01:32:00 -0000

On 03/07/2011 07:47, Nicholas Weaver wrote:
>
> On Mar 7, 2011, at 5:56 AM, Doug Barton wrote:
>>
>> As promised I've managed to squeak this draft in under the wire. As
>> I say in the Foreword I expect that it will need some polishing,
>> and if the group chooses to adopt the document I look forward to
>> getting lots of help with that. :)
>
> Interesting,

Thanks. :)

> but a couple of comments:
>
> For the non-CLONE aware case (no EDNS0 option in query), I think
> instead of returning "as if" its an alias, INSTEAD it should be a
> CNAME or DNAME with TTL=0 with the part the authority is responsible
> for canonicalized.

All due respect, I think you're missing the whole point. :)  Users want 
to be able to use the variant labels (including things like being on the 
RHS of NS and MX records) so the idea is to deal with them on a basis 
that is as equal as possible.

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

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

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

> This enables CLONEs to be
> DNSSEC signed offline.  Otherwise, if you want DNSSEC EVEN FOR
> CLONE-aware clients, you need to...
>
>
> Discuss online signing.

I'm not sure why, but I'm happy to be educated. The idea I have in mind 
is that the zone for the preferred label can be DNSSEC signed in the 
regular way, and a CLONE-Aware resolver can validate responses for the 
CLONE labels "as if" they had been responses for the preferred labels.


Thanks again for the comments. :)

Doug


> [1]  I believe that if CLONE is just a simple pointer, it is
> unnecessary, because 0 TTL CNAMES and DNAMES can accomplish the same
> thing.  The value in a CLONE-type new RR and associated EDNS0
> signaling lies in allowing it to work with the offline DNSSEC
> signature model.

-- 

	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/