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.
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.
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.
in query_respond_any(), the assumption had previously been made that it
was impossible to get past iterating the node with a return value of
ISC_R_NOMORE but not have found any records, unless we were searching
for RRSIG or SIG. however, it is possible for other types to exist but
be hidden, such as when the zone is transitioning from insecure to
secure and DNSSEC types are encountered, and this situation could
trigger an assertion. removed the assertion and reorganized the code.
Including $SYSTEMTESTTOP/conf.sh from a system test's clean.sh script is
not needed for anything while it causes an error message to be printed
out when "./configure" is run, as "make clean" is invoked at the end.
Remove the offending line to prevent the error from occurring.
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.
In case when a zone fails to load because the file does not exist
or is malformed, we should not run the callback that updates the
zone database when the load is done. This is achieved by
unregistering the callbacks if at zone load end if the result
indicates something else than success.
As pointed out in !813 db_registered is sort of redundant. It is
set to `true` only in `dns_zone_rpz_enable_db()` right before the
`dns_rpz_dbupdate_callback()` callback is registered. It is only
required in that callback and it is the only place that the callback
is registered. Therefore there is no path that that `REQUIRE` can
fail.
The `db_registered` variable is only set to `false` in
`dns_rpz_new_zone`, so it is not like the variable is unset again
later.
The only other place where `db_registered` is checked is in
`rpz_detach()`. If `true`, it will call
`dns_db_updatenotify_unregister()`. However if that happens, the
`db_registered` is not set back to `false` thus this implies that
this may happen multiple times. If called a second time, most
likely the unregister function will return `ISC_R_NOTFOUND`, but
the return value is not checked anyway. So it can do without the
`db_registered` check.
This may happen when loading an RPZ failed and the code path skips
calling dns_db_endload(). The dns_rpz_zone_t object is still kept
marked as having registered db. So when this object is finally
destroyed in rpz_detach(), this code will incorrectly call
`dns_db_updatenotify_unregister()`:
if (rpz->db_registered)
dns_db_updatenotify_unregister(rpz->db,
dns_rpz_dbupdate_callback, rpz);
and trigger this assertion failure:
REQUIRE(db != NULL);
To fix this, only call `dns_db_updatenotify_unregister()` when
`rpz->db` is not NULL.
