[dns-operations] The perils of retroactive DNSSEC validation
fw at deneb.enyo.de
Thu Nov 20 14:02:19 UTC 2008
* 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
> 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.
More information about the dns-operations