[dns-operations] The perils of retroactive DNSSEC validation

Florian Weimer fw at deneb.enyo.de
Fri Nov 14 13:51:16 UTC 2008

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

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 mailing list