[dns-operations] The perils of retroactive DNSSEC validation

[Florian Weimer]

* Edward Lewis:

> At 0:29 +0100 11/15/08, Florian Weimer wrote:
>
>>2) is impossible if it's intermittent Bogus data, like in an attack.
>>The RRset will expire quickly from the BAD cache, but the upstream
>>query will just retrieve that data again because the upstream cache
>>has cached it in Indeterminate state, subject to the normal TTL rules.
>
> So, it's like this - you ask for data, a cache gets it but can't
> complete the validation because it gets a SERVFAIL trying to get a
> needed key to complete the chain.  Failing to complete the validation
> means the data is labeled Bogus and be held as such until the TTL
> expires.  I mean, that's what I read as your concern.

No, this is not the way the BAD cache in RFC 4035 is supposed to work
(assuming that BAD == Bogus, which isn't clear).  BAD data should get
an artificial TTL, just like an unreachable nameserver in classic DNS
(so that you avoid flooding someone with queries it cannot answer
properly at the moment).

> For the same reason as we lack a way to flush the NCACHE, we'll
> probably continue to lack a way to flush the BAD cache.

You need to flush data in Indeterminate state.

> One of the parts of your question that makes it hard for to understand
> is that your refer to "being in an attack."  I understand you can see
> unusual traffic patterns, but I don't know that the protocol can be
> used to determine if it is in an attack state.

Successful cache poisoning may lead to Indeterminate data being
cached.  A validating resolver using this cache may detect this, but
it has no way of recovering from the attack before the data expires
from the cache.  Due to the Indeterminate state, this is governed by
the regular TTL on RRsets, something that the attacker probably can
control.

However, the far more relevant scenarion involves cached data which
can't be validated because of an operator error (or corner cases, like
DS and NS RRsets diverging after a redelegation).