[dns-operations] The perils of retroactive DNSSEC validation
Ed.Lewis at neustar.biz
Thu Nov 20 16:05:51 UTC 2008
At 15:02 +0100 11/20/08, Florian Weimer wrote:
>> 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"?
First, comparing "Insecure" with "Bad/Bogus".
To me what is called "Insecure" is the same as "Secure." The reason
is that, given the complete assortment of records that a validator
would use in testing the authenticity and integrity of the "RRset
under test", the validator definitively concludes "DNSSEC is turned
off for this RRset." To me that is secure.
Innocent until proven guilty -or- guilty until proven innocent.
That's the choice.
Given the open nature assumed in the Internet (dang the attacks!) I
go for the former and believe that unless you can employ the records
and state that the RRset under test has been tampered with, it's best
to plough on. Even if the RRset has a (non-germane to me) signature.
Which assumption is ultimately chosen is up to "local policy" BTW.
So, getting back to the message, and why I curtly answered "no."
Let's look at this question "why would one cache mark an answer as
'insecure' but another 'secure'?" The answer lies in local trust
anchors. It wouldn't be time-of-day (which might make signature fail
in one and not the other, bogus) or missing data (indeterminate).
What is the impact of the data being insecure in one place and secure
in another? I don't think there is much. Wouldn't both give the
same answer regardless of the CD bit setting in the query? Wouldn't
both respond with the AD bit set (as in both cases, the data passed
I suppose if a local policy says that cached data that is not
cryptographically validated is bogus changes things. And let's go
with that, even though I think such a policy is not wise (as in
overly paranoid). In that case, CD=1 returns SERVFAIL but CD=0
exposes the bogus data as it is cached. As always, if you are going
to validate yourself you should ignore the AD bit in response and set
CD=1 in the query.
So, what changes insecure to secure - it is the introduction of a DS
RRset in the right place(s). It's hard to predict the mean time to
such an event though, either this happens when a zone transitions
from one state to another, or someone notices a botched key
supercession (rollover). Both of these will involve human
intervention. I point that out because I can't see that twiddling
with the TTL settings is going to matter much.
>> 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.
Considering I equate Secure with Insecure, I don't see the need to
try to refresh the data. It'll stay as long as the TTL is ticking
"So once bad data...it simply stays there" - there isn't any "class"
of data that is immune to the TTL. And a nameserver can place a
limit on how high TTL can be - like, I believe, BIND caps it at one
week's worth of seconds.
>> 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
That's true - no one is going to want caches to overwrite data that
has been used without problem. And the DNS is careful not to allow a
TTL to ever be "upped."
Edward Lewis +1-571-434-5468
Never confuse activity with progress. Activity pays more.
More information about the dns-operations