The dns_update_signaturesinc() updates zone signatures in chunks,
keeping its current state in 'zone->rss_state'. When a zone shuts
down, the signature update process is canceled, and all the data
in the state is not freed.
Create a new dns_update_state_clear() function which can be called
from dns_zone_free() to free the memory.
(cherry picked from commit 5e12906669)
When the zone is shutting down jump straight to cleanup, otherwise
an assertion failure is possible, e.g. because zone->loop can be
already NULL.
(cherry picked from commit b56e3cd2ee)
When a DNS UPDATE messages is received, the zone_send_secureserial()
function can schedule a new receive_secure_serial() call with a new
'rss' object before a previous one had a chance to be fully processed.
This can cause an assertion failure in receive_secure_serial() with a
new 'rss' object (when the old one was rescheduled because it got
DNS_R_CONTINUE from dns_update_signaturesinc()). In other words:
1. receive_secure_serial() called with rss, sets zone->rss = rss,
reschedules because of DNS_R_CONTINUE
2. receive_secure_serial() called with rss_new, INSIST fails because
zone->rss != rss_new), i.e. this was called before the old 'rss'
was fully processed
Change the code logic by introducing a new 'rss_next' field and making
sure the old 'rss' is complete before starting processing the new
one.
(cherry picked from commit 5118f3bad6)
This new check floods the server with DNS UPDATE messages for an
'inline-signing yes; sig-signing-signatures 1;' zone to see if
it manages to process the updates correctly.
(cherry picked from commit 37f265f59a)
A query for an empty non-terminal in a wildcard zone served
from the RBT zone database could abort named with an assertion
failure. It now returns the correct NODATA answer.
Closes#6170
Merge branch '6170-fix-non-terminal-wildcard-in-rbtdb-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12299
The NSEC3-signed entwild.test zone places an apex wildcard above empty
non-terminals; querying one of them with DNSSEC requested reproduces
the abort seen with the RBT zone database. The query must instead
return NODATA with an NSEC3 proof. The zone uses the default zone
database, so it only exercises RBTDB on a build that defaults to it.
Assisted-by: Claude:claude-opus-4-8
dns_rbtnodechain_next() returns DNS_R_NEWORIGIN rather than
ISC_R_SUCCESS whenever the successor lies in a different RBT origin,
which is the case when the queried name's predecessor is an empty
non-terminal with children. Treating that as a failure made
wildcard_blocked() miss the empty non-terminal that must block the
wildcard, so the expansion proceeded and later tripped an assertion.
activeempty() already handled both results.
Callbacks for libuv stream reads do not signal zero-length reads as a
failure signal but rather as EAGAIN/EWOULDBLOCK. This can trigger an
assertion when a zero-length read is pushed onto a PROXYv2 endpoint that
has not yet processed the headers as it expects a non-NULL region of
positive length.
Closes#6140
Backport of MR !12261
Merge branch 'backport-6140-proxyv2-assertion-on-zero-byte-read-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12291
Callbacks for libuv stream reads do not signal zero-length reads as a
failure signal but rather as EAGAIN/EWOULDBLOCK. This can trigger an
assertion when a zero-length read is pushed onto a PROXYv2 endpoint that
has not yet processed the headers as it expects a non-NULL region of
positive length.
(cherry picked from commit 20d3ef1643)
The third-party comparison is right at the 0.4 % threshold, making it
fail quite often. The current range of observed values ranges from
0.3-0.5 %. Raise the threshold to 0.5 %.
The recent-named comparison produces values ranging from 0.05 to 0.12 %,
but appears to be more sensitive to time of the day when the test runs.
Raise the threshold to 0.15 %.
Both results are stable within the specified ranges across the last
three releases in both main and bind-9.20 series.
Backport of MR !12286
Merge branch 'backport-nicki/respdiff-threshold-bump-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12287
The third-party comparison is right at the 0.4 % threshold, making it
fail quite often. The current range of observed values ranges from
0.3-0.5 %. Raise the threshold to 0.5 %.
The recent-named comparison produces values ranging from 0.05 to 0.12 %,
but appears to be more sensitive to time of the day when the test runs.
Raise the threshold to 0.15 %.
Both results are stable within the specified ranges across the last
three releases in both main and bind-9.20 series.
(cherry picked from commit a8413fa94c)
When on an ``rndc reconfig`` the DNSSEC policy changes such that it changes the expected ``CDNSKEY`` and/or ``CDS`` records in the zone, the RRset should
be updated accordingly. This did not happen when removing digests from the configuration, or setting `cdnskey no;`. This has been fixed.
Closes#6166
Backport of MR !12265
Merge branch 'backport-6166-reconfig-delete-cds-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12284
With dnssec-signzone smart-signing (-S), the CDS and CDSNKEY are
derived from the key timing metadata and the configuration options (-G).
The test has specific test cases that smart signing (with the fix)
interferes with. Therefor, disable smart-signing in the cds system test.
(cherry picked from commit fdf74636e2)
When adding to dnssec-policy:
cdnskey no;
cds-digest-types { };
and then reconfig the server, named must remove existing CDS and CDNSKEY
records. Note this already worked when adding CDS digest, or setting
'cdnskey yes;', but not when digests were removed from the list, or
when setting 'cdnskey no;'.
(cherry picked from commit 1c4c2cba8b)
When on an 'rndc reconfig' the DNSSEC policy changes such that it
changes the expected CDNSKEY/CDS records in the zone, the RRset should
be updated accordingly.
Add a test case where we reconfigure a zone with a policy such that
these records should be removed, and on a second reconfigure add
them back again.
Note the test deliberately adds a different CDS digest on the
second reconfigure.
(cherry picked from commit 89ebe61ad3)
A positive wildcard answer, and the NSEC3 proof that the requested
name doesn't exist in the zone, must both be from the same zone.
Otherwise, an NSEC3 from an ancestor zone could be used to interfere
with validation.
We now retrieve the signer name from a wildcard response's signature.
An NSEC3 record cannot be used as a NOQNAME proof for the
wildcard unless it exactly matches the name one level above the NSEC3.
Closes#5971
Backport of MR !12256
Merge branch 'backport-5971-wildcard-noqname-mismatch-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12279
A positive wildcard answer, and the NSEC3 proof that the requested
name doesn't exist in the zone, must both be from the same zone.
Otherwise, an NSEC3 from an ancestor zone could be used to interfere
with validation.
We now retrieve the signer name from a wildcard response's signature.
An NSEC3 record cannot be used as a NOQNAME proof for the wildcard
unless it exactly matches the name one level above the NSEC3.
Fixes: isc-projects/bind9#5971
(cherry picked from commit 45c9bd2603)
Under certain circumstances, a cached SERVFAIL response could incorrectly prevent successful resolution of a CNAME target. This could cause resolution failures to persist until the cached SERVFAIL entry expired, even when the CNAME target itself was otherwise resolvable. This issue has been fixed.
Closes#5983
Backport of MR !12158
Merge branch 'backport-5983-servfail-cache-cname-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12259
Instead of using `client->query.qname` when caching a SERVFAIL answer,
use `client->query.origqname` when available.
This avoids caching a SERVFAIL against a CNAME target when the failure
occurs while the resolver is following the CNAME chain. This is
problematic, for instance, when the SERVFAIL is triggered by the
`max-query-count` threshold being reached, which would incorrectly
prevent legitimate resolution of the CNAME target while in the SERVFAIL
cache.
Note that if the SERVFAIL genuinely originated from resolving the CNAME
target, that specific failure will no longer be cached, and a direct
query for the CNAME target will trigger a fresh (likely failing)
resolution attempt. However, this is still preferable to the previous
behaviour, which would wrongly prevent resolving the CNAME target if it
was cached for other reasons (like the example above).
(cherry picked from commit 66af5b464d)
Add a system test for the case where resolution SERVFAILs because the
fetch context reaches the `max-query-count` threshold while following a
CNAME.
Resolving the CNAME target independently should still work, because the
SERVFAIL cache stores the original query name rather than the target.
(cherry picked from commit d238b8eece)
Since internal communications are now Zulip based, CI jobs now target
Zulip instead of Mattermost. The `MATTERMOST_WEBHOOK_URL` environment
variable is no longer needed, scripts now use `ZULIP_SERVER_URL` and
`ZULIP_API_KEY`.
In order to harmonize Zulip messaging, `message_zulip.py` is used where
curl calls to the webhook were previously used.
Backport of MR !12199
Merge branch 'backport-andoni/mattermost-to-zulip-migration-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12275
Since internal communications are now Zulip based, CI jobs now target
Zulip instead of Mattermost. The MATTERMOST_WEBHOOK_URL environment
variable is no longer needed, scripts now use ZULIP_SERVER_URL and
ZULIP_API_KEY.
In order to harmonize Zulip messaging, message_zulip.py is used where
curl calls to the webhook were previously used.
(cherry picked from commit ae45f4fa84)
The rpz servfail-until-ready test assumed a particular policy zone always
finished loading last, which only holds when zone updates run in parallel;
on a single CPU (or with serialized offload) it could fail spuriously. It now
polls until RPZ reports ready instead.
Backport of MR !12251
Merge branch 'backport-ondrej/fix-rpz-system-test-on-single-cpu-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12253
RPZ is ready only once every policy zone has completed its first update,
and the zones do not finish in a fixed order, so whenever the updates
run serially (per-loop offload, or any single-CPU run): 'slow-rpz' zone
can finish before the others and the query still gets SERVFAIL. Poll
the query until it returns NOERROR instead.
Assisted-by: Claude:claude-opus-4-8
(cherry picked from commit 153c9d3509)
Fold the libuv thread pool and the per-loop isc_helper threads into a single
isc_work pool. Each (loop, lane) gets its own SPSC queue and worker, which drops
the shared-queue contention, and the FAST/SLOW lanes keep short crypto tasks off
the long blocking ones (zone dump/load, xfrin). isc_work jobs are now cancelable:
isc_work_cancel() tombstones a still-queued job and its after_cb fires with
ISC_R_CANCELED, so abandoned work can be dropped instead of run to completion.
Backport of MR !12226
Merge branch 'backport-ondrej/rewrite-threadpool-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12267
Offloaded work used two different mechanisms: a per-loop isc_helper
thread for CPU-bound crypto (DNSSEC validation, message signature
checks) and the process-global libuv thread pool for blocking I/O (zone
load and dump, inbound transfer apply). Neither could cancel a queued
task, and the two disagreed about exclusive mode — the helper paused
with its loop under isc_loopmgr_pause() but the libuv pool did not, so
blocking offloaded work kept running while a loop held the exclusive
lock.
Unify both behind isc_work: each loop gets its own worker thread per
lane — FAST for short, bounded tasks and SLOW for long, blocking ones —
fed by a private queue. Separate lanes keep a short crypto task off the
path of a multi-second zone dump once both run on per-loop workers;
every lane parks with isc_loopmgr_pause() so exclusive mode now quiesces
offloaded work too; and a still-queued task can be canceled before it
starts (isc_work_cancel). isc_helper is removed and its callers select a
lane.
(cherry picked from commit a5f13b3410)
Previously, when the additional section of a response was being
populated, if cached data was found with pending trust, it would be
opportunistically validated. The code implementing this validation was
not quite formally correct. Rather than fixing it, the code has been
removed: RRsets with pending trust are now omitted from responses.
Closes#5966Closes#5968Closes#5972
Backport of MR !12236
Merge branch 'backport-each-remove-lightweight-validator-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12258
The removal of the secondary validator in lib/ns/query.c now means
that some responses will omit additional data or NS records in the
authority section that had pending trust. Some test cases have been
revised or deleted to take this into account.
Exclude ansX directories from vulture, as splitting up the handlers into
multiple files gets flagged as unused code.
(cherry picked from commit 72bda8335f)
Merge the tests for #5966 (F-043) and #5972 (F-045), previously called
dnssec_wildcard_additional and dnssec_replayed_parent_wildcard, into a
single directory with two modules.
(cherry picked from commit 05691b53da)
Previously, when the additional section of a response was being
populated, if cached data was found with pending trust, it would be
opportunistically validated. The code implementing this validation was
not quite formally correct; rather than fixing it, the code has been
removed; RRsets with pending trust are now omitted from responses.
Fixes: isc-projects/bind9#5966Fixes: isc-projects/bind9#5968Fixes: isc-projects/bind9#5972
(cherry picked from commit 7ec85b4bd2)
The code printing query statistics was ignoring the zone-statistics
option. This has been fixed.
Closes#6164
Backport of MR !12262
Merge branch 'backport-6164-no-per-zone-glue-stats-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12263
We no longer want to encourage people to open new issues via email because we are getting too many spammy reports generated by LLM. By requiring people actually login to Gitlab to make their report, they will (hopefully) see our reporting template, and think at least a little bit about whether they are making a well-considered, valid report.
Backport of MR !12248
Merge branch 'backport-vicky-main-patch-01884-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12254
isc__nm_http_request()'s error path reloaded sock->h2->connect.cstream after client_send() had already detached and freed it on a submit failure, dereferencing NULL. The helper is only used by the DoH unit tests. Guard the cleanup path against the detached stream.
Closes#6160
Backport of MR !12247
Merge branch 'backport-6160-fix-latent-NULL-dereference-in-http2-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12249
On a submit failure, client_send() nullifies sock->h2->connect.cstream
and frees the stream before returning the error. The error: label in
isc__nm_http_request() reloaded that pointer and dereferenced it
unconditionally, reading through a NULL stream. The function is only
used by the DoH unit tests -- production DoH client send goes through
isc__nm_http_send()/client_httpsend(), whose submit failure is reported
via the NULL-safe send callback -- so this is a latent defect in the
test helper rather than a reachable named crash.
Skip the read callback when the stream has already been detached and
let the caller report the failure from the error result it receives.
Assisted-by: Claude:claude-opus-4-8
(cherry picked from commit 7df91b7634)
It was possible to use a maliciously crafted authoritative
zone to make :iscman:`named` resolver synthesize a ``DNAME``
"alias" that should have been rejected by the configured
:any:`deny-answer-aliases` option. This has been fixed.
Closes#5930
Backport of MR !12044
Merge branch 'backport-5930-deny-answer-aliases-and-cached-dname-buf-fix-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12245
When using a cached DNAME to resolve a name, make sure to consult
the denied answers lists, otherwise it is possible to consutruct
a restricted alias by caching a DNAME that is a parent of the
denied alias. See the comments in the tests case from the previous
commit an example.
(cherry picked from commit 45c1d760a8)
This new check exercises an attack against guarantees given by the
'deny-answer-aliases' configuration option by caching a DNAME
that is a parent of the restricted alias, and then "constructing"
the restricted alias from the cache.
(cherry picked from commit 1645b09341)
