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 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
