1. 16 Jan, 2020 1 commit
  2. 15 Jan, 2020 1 commit
  3. 14 Jan, 2020 1 commit
  4. 13 Jan, 2020 1 commit
    • Tony Finch's avatar
      Fix line spacing in `rndc secroots` · 5b600c2c
      Tony Finch authored
      Before this change, there was a missing blank line between the
      negative trust anchors for one view, and the heading line for the next
      view. This is because dns_ntatable_totext() omits the last newline.
      There is an example of the incorrect output below; the fixed output
      has a blank line before "Start view auth".
      secure roots as of 21-Oct-2019 12:03:23.500:
       Start view rec
         Secure roots:
      ./RSASHA256/20326 ; managed
         Negative trust anchors:
      example.com: expiry 21-Oct-2019 13:03:15.000
       Start view auth
         Secure roots:
      ./RSASHA256/20326 ; managed
         Negative trust anchors:
      example.com: expiry 21-Oct-2019 13:03:07.000
  5. 09 Dec, 2019 1 commit
  6. 06 Nov, 2019 1 commit
  7. 28 Aug, 2019 1 commit
  8. 09 Aug, 2019 1 commit
  9. 08 Aug, 2019 1 commit
  10. 02 Aug, 2019 1 commit
  11. 31 Jul, 2019 1 commit
  12. 28 Jun, 2019 1 commit
    • Michał Kępień's avatar
      Add and use keyfile_to_key_id() helper function · 7d6eaad1
      Michał Kępień authored
      When trying to extract the key ID from a key file name, some test code
      incorrectly attempts to strip all leading zeros.  This breaks tests when
      keys with ID 0 are generated.  Add a new helper shell function,
      keyfile_to_key_id(), which properly handles keys with ID 0 and use it in
      test code whenever a key ID needs to be extracted from a key file name.
  13. 05 Jun, 2019 1 commit
    • Evan Hunt's avatar
      deprecate "trusted-keys" · 5ab25218
      Evan Hunt authored
      - trusted-keys is now flagged as deprecated, but still works
      - managed-keys can be used to configure permanent trust anchors by
        using the "static-key" keyword in place of "initial-key"
      - parser now uses an enum for static-key and initial-key keywords
  14. 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.
  15. 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
  16. 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).
  17. 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.
  18. 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.
  19. 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
  20. 19 Mar, 2019 3 commits
  21. 15 Mar, 2019 1 commit
  22. 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.
  23. 28 Feb, 2019 1 commit
  24. 21 Feb, 2019 2 commits
  25. 25 Jan, 2019 3 commits
  26. 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
  27. 19 Dec, 2018 2 commits