Re: Protecting caches?
At 8:26 PM +0000 8/29/08, Paul Vixie wrote:[color=blue][color=green]
> > Adding "or glue from a primary zone" to the list in the first sentence
>> would eliminate the effects of the Kaminsky attack, would it not?[/color]
>for replacement, but not insertion, yes.[/color]
> > >however, it's ultimately desireable that a long TTL not lock out
>> >same-credibility replacement data. TTL is about expiry not replacement.[/color]
>> That is the crux of the question. It sounds like you disagree with my
>> assessment that the disadvantage of this policy (the Kaminsky attack) is
>> stronger than the advantage (allowing replacement before expiry, even if
>> the replacement is from an attacker).[/color]
>i know there are a lot of working configurations which depend on low latency
>cache replacement and so have long ttl's. we'd be breaking these. i suspect
>that there are more such currently working configurations than i know about.[/color]
Could you (or someone) describe these? What is their reason for a
long TTL if they know there is going to be a replacement?
--Paul Hoffman, Director
to unsubscribe send a message to [email]email@example.com[/email] with
the word 'unsubscribe' in a single line as the message text body.