1. 15 Mar, 2019 4 commits
  2. 14 Mar, 2019 12 commits
  3. 13 Mar, 2019 2 commits
  4. 12 Mar, 2019 10 commits
  5. 11 Mar, 2019 12 commits
    • Evan Hunt's avatar
      Merge branch '892-fix-redirect-name-v9_14' into 'v9_14' · 4e0e40de
      Evan Hunt authored
      use qname in redirect2
      See merge request !1663
    • Mark Andrews's avatar
      add CHANGES · 7dcee146
      Mark Andrews authored
      (cherry picked from commit ad785e4f)
    • Mark Andrews's avatar
      use client->query.qname · d974a288
      Mark Andrews authored
      (cherry picked from commit 8758d36a)
    • Evan Hunt's avatar
      Merge branch 'each-fix-changes' into 'v9_14' · 85f6e007
      Evan Hunt authored
      remove accidentally-included CHANGES notes
      See merge request !1661
    • Evan Hunt's avatar
      remove accidentally-included CHANGES notes · 0faa56cb
      Evan Hunt authored
    • Michał Kępień's avatar
      Merge branch '928-stabilize-delzsk.example-zone-checks-v9_14' into 'v9_14' · 802a9652
      Michał Kępień authored
      [v9_14] Stabilize "delzsk.example" zone checks
      See merge request !1658
    • Michał Kępień's avatar
      Stabilize "delzsk.example" zone checks · 79a4cbd2
      Michał Kępień authored
      When a zone is converted from NSEC to NSEC3, the private record at zone
      apex indicating that NSEC3 chain creation is in progress may be removed
      during a different (later) zone_nsec3chain() call than the one which
      adds the NSEC3PARAM record.  The "delzsk.example" zone check only waits
      for the NSEC3PARAM record to start appearing in dig output while private
      records at zone apex directly affect "rndc signing -list" output.  This
      may trigger false positives for the "autosign" system test as the output
      of the "rndc signing -list" command used for checking ZSK deletion
      progress may contain extra lines which are not accounted for.  Ensure
      the private record is removed from zone apex before triggering ZSK
      deletion in the aforementioned check.
      Also future-proof the ZSK deletion progress check by making it only look
      at lines it should care about.
      (cherry picked from commit e02de04e)
    • Michał Kępień's avatar
      Merge branch '129-dnssec-system-test-tweaks-v9_14' into 'v9_14' · 83acb4ff
      Michał Kępień authored
      [v9_14] "dnssec" system test tweaks
      See merge request !1656
    • Mark Andrews's avatar
      ${ttl} must exist and be non null · 8f2f5d98
      Mark Andrews authored
      (cherry picked from commit dee1f1a4)
    • Michał Kępień's avatar
      Make ANSWER TTL capping checks stricter · f301744f
      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.
      (cherry picked from commit a85cc414)
    • Michał Kępień's avatar
      Relax ADDITIONAL TTL capping checks · f28953b6
      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
      (cherry picked from commit 8baf8590)
    • Michał Kępień's avatar
      Fix message section checked in a TTL capping test · 8f1c3e5d
      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.
      (cherry picked from commit a597bd52)