DNSSEC : once correct, always correct ?

Marc Lampo marc.lampo at eurid.eu
Wed Aug 17 14:37:55 UTC 2011


Paul,

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.

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.

Kind regards,

Marc Lampo

-----Original Message-----
From: Paul Wouters [mailto:paul at xelerance.com] 
Sent: 17 August 2011 04:35 PM
To: Marc Lampo
Cc: bind-users at lists.isc.org
Subject: Re: DNSSEC : once correct, always correct ?

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



More information about the bind-users mailing list