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.
(cherry picked from commit 1954f8d2bf)
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.
(cherry picked from commit af4b81f944)
Make nsupdate honor the operating system's preferred ephemeral port
range instead of always using the default 1024-65535 range for outgoing
messages.
(cherry picked from commit 06f582f23e)
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]
(cherry picked from commit d2c960cfc2)
Add the -c command line option to the usage message for named-checkconf
as it is not present there despite being documented.
(cherry picked from commit cba155154b)
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).
(cherry picked from commit 1a9fc624ca)
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.)
(cherry picked from commit d181c28c60)
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.
(cherry picked from commit c527b7fd5c)
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.
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.
(cherry picked from commit 70ae48e5cb)
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.
(cherry picked from commit 3e74c7e5ff)
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.
(cherry picked from commit 6602848460)
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.
(cherry picked from commit a077a3ae8a)
