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.
Use dns_dsdigest_t in library function arguments.
Improve dnssec-cds with these more specific types.
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;
remove remnants of deprecated -k option; remove mention of long-gone
TSIG support; refer to -T KEY in options that are only relevant to
pre-RFC3755 DNSSEC; remove unnecessary -n ZONE from the example, and
add a -f KSK example.
Witold Kręcicki [Fri, 15 Feb 2019 10:28:58 +0000 (11:28 +0100)]
Fix a race in socket code when internal_{accept, send, receive} is called
from event loop on an socket and, in the meantime, someone has closed this
socket.
Michał Kępień [Wed, 6 Mar 2019 07:31:07 +0000 (08:31 +0100)]
Log plugin unloading at debug level
During server reconfiguration, plugin instances set up for the old views
are unloaded very close to the end of the whole process, after new
plugin instances are set up. As the log message announcing plugin
unloading is emitted at the default "info" level, the user might be
misled into thinking that it is the new plugin instances that are being
unloaded for some reason, particularly because all other messages logged
at the "info" level around the same time inform about setting things up
rather than tearing them down. Since no distinction is currently made
between destroying a view due to reconfiguration and due to a shutdown
in progress, there is no easy way to vary the contents of the log
message depending on circumstances. Since this message is not a
particularly critical one, demote it to debug level to prevent
confusion.
Michał Kępień [Tue, 12 Feb 2019 14:59:54 +0000 (15:59 +0100)]
Add CHANGES entry
5161. [func] named plugins are now installed into a separate
directory. Supplying a filename (a string without path
separators) in a "plugin" configuration stanza now
causes named to look for that plugin in that directory.
[GL #878]
Michał Kępień [Tue, 12 Feb 2019 14:59:54 +0000 (15:59 +0100)]
Look for named plugins in ${libdir}/named
When the "library" part of a "plugin" configuration stanza does not
contain at least one path separator, treat it as a filename and assume
it is a name of a shared object present in the named plugin installation
directory. Absolute and relative paths can still be used and will be
used verbatim. Get the full path to a plugin before attempting to
check/register it so that all relevant log messages include the same
plugin path (apart from the one logged when the full path cannot be
determined).
Michał Kępień [Tue, 12 Feb 2019 14:59:54 +0000 (15:59 +0100)]
Add ns_plugin_expandpath()
Implement a helper function which, given an input string:
- copies it verbatim if it contains at least one path separator,
- prepends the named plugin installation directory to it otherwise.
This function will allow configuration parsing code to conveniently
determine the full path to a plugin module given either a path or a
filename.
While other, simpler ways exist for making sure filenames passed to
dlopen() cause the latter to look for shared objects in a specific
directory, they are very platform-specific. Using full paths is thus
likely the most portable and reliable solution.
Also added unit tests for ns_plugin_expandpath() to ensure it behaves
as expected for absolute paths, relative paths, and filenames, for
various target buffer sizes.
(Note: plugins share a directory with named on Windows; there is no
default plugin path. Therefore the source path is copied to the
destination path with no modification.)
Michał Kępień [Tue, 12 Feb 2019 14:59:54 +0000 (15:59 +0100)]
Install named plugins into a separate directory
Installing named plugins into ${libdir} clutters the latter and is not
in line with common filesystem conventions. Instead, install named
plugins into a separate directory, ${libdir}/named.
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.
Matthijs Mekking [Wed, 27 Feb 2019 15:24:03 +0000 (16:24 +0100)]
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.
Matthijs Mekking [Wed, 27 Feb 2019 14:21:04 +0000 (15:21 +0100)]
Only perform test cleanups in clean.sh scripts
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.
Evan Hunt [Mon, 25 Feb 2019 20:55:27 +0000 (12:55 -0800)]
fix crash in query_respond_any() from all records being hidden
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.
Michał Kępień [Thu, 28 Feb 2019 12:15:13 +0000 (13:15 +0100)]
Do not include conf.sh from ttl/clean.sh
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.
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.
Matthijs Mekking [Mon, 11 Feb 2019 16:25:34 +0000 (17:25 +0100)]
Unregister RPZ CATZ db cbs when zone load fails
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.
projects / thirdparty / bind9.git / log
