DNSSEC : once correct, always correct ?

Paul Wouters paul at xelerance.com
Wed Aug 17 16:29:13 UTC 2011

On Wed, 17 Aug 2011, Marc Lampo wrote:

> I did indeed deliberately remove the old DNSKEY,
> Before RRSIG's generated with it got expired from the cache.
> But to my surprise, the validating caching name server
> still replies correctly !
> Meaning that that it actually does not re-verify,
> once data was found to be OK and allowed in the cache.

Right. Why would it do that? If verifies the data to be correct,
and the data does not "become incorrect". There is only correct
data with an expiry on it based on TTL and RRSIG expiry time.

> With that behaviour, it are the (validating) user of that
> caching name server that will encounter problems.
> I'm unsure this is desirable behaviour,
> which I wanted to bring to attention.

It is. A validator cannot re-validate every piece in its cache whenever it
is about to give it to a client. Think about it, it would intself cause
an infinite validation loop attempting to revalidate its own cache. Some
implementations might be a little more helpful, and try to do some extra
work when it sees invalid data and try to refetch some data even before
the TTL is up. But as DNS operator you must not depend on that. Once
you handout a properly signed piece of DNS data, you must assume as DNS
operator it will be out there as long as the TTL you on that data. And
assume that somewhere a validator might need to refetch the old DNSKEY
at $TTL-1 seconds in the future. That is the commitment you have made
when you published the DNSKEY RRset and the RRSIGs belonging to those keys.


More information about the bind-users mailing list