1. 10 May, 2019 1 commit
    • Michał Kępień's avatar
      Make NTAs work with validating forwarders · 5e804882
      Michał Kępień authored
      If named is configured to perform DNSSEC validation and also forwards
      all queries ("forward only;") to validating resolvers, negative trust
      anchors do not work properly because the CD bit is not set in queries
      sent to the forwarders.  As a result, instead of retrieving bogus DNSSEC
      material and making validation decisions based on its configuration,
      named is only receiving SERVFAIL responses to queries for bogus data.
      Fix by ensuring the CD bit is always set in queries sent to forwarders
      if the query name is covered by an NTA.
  2. 09 May, 2019 2 commits
    • Tony Finch's avatar
      Deprecate SHA-1 DS digests in `dnssec-signzone` · d8f2eb24
      Tony Finch authored
      This affects two cases:
        * When writing a `dsset` file for this zone, to be used by its
          parent, only write a SHA-256 DS record.
        * When reading a `keyset` file for a child, to generate DS records
          to include in this zone, generate SHA-256 DS records only.
      This change does not affect digests used in CDS records.
      This is for conformance with the DS/CDS algorithm requirements in
    • Tony Finch's avatar
      Deprecate SHA-1 in `dnssec-dsfromkey` · 796a6c4e
      Tony Finch authored
      This makes the `-12a` options to `dnssec-dsfromkey` work more like
      `dnssec-cds`, in that you can specify more than one digest and you
      will get multiple records. (Previously you could only get one
      non-default digest type at a time.)
      The default is now `-2`. You can get the old behaviour with `-12`.
      Tests and tools that use `dnssec-dsfromkey` have been updated to use
      `-12` where necessary.
      This is for conformance with the DS/CDS algorithm requirements in
  3. 26 Apr, 2019 1 commit
    • Michał Kępień's avatar
      Simplify trailing period handling in system tests · da2c1b74
      Michał Kępień authored
      Windows systems do not allow a trailing period in file names while Unix
      systems do.  When BIND system tests are run, the $TP environment
      variable is set to an empty string on Windows systems and to "." on Unix
      systems.  This environment variable is then used by system test scripts
      for handling this discrepancy properly.
      In multiple system test scripts, a variable holding a zone name is set
      to a string with a trailing period while the names of the zone's
      corresponding dlvset-* and/or dsset-* files are determined using
      numerous sed invocations like the following one:
          dlvsets="$dlvsets dlvset-`echo $zone |sed -e "s/.$//g"`$TP"
      In order to improve code readability, use zone names without trailing
      periods and replace sed invocations with variable substitutions.
      To retain local consistency, also remove the trailing period from
      certain other zone names used in system tests that are not subsequently
      processed using sed.
  4. 23 Apr, 2019 2 commits
    • Matthijs Mekking's avatar
      Harden grep key ID calls · 83473b97
      Matthijs Mekking authored
      Key IDs may accidentally match dig output that is not the key ID (for
      example the RRSIG inception or expiration time, the query ID, ...).
      Search for key ID + signer name should prevent that, as that is what
      only should occur in the RRSIG record, and signer name always follows
      the key ID.
    • Matthijs Mekking's avatar
      Remove sleeps · 67f0635f
      Matthijs Mekking authored
      Remove sleep calls from test, rely on wait_for_log().  Make
      wait_for_log() and dnssec_loadkeys_on() fail the test if the
      appropriate log line is not found.
      Slightly adjust the echo_i() lines to print only the key ID (not the
      key name).
  5. 19 Apr, 2019 1 commit
    • Michał Kępień's avatar
      Fix the "dnssec" system test on Windows · e4280ed9
      Michał Kępień authored
      On Windows, the bin/tests/system/dnssec/signer/example.db.signed file
      contains carriage return characters at the end of each line.  Remove
      them before passing the aforementioned file to the awk script extracting
      key IDs so that the latter can work properly.
  6. 11 Apr, 2019 1 commit
    • Matthijs Mekking's avatar
      Add test for ZSK rollover while KSK offline · 8bc10bcf
      Matthijs Mekking authored
      This commit adds a lengthy test where the ZSK is rolled but the
      KSK is offline (except for when the DNSKEY RRset is changed).  The
      specific scenario has the `dnskey-kskonly` configuration option set
      meaning the DNSKEY RRset should only be signed with the KSK.
      A new zone `updatecheck-kskonly.secure` is added to test against,
      that can be dynamically updated, and that can be controlled with rndc
      to load the DNSSEC keys.
      There are some pre-checks for this test to make sure everything is
      fine before the ZSK roll, after the new ZSK is published, and after
      the old ZSK is deleted.  Note there are actually two ZSK rolls in
      quick succession.
      When the latest added ZSK becomes active and its predecessor becomes
      inactive, the KSK is offline.  However, the DNSKEY RRset did not
      change and it has a good signature that is valid for long enough.
      The expected behavior is that the DNSKEY RRset stays signed with
      the KSK only (signature does not need to change).  However, the
      test will fail because after reconfiguring the keys for the zone,
      it wants to add re-sign tasks for the new active keys (in sign_apex).
      Because the KSK is offline, named determines that the only other
      active key, the latest ZSK, will be used to resign the DNSKEY RRset,
      in addition to keeping the RRSIG of the KSK.
      The question is: Why do we need to resign the DNSKEY RRset
      immediately when a new key becomes active?  This is not required,
      only once the next resign task is triggered the new active key
      should replace signatures that are in need of refreshing.
  7. 20 Mar, 2019 1 commit
    • Michał Kępień's avatar
      Fix key ID extraction in the "dnssec" system test · a40c60e4
      Michał Kępień authored
      Simply looking for the key ID surrounded by spaces in the tested
      dnssec-signzone output file is not a precise enough method of checking
      for signatures prepared using a given key ID: it can be tripped up by
      cross-algorithm key ID collisions and certain low key IDs (e.g. 60, the
      TTL specified in bin/tests/system/dnssec/signer/example.db.in), which
      triggers false positives for the "dnssec" system test.  Make key ID
      extraction precise by using an awk script which operates on specific
  8. 19 Mar, 2019 3 commits
  9. 15 Mar, 2019 1 commit
  10. 11 Mar, 2019 5 commits
    • Mark Andrews's avatar
      ${ttl} must exist and be non null · dee1f1a4
      Mark Andrews authored
    • Michał Kępień's avatar
      Make ANSWER TTL capping checks stricter · a85cc414
      Michał Kępień authored
      For checks querying a named instance with "dnssec-accept-expired yes;"
      set, authoritative responses have a TTL of 300 seconds.  Assuming empty
      resolver cache, TTLs of RRsets in the ANSWER section of the first
      response to a given query will always match their authoritative
      counterparts.  Also note that for a DNSSEC-validating named resolver,
      validated RRsets replace any existing non-validated RRsets with the same
      owner name and type, e.g. cached from responses received while resolving
      CD=1 queries.  Since TTL capping happens before a validated RRset is
      inserted into the cache and RRSIG expiry time does not impose an upper
      TTL bound when "dnssec-accept-expired yes;" is set and, as pointed out
      above, the original TTLs of the relevant RRsets equal 300 seconds, the
      RRsets in the ANSWER section of the responses to expiring.example/SOA
      and expired.example/SOA queries sent with CD=0 should always be exactly
      120 seconds, never a lower value.  Make the relevant TTL checks stricter
      to reflect that.
    • Michał Kępień's avatar
      Relax ADDITIONAL TTL capping checks · 8baf8590
      Michał Kępień authored
      Always expecting a TTL of exactly 300 seconds for RRsets found in the
      ADDITIONAL section of responses received for CD=1 queries sent during
      TTL capping checks is too strict since these responses will contain
      records cached from multiple DNS messages received during the resolution
      In responses to queries sent with CD=1, ns.expiring.example/A in the
      ADDITIONAL section will come from a delegation returned by ns2 while the
      ANSWER section will come from an authoritative answer returned by ns3.
      If the queries to ns2 and ns3 happen at different Unix timestamps,
      RRsets cached from the older response will have a different TTL by the
      time they are returned to dig, triggering a false positive.
      Allow a safety margin of 60 seconds for checks inspecting the ADDITIONAL
      section of responses to queries sent with CD=1 to fix the issue.  A
      safety margin this large is likely overkill, but it is used nevertheless
      for consistency with similar safety margins used in other TTL capping
    • Michał Kępień's avatar
      Fix message section checked in a TTL capping test · a597bd52
      Michał Kępień authored
      Commit c032c54d inadvertently changed
      the DNS message section inspected by one of the TTL capping checks from
      ADDITIONAL to ANSWER, introducing a discrepancy between that check's
      description and its actual meaning.  Revert to inspecting the ADDITIONAL
      section in the aforementioned check.
    • Michał Kępień's avatar
      Fix NTA-related races · 9a36a1bb
      Michał Kępień authored
      Changes introduced by commit 6b8e4d6e
      were incomplete as not all time-sensitive checks were updated to match
      revised "nta-lifetime" and "nta-recheck" values.  Prevent rare false
      positives by updating all NTA-related checks so that they work reliably
      with "nta-lifetime 12s;" and "nta-recheck 9s;".  Update comments as well
      to prevent confusion.
  11. 28 Feb, 2019 1 commit
  12. 21 Feb, 2019 2 commits
  13. 31 Jan, 2019 1 commit
    • Evan Hunt's avatar
      silence a spurious dnssec-keygen warning in the dnssec system test · 6661db95
      Evan Hunt authored
      the occluded-key test creates both a KEY and a DNSKEY. the second
      call to dnssec-keygen calls dns_dnssec_findmatchingkeys(), which causes
      a spurious warning to be printed when it sees the type KEY record.
      this should be fixed in dnssec.c, but the meantime this change silences
      the warning by reversing the order in which the keys are created.
  14. 29 Jan, 2019 1 commit
  15. 25 Jan, 2019 3 commits
  16. 14 Jan, 2019 2 commits
    • Ondřej Surý's avatar
    • Evan Hunt's avatar
      fix testing errors · 82e83d5d
      Evan Hunt authored
      - the checkprivate function in the dnssec test set ret=0, erasing
        results from previous tests and making the test appear to have passed
        when it shouldn't have
      - checkprivate needed a delay loop to ensure there was time for all
        private signing records to be updated before the test
  17. 19 Dec, 2018 3 commits
  18. 14 Dec, 2018 1 commit
  19. 10 Dec, 2018 4 commits
  20. 03 Dec, 2018 1 commit
  21. 06 Nov, 2018 1 commit
    • Tony Finch's avatar
      Fixes for `rndc nta` user interface · 1b1d63ac
      Tony Finch authored
      Tell the user explicitly about their mistakes:
      * Unknown options, e.g. -list instead of -dump
        or -delete instead of -remove.
      * Unknown view names.
      * Excess arguments.
      Include the view name in `rndc nta -dump` output, for consistency with
      the NTA add and remove actions.
      When removing an NTA from all views, do not abort with an error if the
      NTA was not found in one of the views.
  22. 05 Oct, 2018 2 commits