[dns-operations] The perils of retroactive DNSSEC validation

[Florian Weimer]

* Edward Lewis:

> The first question I have is about "hierarchy of caches."  This is not
> a concept I am familiar with.  Do you mean an answer that is gleaned
> from cache that received the answer from a different cache (and so on)
> as in a forwarding environment or are you referring to the data in a
> domain hierarchy that is stored in a single, "remote" cache?

The "hierarchy of caches" refers to a chain of forwarders.  The stub
will likely end up with some sort of cache, too, to avoid repeated
crypto operations.

> OTOH, I may understand what you mean by caches holding data that fails
> validation.

That's covered in RFC 4035.  The problem is data which only fails
validation further down the chain.  Down there, it's generally
impossible to fetch better data; all you get from upstream caches is
the same cached data.

>>It's hard to see that anyone is going to attempt a cache flush
>>procedure because our bad experience with updating data before the TTL
>>expires.  So it's difficult to see how this is going to be fixed.
>>(Signing the root doesn't help if the caching hierarchy is mostly
>>non-validating.)
>
> There's no scale-able solution to cache flushing.  I mean, it can be
> done managed service situation (there are products that do it), but
> not on the scale of the Internet.

The initiator could set a flag, similarly to the RD bit, which
requests new data.  This has been implemented for HTTP, for instance.

>>My conclusion is that validators forwarding to non-validating caches
>>just don't work and should be deprecated.
>
> I don't understand this.  First, a forwarder has "up to" one bit of
> information regarding the DNSSEC capabilities of the requestor (the DO
> bit in the [optional] EDNS0 OPT RR).

DO has nothing to do with validation.

> Let's say you get an RRset with a signature valid for November
> 2008. And for simplicity let's say you have a trust anchor validating
> the key in the signer field.  What does "retroactively validate" mean?

I meant "first populate the cache, then validate", in contrast to
"validate and store on success".