1. 03 Jun, 2020 1 commit
  2. 02 Jun, 2020 3 commits
    • Matthijs Mekking's avatar
      Retire predecessor when creating successor · a17dcccf
      Matthijs Mekking authored
      When creating the successor, the current active key (predecessor)
      should change its goal state to HIDDEN.
      Also add two useful debug logs in the keymgr_key_rollover function.
      (cherry picked from commit e71d6029)
    • Matthijs Mekking's avatar
      Fix bug in keymgr_key_has_successor · 168d362b
      Matthijs Mekking authored
      The logic in `keymgr_key_has_successor(key, keyring)` is flawed, it
      returns true if there is any key in the keyring that has a successor,
      while what we really want here is to make sure that the given key
      has a successor in the given keyring.
      Rather than relying on `keymgr_key_exists_with_state`, walk the
      list of keys in the keyring and check if the key is a successor of
      the given predecessor key.
      (cherry picked from commit 0d578097)
    • Matthijs Mekking's avatar
      Add change entry · ba5d122f
      Matthijs Mekking authored
      (cherry picked from commit bcf3c9fe)
  3. 30 May, 2020 1 commit
  4. 29 May, 2020 1 commit
  5. 25 May, 2020 1 commit
  6. 19 May, 2020 4 commits
  7. 18 May, 2020 2 commits
  8. 15 May, 2020 1 commit
  9. 13 May, 2020 1 commit
  10. 12 May, 2020 2 commits
  11. 06 May, 2020 1 commit
  12. 05 May, 2020 1 commit
  13. 04 May, 2020 1 commit
  14. 02 May, 2020 1 commit
  15. 01 May, 2020 7 commits
  16. 30 Apr, 2020 1 commit
  17. 28 Apr, 2020 1 commit
  18. 22 Apr, 2020 1 commit
  19. 20 Apr, 2020 2 commits
    • Mark Andrews's avatar
    • Matthijs Mekking's avatar
      Address Coverity warnings in keymgr.c · 7ac4966a
      Matthijs Mekking authored
      Coverity showed that the return value of `dst_key_gettime` was
      unchecked in INITIALIZE_STATE. If DST_TIME_CREATED was not set we
      would set the state to be initialized to a weird last changed time.
      This would normally not happen because DST_TIME_CREATED is always
      set. However, we would rather set the time to now (as the comment
      also indicates) not match the creation time.
      The comment on INITIALIZE_STATE also needs updating as we no
      longer always initialize to HIDDEN.
      (cherry picked from commit 564f9dca)
  20. 17 Apr, 2020 1 commit
  21. 16 Apr, 2020 2 commits
  22. 08 Apr, 2020 4 commits
    • Michał Kępień's avatar
      Tweak CHANGES for BIND 9.16.2 · aeb1eb20
      Michał Kępień authored
    • Ondřej Surý's avatar
      Add missing CHANGES notes from v9_16 branch · cb100ed5
      Ondřej Surý authored
      (cherry picked from commit 2ef11495)
    • Ondřej Surý's avatar
      Add missing CHANGES notes from v9_11 branch · 9777aab8
      Ondřej Surý authored
      (cherry picked from commit 434929b5)
    • Matthijs Mekking's avatar
      Fix kasp timing issue on Windows · 9b57ad68
      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.
      (cherry picked from commit 62a97570)