Michał Kępień [Tue, 19 Mar 2019 09:26:36 +0000 (10:26 +0100)]
Correctly invoke stop.pl when start.pl fails
MR !1141 broke the way stop.pl is invoked when start.pl fails:
- start.pl changes the working directory to $testdir/$server before
attempting to start $server,
- commit 27ee629e6b583f60fea0ab78fb3ebd0d1d71d9d2 causes the $testdir
variable in stop.pl to be determined using the $SYSTEMTESTTOP
environment variable, which is set to ".." by all tests.sh scripts,
- commit e227815af51c0656e22e5aebfe99e2399106b31c makes start.pl pass
$test (the test's name) rather than $testdir (the path to the test's
directory) to stop.pl when a given server fails to start.
Thus, when a server is restarted from within a tests.sh script and such
a restart fails, stop.pl attempts to look for the server directory in a
nonexistent location ($testdir/$server/../$test, i.e. $testdir/$test,
instead of $testdir/../$test). Fix the issue by changing the working
directory before stop.pl is invoked in the scenario described above.
Petr Menšík [Thu, 14 Mar 2019 12:40:14 +0000 (13:40 +0100)]
Fix regression in dnstap_test with native pkcs11
Change to cmocka broken initialization of TZ environment. This time,
commit 1cf12540515e4a3fc93ace02b81815209f1e709e is not soon enough. Has
to be moved more forward, before any other tests. It library is not full
reinitialized on each test.
Witold Kręcicki [Wed, 13 Feb 2019 10:10:31 +0000 (11:10 +0100)]
Fix a race in fctx_cancelquery.
When sending an udp query (resquery_send) we first issue an asynchronous
isc_socket_connect and increment query->connects, then isc_socket_sendto2
and increment query->sends.
If we happen to cancel this query (fctx_cancelquery) we need to cancel
all operations we might have issued on this socket. If we are under very high
load the callback from isc_socket_connect (resquery_udpconnected) might have
not yet been fired. In this case we only cancel the CONNECT event on socket,
and ignore the SEND that's waiting there (as there is an `else if`).
Then we call dns_dispatch_removeresponse which kills the dispatcher socket
and calls isc_socket_close - but if system is under very high load, the send
we issued earlier might still not be complete - which triggers an assertion
because we're trying to close a socket that's still in use.
The fix is to always check if we have incomplete sends on the socket and cancel
them if we do.
Michał Kępień [Tue, 12 Mar 2019 07:42:48 +0000 (08:42 +0100)]
Silence a Perl warning output by stop.pl
On Unix systems, the CYGWIN environment variable is not set at all when
BIND system tests are run. If a named instance crashes on shutdown or
otherwise fails to clean up its pidfile and the CYGWIN environment
variable is not set, stop.pl will print an uninitialized value warning
on standard error. Prevent this by using defined().
Petr Menšík [Mon, 25 Feb 2019 09:58:14 +0000 (10:58 +0100)]
Allow ifconfig to be called from any directory
ifconfig.sh depends on config.guess for platform guessing. It uses it to
choose between ifconfig or ip tools to configure interfaces. If
system-wide automake script is installed and local was not found, use
platform guess. It should work well on mostly any sane platform. Still
prefers local guess, but passes when if cannot find it.
Michał Kępień [Mon, 11 Mar 2019 12:30:40 +0000 (13:30 +0100)]
Stabilize the "gost" system test
In the "gost" system test, the ./NS RRset returned in the response to
ns2's priming query might not yet be validated when ns2 assembles the
response to the ./SOA query. If that happens, the ./NS RRset will not
be placed in the AUTHORITY section of the response to the ./SOA query,
triggering a false positive for the "gost" system test as the ./NS RRset
is always present in the response sent by ns1 (since it is authoritative
for the root zone). As the purpose of the "gost" system test is to
check whether a zone signed using GOST is properly validated and only
positive responses are inspected, use the +noauth dig option for all
queries in that test, so that the contents of the AUTHORITY section do
not influence its outcome.
Michał Kępień [Mon, 11 Mar 2019 12:02:54 +0000 (13:02 +0100)]
Stabilize "delzsk.example" zone checks
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.
Michał Kępień [Mon, 11 Mar 2019 11:04:42 +0000 (12:04 +0100)]
Make ANSWER TTL capping checks stricter
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ń [Mon, 11 Mar 2019 11:04:42 +0000 (12:04 +0100)]
Relax ADDITIONAL TTL capping checks
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.
Michał Kępień [Mon, 11 Mar 2019 11:04:42 +0000 (12:04 +0100)]
Fix NTA-related races
Changes introduced by commit 6b8e4d6e695fc13b2d2a93437418a047b5adce81
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.
Michał Kępień [Fri, 8 Mar 2019 12:47:13 +0000 (13:47 +0100)]
Fix regex used for mangling druz/DNSKEY
During "dlv" system test setup, the "sed" regex used for mangling the
DNSKEY RRset for the "druz" zone does not include the plus sign ("+"),
which may:
- cause the replacement to happen near the end of DNSKEY RDATA, which
can cause the latter to become an invalid Base64 string,
- prevent the replacement from being performed altogether.
Both cases prevent the "dlv" system test from behaving as intended and
may trigger false positives. Add the missing character to the
aforementioned regex to ensure the replacement is always performed on
bytes 10-25 of DNSKEY RDATA.
Tony Finch [Fri, 8 Feb 2019 17:54:56 +0000 (17:54 +0000)]
cleanup: use dns_secalg_t and dns_dsdigest_t where appropriate
Use them in structs for various rdata types where they are missing.
This doesn't change the structs since we are replacing explicit
uint8_t field types with aliases for uint8_t.
Tony Finch [Thu, 21 Feb 2019 18:54:16 +0000 (18:54 +0000)]
cleanup dnssec-keygen manual page
Alphabetize options and synopsis; remove spurious -z from synopsis;
refer to -T KEY in options that are only relevant to pre-RFC3755
DNSSEC, and add a -f KSK example.
Michał Kępień [Fri, 1 Mar 2019 06:57:45 +0000 (07:57 +0100)]
Disable SERVFAIL cache for ns5 in the "mkeys" system test
The "check key refreshes are resumed after root servers become
available" check may trigger a false positive for the "mkeys" system
test if the second example/TXT query sent by dig is received by ns5 less
than a second after it receives a REFUSED response to the upstream query
it sends to ns1 in order to resolve the first example/TXT query sent by
dig. Since that REFUSED response from ns1 causes ns5 to return a
SERVFAIL answer to dig, example/TXT is added to the SERVFAIL cache,
which is enabled by default with a TTL of 1 second. This in turn may
cause ns5 to return a cached SERVFAIL response to the second example/TXT
query sent by dig, i.e. make ns5 not perform full query processing as
expected by the check.
Since the primary purpose of the check in question is to ensure that key
refreshes are resumed once initially unavailable root servers become
available, the optimal solution appears to be disabling SERVFAIL cache
for ns5 as doing that still allows the check to fulfill its purpose and
it is arguably more prudent than always sleeping for 1 second.
Ensure all system tests run clean.sh from setup.sh
For consistency between all system tests, add missing setup.sh scripts
for tests which do not have one yet and ensure every setup.sh script
calls its respective clean.sh script.
Temporary files created by a given system test should be removed by its
clean.sh script, not its setup.sh script. Remove redundant "rm"
invocations from setup.sh scripts. Move required "rm" invocations from
setup.sh scripts to their corresponding clean.sh scripts.
Michał Kępień [Tue, 26 Feb 2019 11:33:19 +0000 (12:33 +0100)]
Fix IP regex used in the "resolver" system test
If dots are not escaped in the "1.2.3.4" regular expressions used for
checking whether IP address 1.2.3.4 is present in the tested resolver's
answers, a COOKIE that matches such a regular expression will trigger a
false positive for the "resolver" system test. Properly escape dots in
the aforementioned regular expressions to prevent that from happening.
Michał Kępień [Thu, 28 Feb 2019 11:33:07 +0000 (12:33 +0100)]
Call clean.sh from all relevant setup.sh scripts
For all system tests utilizing named instances, call clean.sh from each
test's setup.sh script in a consistent way to make sure running the same
system test multiple times using run.sh does not trigger false positives
caused by stale files created by previous runs.
Ideally we would just call clean.sh from run.sh, but that would break
some quirky system tests like "rpz" or "rpzrecurse" and being consistent
for the time being does not hurt.
projects / thirdparty / bind9.git / log
