I suggest you review the past emails and the RFC's to find out what is
meant by a 'non-verifying DNSSEC cache'.
A DNSSEC-aware cache need not verify the responses it caches. It can
leave that task to the stub-resolver. By having the stub resolvers
perform the crypto checks, the crypto computation resources scale. Of
course, if the cache doesn't verify, it can't tell its been poisoned,
and so ordinary poisoning will work. But if the cache does verify, then
it has to perform a complex signature check, for which there are only
limited computational resources available to perform the check. DNSSEC
caches are cursed, either way.
--Dean
On Wed, 27 Aug 2008, Andrew Sullivan wrote:
> On Tue, Aug 26, 2008 at 05:25:44PM -0400, Dean Anderson wrote:
>
> > An actual poisoning of a non-verifing DNSSEC cache, yes. This is pretty
>
> Wait a minute. You're proposing to show that "a DNSSEC cache" that
> doesn't actually do DNSSEC (whatever that would mean) can be poisoned?
> I'm not sure I see the reasoning. I don't think that a positive
> result would be very big news at all -- in my view, a DNSSEC cache
> that doesn't validate responses is, well, not a DNSSEC cache at all.
>
> Is your concern that a DNSSEC-aware recursing resolver, with
> validation turned off, can be poisoned even though it correctly
> handles all the DNSSEC-requesting questions from a stub resolver, and
> correctly handles the data from a DNSSEC-offering server, in the case
> where Mallory can win the race and answer the non-validating
> DNSSEC-aware resolver before the legitimate server?
>
> A
>
>
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
