1. 08 Apr, 2020 18 commits
  2. 07 Apr, 2020 4 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.
      04e67110
    • Matthijs Mekking's avatar
      Fix ns6 template zonefile · 8d3c0156
      Matthijs Mekking authored
      The template zone file for server ns6 should have the ns6 domain
      name, not ns3.
      8d3c0156
    • Matthijs Mekking's avatar
      Remove kasp Windows prereq check · 87c05fa6
      Matthijs Mekking authored
      Now that the timing issue is fixed, we can enable the kasp test
      again on Windows.
      87c05fa6
    • 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.
      62a97570
  3. 06 Apr, 2020 4 commits
  4. 03 Apr, 2020 14 commits
    • Ondřej Surý's avatar
      Merge branch '1087-fix-the-nonmatching-statcounter-increments-decrements' into 'master' · bb876130
      Ondřej Surý authored
      Fix the some of the underflowing statistics
      
      See merge request !3299
      bb876130
    • Ondřej Surý's avatar
      Add CHANGES · 22aaeb51
      Ondřej Surý authored
      22aaeb51
    • Ondřej Surý's avatar
      Fix the statistic counter underflow in ns_client_t · 78886d4b
      Ondřej Surý authored
      In case of normal fetch, the .recursionquota is attached and
      ns_statscounter_recursclients is incremented when the fetch is created.  Then
      the .recursionquota is detached and the counter decremented in the
      fetch_callback().
      
      In case of prefetch or rpzfetch, the quota is attached, but the counter is not
      incremented.  When we reach the soft-quota, the function returns early but don't
      detach from the quota, and it gets destroyed during the ns_client_endrequest(),
      so no memory was leaked.
      
      But because the ns_statscounter_recursclients is only incremented during the
      normal fetch the counter would be incorrectly decremented on two occassions:
      
      1) When we reached the softquota, because the quota was not properly detached
      2) When the prefetch or rpzfetch was cancelled mid-flight and the callback
         function was never called.
      78886d4b
    • Ondřej Surý's avatar
    • Witold Krecicki's avatar
    • Matthijs Mekking's avatar
      Merge branch '1179-dnssec-stats-oom-kill' into 'master' · 663047ac
      Matthijs Mekking authored
      Resolve "OOM issue after upgrade from 9.14.3 to 9.14.4"
      
      Closes #1179
      
      See merge request !3304
      663047ac
    • Matthijs Mekking's avatar
      Update release notes · 386890a1
      Matthijs Mekking authored
      386890a1
    • Matthijs Mekking's avatar
      Replace hard coded value with constant · c1723b25
      Matthijs Mekking authored
      c1723b25
    • Matthijs Mekking's avatar
      Merge if blocks in statschannel.c · 1596d3b4
      Matthijs Mekking authored
      1596d3b4
    • Matthijs Mekking's avatar
      Replace sign operation bool with enum · 44b49955
      Matthijs Mekking authored
      44b49955
    • Matthijs Mekking's avatar
      Embed algorithm in key tag counter · b2028e26
      Matthijs Mekking authored
      Key tags are not unique across algorithms.
      b2028e26
    • Matthijs Mekking's avatar
      Group the keyid with the counters · eb6a8b47
      Matthijs Mekking authored
      Rather than group key ids together, group key id with its
      corresponding counters. This should make growing / shrinking easier
      than having keyids then counters.
      eb6a8b47
    • Matthijs Mekking's avatar
      Add test for many keys · 31e8b2b1
      Matthijs Mekking authored
      Add a statschannel test case for DNSSEC sign metrics that has more
      keys than there are allocated stats counters for.  This will produce
      gibberish, but at least it should not crash.
      31e8b2b1
    • Matthijs Mekking's avatar
      Redesign dnssec sign statistics · 705810d5
      Matthijs Mekking authored
      The first attempt to add DNSSEC sign statistics was naive: for each
      zone we allocated 64K counters, twice.  In reality each zone has at
      most four keys, so the new approach only has room for four keys per
      zone. If after a rollover more keys have signed the zone, existing
      keys are rotated out.
      
      The DNSSEC sign statistics has three counters per key, so twelve
      counters per zone. First counter is actually a key id, so it is
      clear what key contributed to the metrics.  The second counter
      tracks the number of generated signatures, and the third tracks
      how many of those are refreshes.
      
      This means that in the zone structure we no longer need two separate
      references to DNSSEC sign metrics: both the resign and refresh stats
      are kept in a single dns_stats structure.
      
      Incrementing dnssecsignstats:
      
      Whenever a dnssecsignstat is incremented, we look up the key id
      to see if we already are counting metrics for this key.  If so,
      we update the corresponding operation counter (resign or
      refresh).
      
      If the key is new, store the value in a new counter and increment
      corresponding counter.
      
      If all slots are full, we rotate the keys and overwrite the last
      slot with the new key.
      
      Dumping dnssecsignstats:
      
      Dumping dnssecsignstats is no longer a simple wrapper around
      isc_stats_dump, but uses the same principle.  The difference is that
      rather than dumping the index (key tag) and counter, we have to look
      up the corresponding counter.
      705810d5