Flushing the name when NTA expires causes problems for the ongoing
resolving process. Do not flush the name from the cache. Instead,
the resolver should do the flushing (this is planned to be merged
next).
After KeyTrap, the temporal DNSSEC were originally hard errors that
caused validation failures even if the records had another valid
signature. This has been changed and the RRSIGs outside of the
inception and expiration time are not counted as hard errors. However,
these errors are not even counted as validation attempts, so excessive
number of expired RRSIGs would cause some non-cryptograhic extra work
for the validator. This has been fixed and the temporal errors are
correctly counted as validation attempts.
Closes#5760
Merge branch '5760-count-DNSSEC-temporal-errors-as-validation-attempts' into 'main'
See merge request isc-projects/bind9!11589
After KeyTrap, the temporal DNSSEC were originally hard errors that
caused validation failures even if the records had another valid
signature. This has been changed and the RRSIGs outside of the
inception and expiration time are not counted as hard errors. However,
these errors are not even counted as validation attempts, so excessive
number of expired RRSIGs would cause some non-cryptograhic extra work
for the validator. This has been fixed and the temporal errors are
correctly counted as validation attempts.
An authenticated DDNS client could bypass update-policy per-type record limits
(e.g. TXT(3)) by including padding records in the UPDATE message that are
silently skipped during processing. Each skipped record shifted an internal
counter, causing subsequent records to be checked against the wrong quota —
potentially reading an unlimited (0) entry instead of the configured maximum.
This allowed a client with valid TSIG credentials to add an arbitrary number of
records beyond the configured limit across repeated UPDATE messages up to the
`max-records-per-type` limit.
Closes#5799
Merge branch '5799-fix-counter-desync-in-SSU' into 'main'
See merge request isc-projects/bind9!11708
The prescan and main update loops in DNS UPDATE processing both used the
same counter to index the maxbytype[] quota array. The prescan loop
always incremented the counter, but the main loop had 14 continue paths
that skipped the increment. This allowed an authenticated DDNS client to
craft an UPDATE message with padding records (e.g. CNAME+A pairs that
trigger CNAME-conflict skips) to shift the counter and read wrong quota
entries, bypassing per-type record limits entirely.
Fix by incrementing the counter unconditionally at the start of each
iteration in the main loop.
The :iscman:`named` process could terminate unexpectedly when
processing a catalog zone ACL in an APL resource record that
was completely empty. This has been fixed.
Closes#5801
Merge branch '5801-catz-empty-apl-rr-bug-fix' into 'main'
See merge request isc-projects/bind9!11740
Allow empty APL records because RFC 3123 (Section 4) says "zero or
more items". This fixes processing of a catalog zone ACL (which is
based on APL records) when the zone contains an empty APL record or
when a zone update arrives which creates an empty APL record.
In the current statistics counter implementation, the statistics are
backed by an array of counters, which are updated via atomic operations.
This leads to contention, especially on high core count
machines.
This commit introduces a new isc_statsmulti_t counter that keeps a
separate array per thread. These counters are then aggregated only when
statistics are queried, shifting work off the critical path.
These changes lead to a ~2% improvement in perflab.
Merge branch 'alessio/statsmulti-v2' into 'main'
See merge request isc-projects/bind9!11036
Since it is impossible to increase an isc_statsmulti counter and
retrieve the new counter atomically, and we need the output of
recursclients in order to compute ns_highwater_recursive, we change the
recursclients counter to an isc_stats one.
In the current statistics counter implementation, the statistics are
backed by an array of counters, which are updated via atomic operations.
This leads to contention, especially on high core count
machines.
This commit introduces a new isc_statsmulti_t counter that keeps a
separate array per thread. These counters are then aggregated only when
statistics are queried, shifting work off the critical path.
These changes lead to a ~2% improvement in perflab.
This adds the switch +[no]cookie to delv to control the sending of
DNS COOKIE options when sending requests. The default is to send
DNS COOKIE options.
Closes#5825
Merge branch '5825-switch-to-disable-cookie-checking-in-delv' into 'main'
See merge request isc-projects/bind9!11733
This adds the switch +[no]cookie to delv to control the sending of
DNS COOKIE options when sending requests. The default is to send
DNS COOKIE options.
The "publish" job has no dependencies on other jobs, so nothing prevents
it from being accidentally started before the scheduled publication
date. Although publication still requires confirmation via an SSH
connection to a dedicated, locked-down runner, performing that action
prematurely may have drastic consequences. Therefore, it is worth
implementing additional safeguards.
Add an extra check to the "publish" job to ensure it can only be run on
the scheduled publication day. In exceptional circumstances, this check
can be overridden by setting the FORCE_PUBLICATION CI variable to any
non-empty value.
The "merge-tag" and "update-stable-tag" jobs currently use the
"manual_release_job_qa" YAML anchor, which makes them depend on the
"staging" job. Meanwhile, both of these jobs require the tag they were
created for to be public for them to work. While this is harmless, as
these jobs will simply fail if they are run too early, it still makes
sense for them to depend on the "publish" job instead, if only to reduce
confusion in the pipeline view. Adjust the "needs" key for the
"merge-tag" and "update-stable-tag" jobs accordingly.
The commit.txt file produced by each Cloudsmith build job is required to
run the corresponding publication job. Therefore, the artifact lifetime
for the former must be long enough to prevent the file from expiring
before the publication job is run. Set the lifetime of the artifacts
created by Cloudsmith build jobs to one month to ensure that the
publication jobs can access them.
Setting "artifacts: false" for the dependency on the "publish-private"
job prevents the url-*.txt files produced by that job from being pulled
from GitLab when the jobs that build EVN & -S Cloudsmith packages are
run, effectively breaking the latter. Fix by making these jobs depend
on the artifacts of the "publish-private" job.
The "nsec3-delegation" test was added in a release branch, before commit
67aca1f8c6 introduced the current system
test naming convention. Rename the test to comply with that convention.
Merge branch 'michal/rename-nsec3-delegation-test' into 'main'
See merge request isc-projects/bind9!11753
The "nsec3-delegation" test was added in a release branch, before commit
67aca1f8c6 introduced the current system
test naming convention. Rename the test to comply with that convention.
Unlike new transports with a new dependency DNS-over-QUIC support will
be added incrementally due to the non-trivial amound of plumbing
required by libngtcp2. This will require non-functional QUIC code in the
main branch that won't be exposed for non-development builds.
Therefore, libngtcp2 is linked as an optional dependency only on
explicitly enabled development builds and cannot be required. This will
be changed with a `doq` meson build option once the server-side
functionality is complete for consumption.
Merge branch 'aydin/ngtcp2-dev-only' into 'main'
See merge request isc-projects/bind9!11557
Unlike new transports with a new dependency DNS-over-QUIC support will
be added incrementally due to the non-trivial amound of plumbing
required by libngtcp2. This will require non-functional QUIC code in the
main branch that won't be exposed for non-development builds.
Therefore, libngtcp2 is linked as an optional dependency only on
explicitly enabled development builds and cannot be required. This will
be changed with a `doq` meson build option once the server-side
functionality is complete for consumption.
Commit `604d8f0b967563b0ba9dcd4f09559fdd9e21dfbe` introduced during 9.19
development cycle a check to ensure the resolver never attempts to
lookup more than 20 NS names. This limit was introduced by
`3a44097fd6c6c260765b628cd1d2c9cb7efb0b2a` as part of the CVE-2022-2795.
However, this test relies on the fact that, at the time, the NS names
were processed in a specific order in the nameserver.
This is not true anymore, as the NS are in a random order. Moreover,
commit `3c33e7d9370006b1599e3d99c0d5fa6a6dad7979` introduced the
randomization of the selection of the NS names to lookup, which make the
test potentially unreliable, as it now doesn't mean anything to check
the nameserver does not query `ns21.fake.redirect.com.`, as it could be
the first one, or in any position form the randomized list.
Another test has been added in commit
`c67b52684f11652b07afaa75a917f6f0355dbca6` which test both the
randomization of the NS name to be looked up, as well as the upper bound
limit of NS name lookup to be done.
For all those reasons, this specific legacy check is now removed.
Merge branch 'colin/remove-incompatble-nslimit-check' into 'main'
See merge request isc-projects/bind9!11745
Commit `604d8f0b967563b0ba9dcd4f09559fdd9e21dfbe` introduced during 9.19
development cycle a check to ensure the resolver never attempts to
lookup more than 20 NS names. This limit was introduced by
`3a44097fd6c6c260765b628cd1d2c9cb7efb0b2a` as part of the CVE-2022-2795.
However, this test relies on the fact that, at the time, the NS names
were processed in a specific order in the nameserver, as this snip from
the log (from a build on `604d8f0` branch) running the test illustrates:
```
24-Mar-2026 21:19:46.346 dispatch 0x7fdaa722d200: success, length == 19956, addr = 0x7fdaa0a7c102
24-Mar-2026 21:19:46.346 dispatch 0x7fdaa722d200: got valid DNS message header, /QR 1, id 14328
24-Mar-2026 21:19:46.346 dispatch 0x7fdaa722d200: search for response in bucket 7213: success
24-Mar-2026 21:19:46.354 received packet from 10.53.0.3#5300
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14328
;; flags: qr aa; QUESTION: 1, ANSWER: 0, AUTHORITY: 999, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: baf16b0241efc700
;; QUESTION SECTION:
;large-referral.example.net. IN A
;; AUTHORITY SECTION:
;large-referral.example.net. 300 IN NS ns1.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns2.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns3.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns4.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns5.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns6.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns7.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns8.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns9.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns10.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns11.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns12.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns13.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns14.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns15.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns16.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns17.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns18.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns19.fake.redirect.com.
;large-referral.example.net. 300 IN NS ns20.fake.redirect.com.
```
This is not true anymore, as the NS are in a random order. Moreover,
commit `3c33e7d9370006b1599e3d99c0d5fa6a6dad7979` introduced the
randomization of the selection of the NS names to lookup, which make the
test potentially unreliable, as it now doesn't mean anything to check
the nameserver does not query `ns21.fake.redirect.com.`, as it could be
the first one, or in any position form the randomized list.
Another test has been added in commit
`c67b52684f11652b07afaa75a917f6f0355dbca6` which test both the
randomization of the NS name to be looked up, as well as the upper bound
limit of NS name lookup to be done.
For all those reasons, this specific legacy check is now removed.
The -C option, introduced in BIND 9.7, caused a backward-compatible
key to be generated, using private key format version 1.2, omitting the
creation date and other timing metadata. This made it possible to
generate keys that could be loaded by older versions of BIND.
Those older versions having reached end of life many years ago, the
option can now be removed, along with the `dnssec-settime -f` option,
which caused old-style keys to be upgraded.
Merge branch 'each-remove-keygen-compat' into 'main'
See merge request isc-projects/bind9!11446
The -C option, introduced in BIND 9.7, caused a backward-compatible
key to be generated, using private key format version 1.2, omitting the
creation date and other timing metadata. This made it possible to
generate keys that could be loaded by older versions of BIND.
Those older versions having reached end of life many years ago, the
option can now be removed, along with the "dnssec-settime -f" option,
which caused old-style keys to be upgraded.
Previously, `rpz_rrset_find()` behaved differently depending on whether
a cache lookup returned `DNS_R_DELEGATION` or `ISC_R_NOTFOUND`. The former
indicates the presence of a cached NS rrset, and the latter indicates
that the cache is cold or that all NS rrsets above the query name have
expired. Both results indicate that the caller should recurse, but
`rpz_rrset_find()` only recursed in the case of `DNS_R_DELEGATION`. This
has been fixed and the test updated to match.
Merge branch 'each-rpz-recursion' into 'main'
See merge request isc-projects/bind9!11741
previously, rpz_rrset_find() behaved differently depending on whether
a cache lookup returned DNS_R_DELEGATION or ISC_R_NOTFOUND. the former
indicates the presence of a cached NS rrset, and the latter indicates
that the cache is cold or that all NS rrsets above the query name have
expired. both results indicate that the caller should recurse, but
rpz_rrset_find() only recursed in the case of DNS_R_DELEGATION.
the nsip-wait-recurse and nsdname-wait-recurse test cases in the
rpzrecurse system test were dependent on this misbehavior. the test
server was configured with a lame delegation, so that recursion always
failed, but once the lame delegation was expired due to a zero TTL, the
cache returned ISC_R_NOTFOUND, which caused the recursion not to be
attempted. the test seemed to be observing a delay before recursion
succeeded, but it was actually observing a delay before recursion was
skipped. fixing this bug caused the test to fail.
the test server has now been reconfigured so that recursion succeeds
after a delay, instead of failing. now we're able to test that
we're waiting for the successful completion of recursion.
Fixed a crash that could occur when running rndc reconfig to change a zone's update policy (e.g., from allow-update to update-policy) while DNS UPDATE requests were being processed for that zone.
ISC would like to thank Vitaly Simonovich for bringing this issue to our attention.
Fixes#5817
Merge branch '5817-fix-crash-via-SSU-table-desynchronization' into 'main'
See merge request isc-projects/bind9!11707
Race rndc reconfig (toggling between allow-update and update-policy)
against a stream of DNS UPDATEs for 5 seconds and verify that named
does not crash.
Before the fix, the race between send_update() and update_action()
reading the SSU table independently could trigger an assertion
failure (INSIST) when the zone's update policy changed between the
two reads.
Pass the SSU table through the update event struct from
send_update() to update_action() instead of reading it from the
zone twice. If rndc reconfig changed the zone's update policy
between the two reads (e.g., from allow-update to update-policy),
send_update() would skip the maxbytype allocation but
update_action() would see a non-NULL ssutable, triggering
INSIST(ssutable == NULL || maxbytype != NULL) and crashing named.
The ssutable reference is now taken once in send_update() and
transferred to update_action() via the event struct, ensuring
both functions see the same value.
A helper macro that returns the current value of a pointer and sets
it to NULL in one expression, useful for transferring ownership in
designated initializers.
Merge branch 'ondrej/TAKE_OWNERSHIP-macro' into 'main'
See merge request isc-projects/bind9!11724
Replace the local SAVE(), RESTORE(), and INITANDSAVE() macros in
query.c with the project-wide MOVE_OWNERSHIP() macro. The new
form is clearer about the intent: ownership of a pointer is being
transferred from source to destination, with the source set to NULL.
SAVE and RESTORE were identical macros with different names used to
indicate the direction of transfer, but this distinction was purely
cosmetic. INITANDSAVE additionally set the destination to NULL
first, which is unnecessary because the preceding memcpy already
initialized all fields from the source struct.
A helper macro that returns the current value of a pointer and sets
it to NULL in one expression, useful for transferring ownership in
designated initializers.
The usage still said the default NSEC3 iterations is 10, but this
has been 0 for a while.
Merge branch 'matthijs-dnssec-signzone-help-nsec3iter' into 'main'
See merge request isc-projects/bind9!11727
dns_view_flushnode() was called in the delete_expired() async
callback, which runs after the query that detected the NTA expiry.
This created a race: the query would proceed with stale cached data
from the NTA period before the flush had a chance to run, resulting
in transient SERVFAIL with EDE 22 (No Reachable Authority).
Move dns_view_flushnode() into dns_ntatable_covered() so the cache
is flushed synchronously when the expiry is detected, before the
query continues.
Also simplify the expiry comparison in delete_expired() to a direct
pointer comparison (nta == pval) instead of comparing expiry
timestamps.
Merge branch 'ondrej/refactor-nta-using-RCU-delete-order-fix' into 'main'
See merge request isc-projects/bind9!11729
dns_view_flushnode() was called in the delete_expired() async
callback, which runs after the query that detected the NTA expiry.
This created a race: the query would proceed with stale cached data
from the NTA period before the flush had a chance to run, resulting
in transient SERVFAIL with EDE 22 (No Reachable Authority).
Move dns_view_flushnode() into dns_ntatable_covered() so the cache
is flushed synchronously when the expiry is detected, before the
query continues.
Also simplify the expiry comparison in delete_expired() to a direct
pointer comparison (nta == pval) instead of comparing expiry
timestamps.
