Note: This information is only applicable for the signer and enforcer as of version 2.0
Since the Signer is smart about rollovers (i.e. provide gradual transition between two keys) and the Enforcer supports ludicrous rollovers, we must take extra care in how the two communicate.
The Enforcer has the following directives in the signconf:
This flag is problematic. In order to spread load, the signer keeps using signatures of old keys which are not yet expired before generating signatures with the new key. The Enforcer does not necessary performs a roll between 2 keys but rather N keys. Additionally a zone might be signed with multiple key of the same algorithm.
The challenge is for the signer to find out when new signatures must be generated and with which keys. The Figure below shows the decision tree Matthijs and I figured out.
The signer first of all loops through all RR sets, then over all keys. Each iteration the tree is consulted. We can define 4 different checks:
This specification leads to the following behavior: