1. 05 Jun, 2019 2 commits
  2. 04 Jun, 2019 1 commit
  3. 30 May, 2019 1 commit
  4. 11 Apr, 2019 2 commits
    • Matthijs Mekking's avatar
      With update-check-ksk also consider offline keys · 3cb8c49c
      Matthijs Mekking authored
      The option `update-check-ksk` will look if both KSK and ZSK are
      available before signing records.  It will make sure the keys are
      active and available.  However, for operational practices keys may
      be offline.  This commit relaxes the update-check-ksk check and will
      mark a key that is offline to be available when adding signature
    • Matthijs Mekking's avatar
      Style: some curly brackets · 2e83e325
      Matthijs Mekking authored
  5. 08 Mar, 2019 1 commit
  6. 22 Feb, 2019 5 commits
    • Matthijs Mekking's avatar
      Update CHANGES · e5565808
      Matthijs Mekking authored
    • Matthijs Mekking's avatar
      Unregister RPZ CATZ db cbs when zone load fails · 6ed14eff
      Matthijs Mekking authored
      In case when a zone fails to load because the file does not exist
      or is malformed, we should not run the callback that updates the
      zone database when the load is done.  This is achieved by
      unregistering the callbacks if at zone load end if the result
      indicates something else than success.
    • Matthijs Mekking's avatar
      Remove rpz->db_registered · 67562802
      Matthijs Mekking authored
      As pointed out in !813 db_registered is sort of redundant.  It is
      set to `true` only in `dns_zone_rpz_enable_db()` right before the
      `dns_rpz_dbupdate_callback()` callback is registered.  It is only
      required in that callback and it is the only place that the callback
      is registered.  Therefore there is no path that that `REQUIRE` can
      The `db_registered` variable is only set to `false` in
      `dns_rpz_new_zone`, so it is not like the variable is unset again
      The only other place where `db_registered` is checked is in
      `rpz_detach()`.  If `true`, it will call
      `dns_db_updatenotify_unregister()`.  However if that happens, the
      `db_registered` is not set back to `false` thus this implies that
      this may happen multiple times.  If called a second time, most
      likely the unregister function will return `ISC_R_NOTFOUND`, but
      the return value is not checked anyway.  So it can do without the
      `db_registered` check.
    • Matthijs Mekking's avatar
      Add curly brackets on if statements · 2e5e4296
      Matthijs Mekking authored
    • Matthijs Mekking's avatar
      named crashes on shutdown after load rpz failed · a490c091
      Matthijs Mekking authored
      This may happen when loading an RPZ failed and the code path skips
      calling dns_db_endload().  The dns_rpz_zone_t object is still kept
      marked as having registered db.  So when this object is finally
      destroyed in rpz_detach(), this code will incorrectly call
         if (rpz->db_registered)
                                          dns_rpz_dbupdate_callback, rpz);
      and trigger this assertion failure:
         REQUIRE(db != NULL);
      To fix this, only call `dns_db_updatenotify_unregister()` when
      `rpz->db` is not NULL.
  7. 21 Feb, 2019 2 commits
  8. 18 Feb, 2019 1 commit
  9. 14 Feb, 2019 2 commits
    • Michał Kępień's avatar
      Do not check SEP bit for mirror zone trust anchors · 72c20173
      Michał Kępień authored
      When a mirror zone is verified, the 'ignore_kskflag' argument passed to
      dns_zoneverify_dnssec() is set to false.  This means that in order for
      its verification to succeed, a mirror zone needs to have at least one
      key with the SEP bit set configured as a trust anchor.  This brings no
      security benefit and prevents zones signed only using keys without the
      SEP bit set from being mirrored, so change the value of the
      'ignore_kskflag' argument passed to dns_zoneverify_dnssec() to true.
    • Michał Kępień's avatar
      Prevent races when waiting for log messages · 9c611dd9
      Michał Kępień authored
      The "mirror" system test checks whether log messages announcing a mirror
      zone coming into effect are emitted properly.  However, the helper
      functions responsible for waiting for zone transfers and zone loading to
      complete do not wait for these exact log messages, but rather for other
      ones preceding them, which introduces a possibility of false positives.
      This problem cannot be addressed by just changing the log message to
      look for because the test still needs to discern between transferring a
      zone and loading a zone.
      Add two new log messages at debug level 99 (which is what named
      instances used in system tests are configured with) that are to be
      emitted after the log messages announcing a mirror zone coming into
      effect.  Tweak the aforementioned helper functions to only return once
      the log messages they originally looked for are followed by the newly
      added log messages.  This reliably prevents races when looking for
      "mirror zone is now in use" log messages and also enables a workaround
      previously put into place in the "mirror" system test to be reverted.
  10. 31 Jan, 2019 3 commits
  11. 21 Jan, 2019 1 commit
  12. 16 Jan, 2019 2 commits
    • Michał Kępień's avatar
      Log a message when a mirror zone becomes unusable · 7d6b8f7c
      Michał Kępień authored
      Log a message if a mirror zone becomes unusable for the resolver (most
      usually due to the zone's expiration timer firing).  Ensure that
      verification failures do not cause a mirror zone to be unloaded
      (instead, its last successfully verified version should be served if it
      is available).
    • Michał Kępień's avatar
      Log a message when a mirror zone loaded from disk comes into effect · 7665e132
      Michał Kępień authored
      Log a message when a mirror zone is successfully loaded from disk and
      subsequently verified.
      This could have been implemented in a simpler manner, e.g. by modifying
      an earlier code branch inside zone_postload() which checks whether the
      zone already has a database attached and calls attachdb() if it does
      not, but that would cause the resulting logs to indicate that a mirror
      zone comes into effect before the "loaded serial ..." message is logged,
      which would be confusing.
      Tweak some existing sed commands used in the "mirror" system test to
      ensure that separate test cases comprising it do not break each other.
  13. 09 Jan, 2019 1 commit
  14. 11 Dec, 2018 1 commit
  15. 10 Dec, 2018 1 commit
  16. 07 Dec, 2018 1 commit
  17. 22 Nov, 2018 2 commits
  18. 08 Nov, 2018 3 commits
  19. 26 Oct, 2018 2 commits
  20. 24 Oct, 2018 2 commits
    • Michał Kępień's avatar
      Replace the "mirror" zone option with "type mirror;" · 2cb9e8a0
      Michał Kępień authored
      Use a zone's 'type' field instead of the value of its DNS_ZONEOPT_MIRROR
      option for checking whether it is a mirror zone.  This makes said zone
      option and its associated helper function, dns_zone_mirror(), redundant,
      so remove them.  Remove a check specific to mirror zones from
      named_zone_reusable() since another check in that function ensures that
      changing a zone's type prevents it from being reused during
    • Michał Kępień's avatar
      Define a separate dns_zonetype_t for mirror zones · e1bb8de6
      Michał Kępień authored
      Rather than overloading dns_zone_slave and discerning between a slave
      zone and a mirror zone using a zone option, define a separate enum
      value, dns_zone_mirror, to be used exclusively by mirror zones.  Update
      code handling slave zones to ensure it also handles mirror zones where
  21. 23 Oct, 2018 2 commits
  22. 27 Sep, 2018 1 commit
    • Michał Kępień's avatar
      Prevent a race after zone load · 56003e9f
      Michał Kępień authored
      Zone loading happens in a different task (zone->loadtask) than other
      zone actions (zone->task).  Thus, when zone_postload() is called in the
      context of zone->loadtask, it may cause zone maintenance to be queued in
      zone->task and another thread can then execute zone_maintenance() before
      zone_postload() gets a chance to finish its work in the first thread.
      This would not be a problem if zone_maintenance() accounted for this
      possibility by locking the zone before checking the state of its
      DNS_ZONEFLG_LOADPENDING flag.  However, the zone is currently not locked
      before the state of that flag is checked, which may prevent zone
      maintenance from happening despite zone_postload() scheduling it.  Fix
      by locking the zone in zone_maintenance() before checking the state of
      the zone's DNS_ZONEFLG_LOADPENDING flag.
  23. 31 Aug, 2018 1 commit