The issue of long-running operations potentially blocking query resolution has been fixed. Revert this temporary workaround and restore the number of threadpool threads.
Related #4898
Backport of MR !9530
Merge branch 'backport-4898-remove-workaround-and-note-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!9532
when the QP cache was adapted from the RBTDB, some variable names weren't changed, and still incorrectly reference the RBT.
Backport of MR !9515
Merge branch 'backport-each-qpcache-nits-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!9525
when the QP cache was adapted from the RBT database, some names
weren't changed. this could be confusing, so let's change them now.
also, we no longer need to include rbt.h.
(cherry picked from commit 5a444838db)
Some 'notify' and 'xfer-in' related log messages were logged at the
'general' category instead of their own category. This has been fixed.
Closes#2730
Backport of MR !9451
Merge branch 'backport-2730-logging-category-for-notify-and-xfer-related-messages-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!9514
Some notify/xfer related log messages are logged at the general
category. Set a more suitable caterogry for those messages.
(cherry picked from commit 7c45caa8a5)
If the operating system UDP queue gets full and the outgoing UDP sending
starts to be delayed, BIND 9 could exhibit memory spikes as it tries to
enqueue all the outgoing UDP messages. Try a bit harder to deliver the
outgoing UDP messages synchronously and if that fails, drop the outgoing
DNS message that would get queued up and then timeout on the client side.
Closes#4930
Backport of MR !9506
Merge branch 'backport-4930-limit-the-UDP-send-queue-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!9511
If the operating system UDP queue gets full and the outgoing UDP sending
starts to be delayed, BIND 9 could exhibit memory spikes as it tries to
enqueue all the outgoing UDP messages. As those are not going to be
delivered anyway (as we argued when we stopped enlarging the operating
system send and receive buffers), try to send the UDP messages directly
using `uv_udp_try_send()` and if that fails, drop the outgoing UDP
message.
(cherry picked from commit b576c4c977)
We currently set SO_INCOMING_CPU incorrectly, and testing by Ondrej
shows that fixing the issue by setting affinities is worse than letting
the kernel schedule threads without constraints. So we should not set
SO_INCOMING_CPU anymore.
Closes#4936
Backport of MR !9497
Merge branch 'backport-4936-remove-so-incoming-cpu-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!9504
We currently set SO_INCOMING_CPU incorrectly, and testing by Ondrej
shows that fixing the issue and setting affinities is worse than letting
the kernel schedule threads without constraints. So we should not set
SO_INCOMING_CPU anymore.
(cherry picked from commit 8b8149cdd2)
When resolving a zone with a 'forward only' policy, and
finding out that all the forwarders are marked as "bad",
the 'ServerQuota' counter of the statistics channel was
incorrectly increased. This has been fixed.
Closes#1793
Backport of MR !9493
Merge branch 'backport-1793-serverquota-counter-bug-with-forward-only-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!9502
Check that the fix in the previous commit works and that the
'ServerQuota' counter in the statistics channel is still unset
after a SERVFAIL result in a 'forward only' zone.
(cherry picked from commit 81b3c5d908)
The 'all_spilled' local variable in resolver.c:fctx_getaddresses()
is 'true' by default, and only becomes false when there is at least
one successfully found NS address. However, when a 'forward only;'
configuration is used, the code jumps over the part where it looks
for NS addresses and doesn't reset the 'all_spilled' to false, which
results in incorretly increased 'serverquota' statistics variable,
and also in invalid return error code from the function. The result
code error didn't make any differences, because all codes other than
'ISC_R_SUCCESS' or 'DNS_R_WAIT' were treated in the same way, and
the result code was never logged anywhere.
Set the default value of 'all_spilled' to 'false', and only make it
'true' before actually starting to look up NS addresses.
(cherry picked from commit e430ce7039)
Silence Coverity CID 468757 and 468767 (DATA RACE read not locked) by converting dnssec-signzone to use atomics for statistics counters rather than using a lock.
Closes#4939
Backport of MR !9496
Merge branch 'backport-4939-remove-stats-lock-from-dnssec-signzone-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!9500
Silence Coverity CID 468757 and 468767 (DATA RACE read not locked)
by converting dnssec-signzone to use atomics for statistics counters
rather than using a lock. This should be marginally faster than
using the lock as well when statistics are requested.
(cherry picked from commit 473cbd4e87)
As part of the KeyTrap \[CVE-2023-50387\] mitigation, the DNSSEC CPU-intensive operations were offloaded to a separate threadpool that we use to run other tasks that could affect the networking latency.
If that threadpool is running some long-running tasks like RPZ, catalog zone processing, or zone file operations, it would delay DNSSEC validations to a point where the resolving signed DNS records would fail.
Split the CPU-intensive and long-running tasks into separate threadpools in a way that the long-running tasks don't block the CPU-intensive operations.
Closes#4898
Backport of MR !9473
Merge branch 'backport-4898-move-offloaded-DNSSEC-to-own-threads-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!9495
Currently, the isc_work API is overloaded. It runs both the
CPU-intensive operations like DNSSEC validations and long-term tasks
like RPZ processing, CATZ processing, zone file loading/dumping and few
others.
Under specific circumstances, when many large zones are being loaded, or
RPZ zones processed, this stops the CPU-intensive tasks and the DNSSEC
validation is practically stopped until the long-running tasks are
finished.
As this is undesireable, this commit moves the CPU-intensive operations
from the isc_work API to the isc_helper API that only runs fast memory
cleanups now.
(cherry picked from commit 8a96a3af6a)
Add an extra thread that can be used to offload operations that would
affect latency, but are not long-running tasks; those are handled by
isc_work API.
Each isc_loop now has matching isc_helper thread that also built on top
of uv_loop. In fact, it matches most of the isc_loop functionality, but
only the `isc_helper_run()` asynchronous call is exposed.
(cherry picked from commit 6370e9b311)
Closes#4634
Backport of MR !9150
Merge branch 'backport-4634-drop-dns.resolver-module-from-system-tests-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!9491
When verifying a message in an offloaded thread there is a race with
the worker thread which writes to the same buffer. Clone the message
buffer before offloading.
Closes#4929
Backport of MR !9481
Merge branch 'backport-4929-data-race-in-dns_dnssec_verifymessage-memmove-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!9490
When verifying a message in an offloaded thread there is a race with
the worker thread which writes to the same buffer. Clone the message
buffer before offloading.
(cherry picked from commit 35ef25e5ea)
When the libxml2 and libjson-c libraries are not supported, the statistics channel can't return anything useful, so it is now disabled. Use of `statistics-channel` in `named.conf` is a fatal error.
Closes#4895
Backport of MR !9423
Merge branch 'backport-4895-link-style-sheet-to-libxml2-support-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!9486
If neither libxml2 nor libjson_c are available have named-checkconf
fail if a statistics-channels block is specified.
(cherry picked from commit b9246418e8)
The `statschannel` system test failed if only one of `libxml2` or `json-c` is
available / configured as checks were being run against the non available
statistics page.
Closes#4919
Backport of MR !9454
Merge branch 'backport-4919-fix-statschannel-system-test-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!9483
Forward-port of !9375Closes#4832
Merge branch '4832-bind-arm-review-from-2022-through-9-18-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!9480
clang 19 was updated in the base image.
Backport of MR !9475
Merge branch 'backport-mnowak/fix-clang-format-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!9477
This change allows fallback from an IXFR failure to AXFR when the reason is `DNS_R_TOOMANYRECORDS`. This is because this error condition could be temporary only in an intermediate version of IXFR transactions and it's possible that the latest version of the zone doesn't have that condition. In such a case, the secondary would never be able to update the zone (even if it could) without this fallback.
This fallback behavior is particularly useful with the recently introduced `max-records-per-type` and `max-types-per-name` options: the primary may not have these limitations and may temporarily introduce "too many" records, breaking IXFR. If the primary side subsequently deletes these records, this fallback will help recover the zone transfer failure automatically; without it, the secondary side would first need to increase the limit, which requires more operational overhead and has its own adverse effect.
Closes#4928
Backport of MR !9333
Merge branch 'backport-fallback-ixfr-to-axfr-on-toomanyrecords-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!9471
This change allows fallback from an IXFR failure to AXFR when the
reason is DNS_R_TOOMANYRECORDS. This is because this error condition
could be temporary only in an intermediate version of IXFR
transactions and it's possible that the latest version of the zone
doesn't have that condition. In such a case, the secondary would never
be able to update the zone (even if it could) without this fallback.
This fallback behavior is particularly useful with the recently
introduced max-records-per-type and max-types-per-name options:
the primary may not have these limitations and may temporarily
introduce "too many" records, breaking IXFR. If the primary side
subsequently deletes these records, this fallback will help recover
the zone transfer failure automatically; without it, the secondary
side would first need to increase the limit, which requires more
operational overhead and has its own adverse effect.
This change also fixes a minor glitch that DNS_R_TOOMANYRECORDS wasn't
logged in xfrin_fail.
(cherry picked from commit 7289090683)
The named process could terminate unexpectedly when processing access
control lists (ACLs). This has been fixed.
Closes#4908
Backport of MR !9458
Merge branch 'backport-4908-acl-assertion-failure-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!9466
The rcu_xchg_pointer() function can be used outside of a critical
section, and usually must be followed by a synchronize_rcu() or
call_rcu() call to detach from the resource, unless if there are
some guarantees in place because of our own reference counting.
(cherry picked from commit 0367c60759)
This file was initially created for unit testing, but later code was added to generate the file. The static file should have been removed from the git repo.
Closes#4916
Backport of MR !9450
Merge branch 'backport-4916-skr-unit-test-rm-test-file-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!9465
This file was initially created for unit testing, but later code was
added to generate the file. The static file should have been removed
from the git repo.
(cherry picked from commit 903534c9a9)
If the ZSK has unlimited lifetime, the timing metadata "Inactive" and "Delete" cannot be found and is treated as an error, preventing the zone to be signed. This has been fixed.
Closes#4914
Backport of MR !9447
Merge branch 'backport-4914-offline-ksk-zsk-lifetime-unlimited-bug-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!9453
If the ZSK has lifetime unlimited, the timing metadata "Inactive" and
"Delete" cannot be found and is treated as an error. Fix by allowing
these metadata to not exist.
(cherry picked from commit 5af53a329f)
