1. 19 Mar, 2019 2 commits
  2. 15 Mar, 2019 1 commit
  3. 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.
  4. 28 Feb, 2019 1 commit
  5. 21 Feb, 2019 2 commits
  6. 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.
  7. 29 Jan, 2019 1 commit
  8. 25 Jan, 2019 3 commits
  9. 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
  10. 19 Dec, 2018 3 commits
  11. 14 Dec, 2018 1 commit
  12. 10 Dec, 2018 4 commits
  13. 03 Dec, 2018 1 commit
  14. 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.
  15. 05 Oct, 2018 3 commits
  16. 14 Aug, 2018 1 commit
  17. 19 Jul, 2018 1 commit
  18. 27 Jun, 2018 2 commits
  19. 13 Jun, 2018 1 commit
  20. 08 Jun, 2018 1 commit
  21. 31 May, 2018 1 commit
    • Evan Hunt's avatar
      update system tests so validation won't fail when using IANA key · a7a2fa29
      Evan Hunt authored
      - all tests with "recursion yes" now also specify "dnssec-validation yes",
        and all tests with "recursion no" also specify "dnssec-validation no".
        this must be maintained in all new tests, or else validation will fail
        when we use local root zones for testing.
      - clean.sh has been modified where necessary to remove managed-keys.bind
        and viewname.mkeys files.
  22. 16 May, 2018 2 commits