this moves the creation of "parallel.mk" into a separate shell script
instead of bin/tests/system/Makefile. that shell script can now be
executed by runall.sh, allowing us to make use of the cygwin "make"
command, which supports parallel execution.
(cherry picked from commit bbae24c140)
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.
(cherry picked from commit da2c1b74ad)
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.
(cherry picked from commit 83473b9758)
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).
(cherry picked from commit 67f0635f3c)
One second may not be enough for an NSEC3 chain change triggered by an
UPDATE message to complete. Wait up to 10 seconds when checking whether
a given NSEC3 chain change is complete in the "nsupdate" system test.
(cherry picked from commit f8746cddbc)
In the "nsupdate" system test, do not sleep before checking results of
changes which are expected to be processed synchronously, i.e. before
nsupdate returns.
(cherry picked from commit 1c8e5ea333)
Make bin/tests/system/ifconfig.bat also configure addresses ending with
9 and 10, so that the script is in sync with its Unix counterpart.
Update comments listing the interfaces created by ifconfig.{bat,sh} so
that they do not include addresses whose last octet is zero (since an
address like 10.53.1.0/24 is not a valid host address and thus the
aforementioned scripts do not even attempt configuring them).
(cherry picked from commit b6c1cdfffe)
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.
(cherry picked from commit e4280ed9f5)
As signals are currently not handled by named on Windows, instances
terminated using signals are not able to perform a clean shutdown, which
involves e.g. removing the lock file. Thus, waiting for a given
instance's lock file to be removed beforing assuming it is shut down
is pointless on Windows, so do not even attempt it.
(cherry picked from commit 761ba4514f)
This tests both the cases when the DLV trust anchor is of an
unsupported or disabled algorithm, as well as if the DLV zone
contains a key with an unsupported or disabled algorithm.
(cherry picked from commit 3b7c849a3f)
The following changes were needed:
* Remove dnskey-sig-validity option (added in 9.12)
* Replace rndccmd, dig_with_opts with export variables
* Remove tests for CDNSKEY and CDS (in 9.11 always signed with ZSK)
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.
(cherry-picked from commit c48b85d0a3c34480179d44e736e3e535dbae1001)
Some system tests assume dig's default setings are in effect. While
these defaults may only be silently overridden (because of specific
options set in /etc/resolv.conf) for BIND releases using liblwres for
parsing /etc/resolv.conf (i.e. BIND 9.11 and older), it is arguably
prudent to make sure that tests relying on specific +timeout and +tries
settings specify these explicitly in their dig invocations, in order to
prevent test failures from being triggered by any potential changes to
current defaults.
(cherry picked from commit b6cce0fb8b)
If the path to the source of random data is not passed explicitly to
dnssec-keygen or dnssec-signzone and the --with-randomdev compile-time
switch is not used, the aforementioned utilities will hang if the
default source of random data (/dev/random) runs out of entropy. Use
"-r $RANDFILE" to prevent that from happening in affected system tests.
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
fields.
(cherry picked from commit a40c60e4c1)
bin/tests/system/stop.pl only waits for the PID file to be cleaned up
while named cleans up the lock file after the PID file. Thus, the
aforementioned script may consider a named instance to be fully shut
down when in fact it is not.
Fix by also checking whether the lock file exists when determining a
given instance's shutdown status. This change assumes that if a named
instance uses a lock file, it is called "named.lock", and that if an
lwresd instance uses a lock file, it is called "lwresd.lock".
Also rename clean_pid_file() to pid_file_exists(), so that it is called
more appropriately (it does not clean up the PID file itself, it only
returns the server's identifier if its PID file is not yet cleaned up).
(cherry picked from commit c787a539d2)
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 27ee629e6b 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 e227815af5 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.
(cherry picked from commit 4afad2a047)
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().
(cherry picked from commit 91e5a99b9b)
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.
(cherry picked from commit 38301052e1)
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.
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 e02de04e97)
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 a85cc41486)
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.
(cherry picked from commit 8baf859063)
Changes introduced by commit 6b8e4d6e69
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.
(cherry picked from commit 9a36a1bba3)
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.
(cherry picked from commit fd13fef299)
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.
(cherry picked from commit 7c6bff3c4e)
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.
(cherry picked from commit e410803919)
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.
(cherry picked from commit c64ed484c8)
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.
(cherry picked from commit 70ae48e5cb)
Evan Hunt
Mark Andrews
Michał Kępień
Matthijs Mekking
Petr MenšíkandMark Andrews
Curtis BlackburnandEvan Hunt