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

[Doug Barton <[e-mail]>]

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/