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

[Doug Barton <[e-mail]>]

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/