[dns-operations] The perils of retroactive DNSSEC validation

[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.

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.  (Certainly 
we don't want to give an arbitrary querier the ability to cause 
caches to dump all the time, regardless of which cache.)

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.  An 
admin can suspect an attack and tell from lots of other data, but the 
DNS mechanics don't have the mechanisms for it.  (It would take a lot 
of state holding to tell if something is repeated in a malicious way, 
etc.  And you'd have to define the diffence between a broken 
application and a determined effort to be a nuisance.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.