DNSSEC : once correct, always correct ?

[Paul Wouters]

On Wed, 17 Aug 2011, Marc Lampo wrote:

> It looks like once DNSSEC'd data validates correctly,
> that version of Bind will keep reusing that data (until TTL expires).

Or when the RRSIG expiry time is reached, whichever comes first.

> While it may make sense, to save on CPU cycles,
> I am unsure if that behaviour is correct :
> suppose a validating *forwarding* name server
> (or validating resolvers in clients, once we they become available)
> addresses this caching name server in that "condition".
> It would :
> 1) receive, from the cache, the data + (old) RRSIG
> 2) when queried for it, because the forwarding name server wants to
>   validate, it will deliver the (new) DNSKEY's
> --> validation should now fail !!!

This is why you rollover in two or three phases. You prepublish the new ZSK
key. The DNSKEY's are transmitted as an RRset, so the client/cache
will get the current and the future ZSK. When the RRSIG changed from
the old to the new key, you already have both (or neither) in the DNSKEY
RRset.

After rollover, you don't remove the old DNSKEY immediately, but leave it in
for a while, so that anyone who would have RRSIGs made by a DNSKEY, but no
longer has the DNSKEY RRset cached, can requery it and get old+new key.

Things are a little different depending on if you use a ZSK/KSK split or not.

> Very confusing for debugging :
> One validating name server yields AD-'d data;
> the other, using the first one, yields SERVFAIL ...

That means you botched the ZSK rollover. You should prepublish at least
the TTL period in advance or leave the cycled key for a TTL period in
the DNSKEY RRset.

Paul