[dns-operations] The perils of retroactive DNSSEC validation

[Florian Weimer]

* Florian Weimer:

> DNSSEC, as it is currently deployed, assumes that it's possible to run
> a hierarchy of caches where validition efforts increase down the
> hierarchy (that is, an initiator has more trust anchors to work from
> than a responding cache).  Therefore, caches are expected to store
> data which they cannot validate ("Indeterminate" in the language of
> RFC 4035).

Quoting the original message in full.  Does it make more sense when
you replace "Indeterminate" with "Insecure"?

> The question that bugs me is: Why do you think this can actually work?
>
> For Bogus/BAD data (for the distinction or the lack thereof, see my
> question on the namedroppers list), an intermediate cache will
> eventually make an attempt at fetching the data again.  But not for
> Indeterminate data.  So once bad data ends up in the cache hierarchy,
> and there's no attempt at validation, it simply stays there, resulting
> in a rather effective denial of service.
>
> 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.)
>
> My conclusion is that validators forwarding to non-validating caches
> just don't work and should be deprecated.  This also means that
> Indeterminate answers are relegated to an odd corner case, and once
> that has happened, key rollovers and redelegation with key changes
> become much less daunting: If the involved zone operators make a
> mistake, RRsets may end up in the BAD cache described in RFC 4035,
> which should be a rather temporary situation.  On top of that, lack of
> a response from a name server for a query which should result in a
> response with Secure data could mean that the (unsigned) referral has
> been tampered with, so a cache can be expected to periodically recheck
> the delegation chain.  This will actually improve operator experience
> because mistakes are fixed much quicker.
>
> Unfortunately, while the suggestion above does not require protocol
> changes, it seem require extensive changes in some implementations
> because iterator, cache and validator and validator are separate
> modules (at least conceptually).  In other words, the valdiator
> validates retroactively, and the BAD cache does not seem to have been
> properly implemented.