-
Matthijs Mekking authored
This fixes another intermittent failure in the kasp system test. It does not happen often, except for in the Windows platform tests where it takes a long time to run the tests. In the "kasp" system test, there is an "rndc reconfig" call which triggers a new rekey event. check_next_key_event() verifies the time remaining from the moment "rndc reconfig" is called until the next key event. However, the next key event time is calculated from the key times provided during key creation (i.e. during test setup). Given this, if "rndc reconfig" is called a significant amount of time after the test is started, some check_next_key_event() checks will fail. Fix by calculating the time passed since the start of the test and when 'rndc reconfig' happens. Substract this time from the calculated next key event. This only needs to be done after an "rndc reconfig" on zones where the keymgr needs to wait for a period of time (for example for keys to become OMNIPRESENT, or HIDDEN). This is on step 2 and step 5 of the algorithm rollover. In step 2 there is a waiting period before the DNSKEY is OMNIPRESENT, in step 5 there is a waiting period before the DNSKEY is HIDDEN. In step 1 new keys are created, in step 3 and 4 key states just entered OMNIPRESENT, and in step 6 we no longer care because the key lifetime is unlimited and we default to checking once per hour. Regardless of our indifference about the next key event after step 6, change some of the key timings in the setup script to better reflect reality: DNSKEY is in HIDDEN after step 5, DS times have changed when the new DS became active.
62a97570