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. 15 Nov, 2019 3 commits
    • Evan Hunt's avatar
      use DS style trust anchors in all system tests · 54a682ea
      Evan Hunt authored
      this adds functions in conf.sh.common to create DS-style trust anchor
      files. those functions are then used to create nearly all of the trust
      anchors in the system tests.
      there are a few exceptions:
       - some tests in dnssec and mkeys rely on detection of unsupported
         algorithms, which only works with key-style trust anchors, so those
         are used for those tests in particular.
       - the mirror test had a problem with the use of a CSK without a
         SEP bit, which still needs addressing
      in the future, some of these tests should be changed back to using
      traditional trust anchors, so that both types will be exercised going
    • Evan Hunt's avatar
      refactor create_keydata · 4d3ed3f4
      Evan Hunt authored
      use empty placeholder KEYDATA records for all trust anchors, not just
      DS-style trust anchors.
      this revealed a pre-existing bug: keyfetch_done() skips keys without
      the SEP bit when populating the managed-keys zone. consequently, if a
      zone only has a single ZSK which is configured as trust anchor and no
      KSKs, then no KEYDATA record is ever written to the managed-keys zone
      when keys are refreshed.
      that was how the root server in the dnssec system test was configured.
      however, previously, the KEYDATA was created when the key was
      initialized; this prevented us from noticing the bug until now.
      configuring a ZSK as an RFC 5011 trust anchor is not forbidden by the
      spec, but it is highly unusual and not well defined.  so for the time
      being, I have modified the system test to generate both a KSK and ZSK
      for the root zone, enabling the test to pass.
      we should consider adding code to detect this condition and allow keys
      without the SEP bit to be used as trust anchors if no key with the SEP
      bit is available, or at minimum, log a warning.
    • Evan Hunt's avatar
  7. 07 Nov, 2019 1 commit
    • Evan Hunt's avatar
      convert ns_client and related objects to use netmgr · 53f0b6c3
      Evan Hunt authored
      - ns__client_request() is now called by netmgr with an isc_nmhandle_t
        parameter. The handle can then be permanently associated with an
        ns_client object.
      - The task manager is paused so that isc_task events that may be
        triggred during client processing will not fire until after the netmgr is
        finished with it. Before any asynchronous event, the client MUST
        call isc_nmhandle_ref(client->handle), to prevent the client from
        being reset and reused while waiting for an event to process. When
        the asynchronous event is complete, isc_nmhandle_unref(client->handle)
        must be called to ensure the handle can be reused later.
      - reference counting of client objects is now handled in the nmhandle
        object.  when the handle references drop to zero, the client's "reset"
        callback is used to free temporary resources and reiniialize it,
        whereupon the handle (and associated client) is placed in the
        "inactive handles" queue.  when the sysstem is shutdown and the
        handles are cleaned up, the client's "put" callback is called to free
        all remaining resources.
      - because client allocation is no longer handled in the same way,
        the '-T clienttest' option has now been removed and is no longer
        used by any system tests.
      - the unit tests require wrapping the isc_nmhandle_unref() function;
        when LD_WRAP is supported, that is used. otherwise we link a
        libwrap.so interposer library and use that.
  8. 06 Nov, 2019 1 commit
  9. 28 Aug, 2019 1 commit
  10. 09 Aug, 2019 1 commit
  11. 08 Aug, 2019 1 commit
  12. 02 Aug, 2019 1 commit
  13. 31 Jul, 2019 1 commit
  14. 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.
  15. 05 Jun, 2019 2 commits
    • Evan Hunt's avatar
      rename keyfile_to_*_keys system test shell functions · 0ef5b8ed
      Evan Hunt authored
      - keyfile_to_trusted_keys -> keyfile_to_static_keys
      - keyfile_to_managed_keys -> keyfile_to_initial_keys
    • 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
  16. 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.
  17. 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
  18. 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.
  19. 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).
  20. 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.
  21. 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.
  22. 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
  23. 19 Mar, 2019 3 commits
  24. 15 Mar, 2019 1 commit
  25. 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.
  26. 28 Feb, 2019 1 commit
  27. 21 Feb, 2019 2 commits
  28. 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.