1. 30 Jul, 2020 1 commit
    • Michal Nowak's avatar
      Drop $SYSTEMTESTTOP from bin/tests/system/ · 093af1c0
      Michal Nowak authored
      The $SYSTEMTESTTOP shell variable if often set to .. in various shell
      scripts inside bin/tests/system/, but most of the time it is only
      used one line later, while sourcing conf.sh. This hardly improves
      code readability.
      $SYSTEMTESTTOP is also used for the purpose of referencing
      scripts/files living in bin/tests/system/, but given that the
      variable is always set to a short, relative path, we can drop it and
      replace all of its occurrences with the relative path without adversely
      affecting code readability.
  2. 26 Jun, 2020 1 commit
    • Matthijs Mekking's avatar
      kasp tests: fix wait for reconfig done · a47192ed
      Matthijs Mekking authored
      The wait until zones are signed after rndc reconfig is broken
      because the zones are already signed before the reconfig.  Fix
      by having a different way to ensure the signing of the zone is
      complete.  This does require a call to the "wait_for_done_signing"
      function after each "check_keys" call after the ns6 reconfig.
      The "wait_for_done_signing" looks for a (newly added) debug log
      message that named will output if it is done signing with a certain
  3. 02 Jun, 2020 3 commits
    • Matthijs Mekking's avatar
      Test keytimes on algorithm rollover · 61c1040a
      Matthijs Mekking authored
      This improves keytime testing on algorithm rollover.  It now
      tests for specific times, and also tests for SyncPublish and
      Removed keytimes.
    • Matthijs Mekking's avatar
      Test keytimes on policy changes · da5e1e3a
      Matthijs Mekking authored
      This improves keytime testing on reconfiguration of the
    • Matthijs Mekking's avatar
      Move setting keytimes from settime to keygen · 637d5f9a
      Matthijs Mekking authored
      In the kasp system test, we are going to set the keytimes on
      dnssec-keygen so we can test them against the key creation time.
      This prevents off by one second in the test, something that can
      happen if you set those times with dnssec-settime after
      Also fix some test output filenames.
  4. 07 Apr, 2020 2 commits
    • Matthijs Mekking's avatar
      Increase migrate.kasp DNSKEY TTL · 04e67110
      Matthijs Mekking authored
      Increate the DNSKEY TTL of the migrate.kasp zone for the following
      reason:  The key states are initialized depending on the timing
      metadata. If a key is present long enough in the zone it will be
      initialized to OMNIPRESENT.  Long enough here is the time when it
      was published (when the setup script was run) plus DNSKEY TTL.
      Otherwise it is set to RUMOURED, or to HIDDEN if no timing metadata
      is set or the time is still in the future.
      Since the TTL is "only" 5 minutes, the DNSKEY state may be
      initialized to OMNIPRESENT if the test is slow, but we expect it
      to be in RUMOURED state.  If we increase the TTL to a couple of
      hours it is very unlikely that it will be initialized to something
      else than RUMOURED.
    • Matthijs Mekking's avatar
      Fix kasp timing issue on Windows · 62a97570
      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.
  5. 03 Apr, 2020 4 commits
    • Matthijs Mekking's avatar
      Test migration to dnssec-policy, change algorithm · 551acb44
      Matthijs Mekking authored
      Add a test to ensure migration from 'auto-dnssec maintain;' to
      dnssec-policy works even if the algorithm is changed.  The existing
      keys should not be removed immediately, but their goal should be
      changed to become hidden, and the new keys with the different
      algorithm should be introduced immediately.
    • Matthijs Mekking's avatar
      Only initialize goal on active keys · 2389fcb4
      Matthijs Mekking authored
      If we initialize goals on all keys, superfluous keys that match
      the policy all desire to be active.  For example, there are six
      keys available for a policy that needs just two, we only want to
      set the goal state to OMNIPRESENT on two keys, not six.
    • Matthijs Mekking's avatar
      Test migration to dnssec-policy, retire old keys · 7f435208
      Matthijs Mekking authored
      Migrating from 'auto-dnssec maintain;' to dnssec-policy did not
      work properly, mainly because the legacy keys were initialized
      badly.  Earlier commit deals with migration where existing keys
      match the policy.  This commit deals with migration where existing
      keys do not match the policy.  In that case, named must not
      immediately delete the existing keys, but gracefully roll to the
      However, named did remove the existing keys immediately.  This is
      because the legacy key states were initialized badly.  Because
      those keys had their states initialized to HIDDEN or RUMOURED, the
      keymgr decides that they can be removed (because only when the key
      has its states in OMNIPRESENT it can be used safely).
      The original thought to initialize key states to HIDDEN (and
      RUMOURED to deal with existing keys) was to ensure that those keys
      will go through the required propagation time before the keymgr
      decides they can be used safely.  However, those keys are already
      in the zone for a long time and making the key states represent
      otherwise is dangerous: keys may be pulled out of the zone while
      in fact they are required to establish the chain of trust.
      Fix initializing key states for existing keys by looking more closely
      at the time metadata.  Add TTL and propagation delays to the time
      metadata and see if the DNSSEC records have been propagated.
      Initialize the state to OMNIPRESENT if so, otherwise initialize to
      RUMOURED.  If the time metadata is in the future, or does not exist,
      keep initializing the state to HIDDEN.
      The added test makes sure that new keys matching the policy are
      introduced, but existing keys are kept in the zone until the new
      keys have been propagated.
    • Matthijs Mekking's avatar
      Fix and test migration to dnssec-policy · 68018991
      Matthijs Mekking authored
      Migrating from 'auto-dnssec maintain;' to dnssec-policy did not
      work properly, mainly because the legacy keys were initialized
      badly. Several adjustments in the keymgr are required to get it right:
      - Set published time on keys when we calculate prepublication time.
        This is not strictly necessary, but it is weird to have an active
        key without the published time set.
      - Initalize key states also before matching keys. Determine the
        target state by looking at existing time metadata: If the time
        data is set and is in the past, it is a hint that the key and
        its corresponding records have been published in the zone already,
        and the state is initialized to RUMOURED. Otherwise, initialize it
        as HIDDEN. This fixes migration to dnssec-policy from existing
      - Initialize key goal on keys that match key policy to OMNIPRESENT.
        These may be existing legacy keys that are being migrated.
      - A key that has its goal to OMNIPRESENT *or* an active key can
        match a kasp key.  The code was changed with CHANGE 5354 that
        was a bugfix to prevent creating new KSK keys for zones in the
        initial stage of signing.  However, this caused problems for
        restarts when rollovers are in progress, because an outroducing
        key can still be an active key.
      The test for this introduces a new KEY property 'legacy'.  This is
      used to skip tests related to .state files.
  6. 06 Mar, 2020 3 commits
    • Matthijs Mekking's avatar
      Add additional wait period for algorithm rollover · d1652053
      Matthijs Mekking authored
      We may be checking the algorithm steps too fast: the reconfig
      command may still be in progress. Make sure the zones are signed
      and loaded by digging the NSEC records for these zones.
    • Matthijs Mekking's avatar
      Add CSK algorithm rollover test · 917cf5f8
      Matthijs Mekking authored
    • Matthijs Mekking's avatar
      Add algorithm rollover test case · 88ebe958
      Matthijs Mekking authored
      Add a test case for algorithm rollover.  This is triggered by
      changing the dnssec-policy.  A new nameserver ns6 is introduced
      for tests related to dnssec-policy changes.
      This requires a slight change in check_next_key_event to only
      check the last occurrence.  Also, change the debug log message in
      lib/dns/zone.c to deal with checks when no next scheduled key event
      exists (and default to loadkeys interval 3600).