RPZ NSIP and NSDNAME checks were failing with "unrecognized NS
rpz_rrset_find() failed: glue" when static or static-stub zones
where used to resolve the query name.
Add tests using stub and static-stub zones that are expected to
be filtered and not-filtered against NSIP and NSDNAME rules.
stub and static-stub queries are expected to be filtered
stub-nomatch and static-stub-nomatch queries are expected to be passed
(cherry picked from commit 30cb70c826)
The named_config_getdefault() was missing void in the function
definition. This broke clang-15 that didn't match the declaration that
had the void in the argument with the definition that hadn't.
The dig commands appear to be failing unexpectedly on some platforms
when rate limiting kicks in and the response is dropped. Correct
behaviour should be for dig to retry the query. Set +qr and capture
stdout and stderr of each of the dig commands involved.
(cherry picked from commit 614cf5a030)
In '_check_apex_dnskey' we check for each key (KEY1 to KEY4) if they
are present in the DNSKEY RRset if they should be.
However, we only grep the dig output for the first seven fields (owner,
ttl, class, type, flags, protocol, algorithm). This can be the same
for different keys.
For example, KEY1 may be KSK predecessor and KEY2 a KSK successor,
both DNSKEY records for these keys are the same up to the public key
field. This can cause test failures if KEY1 needs to be present, but
KEY2 not, because when grepping for KEY2 we will falsely detect the
key to be present (because the grep matches KEY1).
Fix the function by grepping looking for the first seven fields in the
corresponding key file and retrieve the public key part. Grep for this
in the dig output.
(cherry picked from commit 3e1d09ac66)
It might be useful to display built-in configuration with all its
values. It should make it easier to test what default values has changed
in a new release.
Related: #1326
(cherry picked from commit cf722d18b3)
The `send_done()` callback needs to access query's `link.next` pointer
when running in `+nssearch` mode, even if the query is already canceled
or serviced, which can happen when `recv_done()` happens to be called
earlier than `send_done()`.
Keep the next query's pointer before unlinking the query from the
lookup's queries list in `clear_query()` so that `send_done()` can
use it even if the query is cleared.
Printing the pointers makes it clear, for example, for which query
exactly a recv_done() or send_done() callback was called, which
helps investigating and debugging issues easier.
dzl_ldap_driver.c was missing some FALLTHROUGH macros in a switch
statement resulting in compiler warnings and a failed build when
configured with `--with-dlz-ldap` option.
inet_ntop result should always protect against empty string accepted
without an error. Make additional check to satisfy coverity scans.
(cherry picked from commit 656a0f076f)
- var_decl: Declaring variable "tbuf" without initializer
- assign: Assigning: "target.base" = "tbuf", which points to
uninitialized data
- assign: Assigning: "r.base" = "target.base", which points to
uninitialized data
I expect it would correctly initialize length always. Add simple
initialization to silent coverity.
(cherry picked from commit 59132bd3ec)
Coverity detected issues:
- var_decl: Declaring variable "diff" without initializer.
- uninit_use_in_call: Using uninitialized value "diff.tuples.head" when
calling "dns_diff_clear".
(cherry picked from commit 67e773c93c)
Parser ensures new-zones-directory has qstring parameter before it can
reach this place. dir == NULL then should never happen on any
configuration. Replace silent check with insist.
(cherry picked from commit 0a7d04367a)
FALLTHOUGH is a copy of how it is defined in <isc/util.h>
UNREACHABLE follows the model used in MacOS /usr/include/c++/v1/cstdlib
to determine if __builtin_ureachable is available
(cherry picked from commit 6d68a22954)
It was discovered that MariaDB 10 didn't define LIBMARIADB leading
to compilation errors of MySQL DLZ modules on Debian stretch.
Use MARIADB_BASE_VERSION instead which is defined in all tested MariaDB
versions.
It was discovered that MariaDB 10 didn't define LIBMARIADB leading
to compilation errors of MySQL DLZ modules on Debian stretch.
Use MARIADB_BASE_VERSION instead which is defined in all tested MariaDB
versions.
(cherry picked from commit 5835aae694)
Recent python does not make parsetab.py successfully, because some token
regexp is starting with ?i flag. Remove that flag from regex and pass it
as extra flags parameter instead.
This seems to be most appropriate way to ensure consistency between
release tarballs and public presentation on ReadTheDocs.
Previous attempt with removing docutils constraint, which relied on pip
depedency solver to pick the same packages as in CI was flawed. RTD
installs a bit different set of packages so it was inherently
unreliable.
As a result RTD pulled in sphinx-rtd-theme==0.4.3 while CI
had 1.0.0, and this inconsistency caused Table of Contents in Release
Notes to render incorrectly. Previous solution was to downgrade
docutils to < 0.17, but I think we should rather pin exact versions.
For the long history of messing with versions read also
isc-projects/bind9@2a8eda0084isc-projects/images@d4435b97beisc-projects/bind9@6a2daddf5b
(cherry picked from commit 6088ba3837)
Currently our CI images we use to build docs (which subsequently get
into release tarballs) are using docutils 0.17.1, which is latest version
which fulfills Sphinx 4.5.0 requirement for docutils < 0.18.
The old requirement for docutils < 0.17 was causing discrepancy between
the way we build release artifacts and the docs on ReadTheDocs.org which
uses doc/arm/requirements.txt from our repo.
Remove the limit for RDT with hope that it will pull latest permissible
version of docutils.
For the long history of messing with docutils version read also
isc-projects/images@d4435b97beisc-projects/bind9@6a2daddf5b
(cherry picked from commit 2a8eda0084)
When we compile with libuv that has some capabilities via flags passed
to f.e. uv_udp_listen() or uv_udp_bind(), the call with such flags would
fail with invalid arguments when older libuv version is linked at the
runtime that doesn't understand the flag that was available at the
compile time.
Enforce minimal libuv version when flags have been available at the
compile time, but are not available at the runtime. This check is less
strict than enforcing the runtime libuv version to be same or higher
than compile time libuv version.
Older versions do not have "override" parameter in add_role_to_domain()
function signature. Luckily the override is _not_ required when
overidding the built-in standard domain roles for the first time, so we
just drop the paramter.
Tested with Sphinx 1.6.7 (does not have override) and Sphinx 4.5.0
(does have override).
Fixes: #3294
Related: !6086
According to PEP 632 [1], the distutils module is considered deprecated
in Python 3.10 and will be removed in Python 3.12. Setup scripts
using it should be migrated to the setuptools module, which contains
drop-in replacements for distutils functions [2]. The catch is that the
setuptools module is not part of the Python Standard Library.
While this problem could be addressed by adding a hard dependency on
setuptools, it only affects BIND 9.16, which is an Extended Support
Version. To avoid unnecessary disruptions, try importing setup() from
the setuptools module and fall back to using distutils if that fails.
Add a PyLint suppression for this specific "deprecated-module" warning.
Since the setuptools module is not part of the Python Standard Library
and therefore it is not guaranteed that it is universally available in
every Python installation, update Python-related checks in configure.ac
to ensure Python module installation does not silently fail.
[1] https://peps.python.org/pep-0632/
[2] https://setuptools.pypa.io/en/latest/deprecated/distutils-legacy.html
Since version 5.0.0, decay-based purging is the only available dirty
page cleanup mechanism in jemalloc. It relies on so-called tickers,
which are simple data structures used for ensuring that certain actions
are taken "once every N times". Ticker data (state) is stored in a
thread-specific data structure called tsd in jemalloc parlance. Ticks
are triggered when extents are allocated and deallocated. Once every
1000 ticks, jemalloc attempts to release some of the dirty pages hanging
around (if any). This allows memory use to be kept in check over time.
This dirty page cleanup mechanism has a quirk. If the first
allocator-related action for a given thread is a free(), a
minimally-initialized tsd is set up which does not include ticker data.
When that thread subsequently calls *alloc(), the tsd transitions to its
nominal state, but due to a certain flag being set during minimal tsd
initialization, ticker data remains unallocated. This prevents
decay-based dirty page purging from working, effectively enabling memory
exhaustion over time. [1]
The quirk described above has been addressed (by moving ticker state to
a different structure) in jemalloc's development branch [2], but not in
any numbered jemalloc version released to date (the latest one being
5.2.1 as of this writing).
Work around the problem by ensuring that every thread spawned by
isc_thread_create() starts with a malloc() call. Avoid immediately
calling free() for the dummy allocation to prevent an optimizing
compiler from stripping away the malloc() + free() pair altogether.
An alternative implementation of this workaround was considered that
used a pair of isc_mem_create() + isc_mem_destroy() calls instead of
malloc() + free(), enabling the change to be fully contained within
isc__trampoline_run() (i.e. to not touch struct isc__trampoline), as the
compiler is not allowed to strip away arbitrary function calls.
However, that solution was eventually dismissed as it triggered
ThreadSanitizer reports when tools like dig, nsupdate, or rndc exited
abruptly without waiting for all worker threads to finish their work.
[1] https://github.com/jemalloc/jemalloc/issues/2251
[2] c259323ab3
(cherry picked from commit 7aa7b6474b)
