1. 18 Feb, 2019 18 commits
  2. 14 Feb, 2019 9 commits
    • Evan Hunt's avatar
      Merge branch '879-dnssec-checkds-help' into 'master' · 4d4233f6
      Evan Hunt authored
      Correct path in dnssec-checkds help
      Closes #879
      See merge request !1515
    • Petr Menšík's avatar
      Correct path in dnssec-checkds help · 7bd544e7
      Petr Menšík authored
    • Michał Kępień's avatar
      Merge branch '873-do-not-check-sep-bit-for-mirror-zone-trust-anchors' into 'master' · ef9b9035
      Michał Kępień authored
      Do not check SEP bit for mirror zone trust anchors
      Closes #873
      See merge request !1506
    • Michał Kępień's avatar
      Add CHANGES entry · 2b19b851
      Michał Kępień authored
      5161.	[bug]		Do not require the SEP bit to be set for mirror zone
      			trust anchors. [GL #873]
    • 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
      Merge branch 'michal/improve-stability-of-mirror-zone-tests' into 'master' · 724663c1
      Michał Kępień authored
      Improve stability of mirror zone system tests
      See merge request !1505
    • 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.
    • Michał Kępień's avatar
      Improve reliability of zone verification checks · 2cbf1028
      Michał Kępień authored
      In the "mirror" system test, ns3 periodically sends trust anchor
      telemetry queries to ns1 and ns2.  It may thus happen that for some
      non-recursive queries for names inside mirror zones which are not yet
      loaded, ns3 will be able to synthesize a negative answer from the cached
      records it obtained from trust anchor telemetry responses.  In such
      cases, NXDOMAIN responses will be sent with the root zone SOA in the
      AUTHORITY section.  Since the root zone used in the "mirror" system test
      has the same serial number as ns2/verify.db.in and zone verification
      checks look for the specified serial numbers anywhere in the answer, the
      test could be broken if different zone names were used.
      The +noauth dig option could be used to address this weakness, but that
      would prevent entire responses from being stored for later inspection,
      which in turn would hamper troubleshooting test failures.  Instead, use
      a different serial number for ns2/verify.db.in than for any other zone
      used in the "mirror" system test and check the number of records in the
      ANSWER section of each response.
    • Michał Kępień's avatar
      Fix serial number used in zone verification checks · 46480a4b
      Michał Kępień authored
      Due to the way the "mirror" system test is set up, it is impossible for
      the "verify-unsigned" and "verify-untrusted" zones to contain any serial
      number other than the original one present in ns2/verify.db.in.  Thus,
      using presence of a different serial number in the SOA records of these
      zones as an indicator of problems with mirror zone verification is
      wrong.  Look for the original zone serial number instead as that is the
      one that will be returned by ns3 if one of the aforementioned zones is
      successfully verified.
  3. 11 Feb, 2019 3 commits
  4. 10 Feb, 2019 2 commits
  5. 08 Feb, 2019 8 commits