GitLab

More specifically: ignore configured trusted and managed keys that
match a disabled algorithm.  The behavioral change is that
associated responses no longer SERVFAIL, but return insecure.

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.

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
process.

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
checks.

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.

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.

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.

this prevents servers that use arguments specified in named.args
from appearing different in 'ps' output from servers run with arguments
from start.pl

- work around CR issues
- use UTC for time comparisons
- use $DIFF instead of cmp

- 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

dnssec-signzone should sign a zonefile that contains a DNSKEY record
with an unsupported algorithm.

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.

Reduce code duplication by replacing a code snippet repeated throughout
system tests using "trusted-keys" and/or "managed-keys" configuration
sections with calls to keyfile_to_{managed,trusted}_keys() helper
functions.

- incidentally fixed a bug in the dnssec system test where TTLs in the
  answer section rather than the additional section were being checked

- 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.