In the generated man pages, `@RELEASEDATE@` wasn't replaced since the
actual variable name is `RELEASE_DATE` with an underscore. This issue
was introduced in the recently merged !7518 (commit
18b7ba3ea3) which removed the pregenerated
man pages from the repo.
The Known Issues section for 9.16.38 release notes was accidentally
removed during branch maintenance after release. Restore the contents to
its tagged released version.
Named now logs both compile time and run time UV versions when
starting up. This is useful information to have when debugging
network issues involving named.
(cherry picked from commit 5fd2cd8018)
Remove the part which is no longer true after reverting the commit
in question.
The CHANGES entry was never part of a released BIND 9 version.
(cherry picked from commit e1627e1289)
This reverts commit 1254f37584.
The commit introduced a data race, because dns_db_endload() is called
after unfreezing the zone.
(not cherry picked from commit 593dea871a)
During reconfiguration, the configure_view() function reverts the
configured zones to the previous view in case if there is an error.
It uses the 'zones_configured' boolean variable to decide whether
it is required to revert the zones, i.e. the error happened after
all the zones were successfully configured.
The problem is that it does not account for the case when an error
happens during the configuration of one of the zones (not the first),
in which case there are zones that are already configured for the
new view (and they need to be reverted), and there are zones that
are not (starting from the failed one).
Since 'zones_configured' remains 'false', the configured zones are
not reverted.
Replace the 'zones_configured' variable with a pointer to the latest
successfully configured zone configuration element, and when reverting,
revert up to and including that zone.
(cherry picked from commit 84c235a4b0)
The trick is to configure a duplicate zone, which comes after the
catalog zone, where the duplicate zone is an existing member zone.
In that scenario, all the zones which come before the "faulty" zone
in the configuration file will fail to be reverted to the previous
version of the view after a reconfiguration error, and in this
particular case that will result in an assertion failure when the
catalog zone update is initiated, because it will be still tied to
the new version of the view, which was dismissed.
(cherry picked from commit 93c4f382f4)
When detaching from the previous version of the database, make sure
that the update-notify callback is unregistered, otherwise there is
an INSIST check which can generate an assertion failure in free_rbtdb(),
which checks that there are no outstanding update listeners in the list.
There is a similar code already in place for RPZ.
(cherry picked from commit cf79692a66)
The zone_postload() function can fail and unregister the callbacks.
Call dns_db_endload() only after calling zone_postload() to make
sure that the registered update-notify callbacks are not called
when the zone loading has failed during zone_postload().
Also, don't ignore the return value of zone_postload().
(cherry picked from commit ed268b46f1)
Add the 'ixfr-from-differences yes;' option to trigger a failed
zone postload operation when a zone is updated but the serial
number is not updated, then issue two successive 'rndc reload'
commands to trigger the bug, which causes an assertion failure.
(cherry picked from commit a73b67456e)
When switching to a new view during a reconfiguration (or reverting
to the old view), detach the 'rpzs' and 'catzs' from the previuos view.
The 'catzs' case was earlier solved slightly differently, by detaching
from the new view when reverting to the old view, but we can not solve
this the same way for 'rpzs', because now in BIND 9.19 and BIND 9.18
a dns_rpz_shutdown_rpzs() call was added in view's destroy() function
before detaching the 'rpzs', so we can not leave the 'rpzs' attached to
the previous view and let it be shut down when we intend to continue
using it with the new view.
Instead, "re-fix" the issue for the 'catzs' pointer the same way as
for 'rpzs' for consistency, and also because a similar shutdown call
is likely to be implemented for 'catzs' in the near future.
(cherry picked from commit 121a095a22)
The faulty "DLZ" configuration triggers a reconfiguration failure
in such a place where view reverting code is covered.
(cherry picked from commit 95f4bac002)
The tests have been executed with four jobs for a long time because the
TEST_PARALLEL_JOBS variable was set to 4 in the project's CI/CD
Variables Settings. The variable was recently dropped in favor of
.gitlab-ci.yaml one and now needs to be streamlined with the rest of
BIND 9 maintained branches.
(cherry picked from commit 03d7b45d81)
Make OpenBSD system tests more stable by disabling parallelism in CI.
Accordingly, they will run 3-4 times longer.
(cherry picked from commit d73eba57bd)
Setting TEST_PARALLEL_JOBS to 4 in FreeBSD system test jobs is a no-op
because it's already set to 4, one level above, on the global level.
(cherry picked from commit cf46addf51)
Add new SonarCloud GitHub Action and configuration; something (maybe
the way the builds were submitted) has apparently changed and the
project got deleted and the analysis wasn't working.
(cherry picked from commit 4bfbb4ddf7)
stop.pl tries to stop ns1 via rndc but fails to find rndc.conf because
the logfileconfig test code is unexpectedly executed from the
logfileconfig/ns1/ directory. Instead of stopping ns1 with rndc, it
waits for 30 seconds and then terminates ns1 with the TERM signal.
I:logfileconfig:testing default logfile using named -L file (9)
rndc: ../common/rndc.conf does not exist
Stopping ns1 with rndc was recently inadvertently introduced in
172826bfa8. Stop ns1 with the TERM signal
directly, as we did before.
