Two TSIG-authenticated TKEY DELETE queries for the same dynamic key,
arriving on different worker loops, could each enter
dns_tsigkey_delete() and cause over-decrementing the key refcount.
This has been fixed by making dns_tsigkey_delete() idempotent.
(cherry picked from commit 5c8dcd4419)
When an RRset is in stale cache, and the authoritative server changes the record type to CNAME, the resolver fails to refresh the stale cache. This has been fixed.
Closes#5302
Backport of MR !11758
Merge branch 'backport-5302-serve-stale-cname-to-a-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12040
Matthijs Mekking authored 2 months ago
CNAME and other record types cannot coexist. DNSSEC records are the
exceptions to this rule.
If the answer contains a name with a CNAME, remove existing RRsets at
the same name from the cache.
If the answer contains a name without a CNAME, remove the CNAME RRset
at the same name from the cache.
(manually picked from commit 69a560fff1)
Add a serve-stale system test case where the authority changes a
CNAME RRset to A (at cname2.stale.test). The CNAME that is in the
cache is stale and should be refreshed. The target A record (at
a2.stale.test) has a longer TTL and is also still in the cache. The
next query should return the refreshed A RRset to the client.
Then the authority changes back the A RRset to CNAME. The A RRset
has become stale and should be refreshed. The next query should
return the refreshed CNAME RRset plus the already cached
a2.stale.test A record.
This test requires ns1 to allow dynamic updates to stale.test, and
prefetch to be disabled. The latter is to ensure the record is not
prefetched, but only refreshed when stale (and logs the expected
"an attempt to refresh the RRset" messages).
(cherry picked from commit 4ee526cb6d)
A recursive resolver could accept and cache an RRSIG record whose
Type-Covered field names a meta-type (ANY, AXFR, IXFR, MAILA, MAILB),
even though no real RRset of those types ever exists. Such records
are now rejected by the DNS message parser.
Closes#6002
Backport of MR !12048
Merge branch 'backport-6002-reject-rrsig-covering-meta-types-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12051
A signature cannot cover a meta-type (NONE, ANY, AXFR, IXFR, MAILB,
MAILA, OPT, TSIG, TKEY); previously such records were cached by the
recursive resolver and collided with negative-cache entries on the
same owner name, corrupting the QP-trie cache.
Assisted-by: Claude:claude-opus-4-7
(cherry picked from commit c28ba9c3c6)
A badly configured secondary signer that was missing the 'file' entry caused the server to crash, rather than to reject the configuration. This has been fixed.
Closes#5993
Backport of MR !12045
Merge branch 'backport-5993-fix-bump-in-the-wire-crash-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12112
A secondary server that is configured as a bump in the wire signer
with inline-signing implicitly enabled via dnssec-policy requires
a 'file' entry.
(cherry picked from commit 77649ea8e2)
Add a variant of checking configuration where inline-signing is
enabled on the secondary, requiring the 'file' entry. This time,
inline-signing is implicitly enabled via dnssec-policy.
(cherry picked from commit 43bbfbeb3c)
GNOME GitLab returns HTTP 406 to Sphinx's linkcheck requests, the
same behavior already worked around for gitlab.isc.org.
Assisted-by: Claude:claude-opus-4-7
(cherry picked from commit 2850dc9d71)
Add a rule to match open source stable tags in CI and apply it to the
update-stable-tag job.
Backport of MR !11646
Merge branch 'backport-andoni/show-update-stable-tag-job-in-stable-versions-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12107
The update-stable-tag job should only be run for the stable tag, which
is used by Read the Docs to build the docs for the "stable" version.
A new rule called rule_tag_open_source_stable is introduced, in order to
prevent the job from appearing in the pipeline for non-stable versions.
Having this rule in YAML is necessary, because if it were in the script
itself, the job would show up in the pipeline.
Besides, the new rule allows other jobs to be run only for the stable
tag in the future, without modifying their internal logic.
The CI variable STABLE_VERSION contains a regular expression in
Gitlab CI sense[1]: it uses the RE2 syntax[2] and must be enclosed by
slashes (i.e. /.../). It must be updated every time the minor version
is changed: releasing v9.22 will require changing STABLE_VERSION from
"/v9.20/" to "/v9.22/".
The variable is imported from common Gitlab CI YAML in the project
isc-projects/bind9-qa, so as to maintain it in a central place.
[1]: https://docs.gitlab.com/ci/jobs/job_rules/#compare-a-variable-to-a-regular-expression
[2]: https://github.com/google/re2/wiki/Syntax
(cherry picked from commit 38e80f542e)
The template file .gitlab-ci-common.yml is to be used across ISC
projects, while it is maintained in the isc-projects/bind9-qa project.
(cherry picked from commit 1c31e6fea9)
POSIX does not require localtime_r() to behave as if tzset() was called,
so the TZ environment change isn't picked up if some library has already
primed libc's tz cache. Loading pkcs11-provider during OpenSSL init
does exactly that, causing the time and dnstap cmocka tests to format
timestamps in UTC instead of the requested zone.
Assisted-by: Claude:claude-opus-4-7
(cherry picked from commit c14f7881f2)
Previously, the server would crash if it received a query with an ID
close to 65535 in the badmessageid case, as adding 50 to it would not
fit in uint16.
This was an oversight in porting it from Perl to Python in
f9ed3650ac.
Fixes#6025.
Backport of MR !12097
Merge branch 'backport-stepan/fix-xfer-large-qid-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12098
Previously, the server would crash if it received a query with an ID
close to 65535 in the badmessageid case, as adding 50 to it would not
fit in uint16.
This was an oversight in porting it from Perl to Python in
f9ed3650ac.
(cherry picked from commit e0ef63532f)
Mypy reports 'Need type annotation for "FEATURE_VARS"'; init_features()
populates it with str->str entries.
Assisted-by: Claude:claude-opus-4-7
Backport of MR !12086
Merge branch 'backport-nicki/fix-isctest-vars-mypy-annotation-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12088
Mypy reports 'Need type annotation for "FEATURE_VARS"'; init_features()
populates it with str->str entries.
Assisted-by: Claude:claude-opus-4-7
(cherry picked from commit 81c1105125)
dnspython's RRSIG.to_text() converts the signature inception/expiration
fields by calling time.gmtime(), which on 32-bit platforms raises
OverflowError for values past 2038-01-19 (INT32_MAX). Several DNSSEC
test fixtures use far-future expirations: the precomputed RRSIGs in
the dnssec test's rsasha1.example.db.in zone expire in 2093, ans4 of
the chain test hardcodes 2090, and ans10 of the dnssec test uses
2**32-1 (year 2106). Whenever a response carrying such an RRSIG is
formatted with str()/to_text() the overflow propagates out and either
fails the test (when triggered in isctest.query's debug logging) or
kills the asyncserver-based ans* server (when triggered in its
response logger), which in turn cascades into "Failed to stop
servers" teardown errors and SERVFAIL responses for subsequent tests.
Wrap the to_text() calls in isctest/query.py and the str(response)
call in asyncserver's _log_response() with try/except OverflowError,
falling back to a placeholder message. The conversions are only used
for debug logging, so losing the human-readable form there does not
affect what the tests actually validate.
Assisted-by: Claude:claude-opus-4-7
(cherry picked from commit 968ccdeeda)
Issue #5826 has two different fixes: one released in April 2026 that
applies to 9.20 and 9.18, and another released in May 2026 that applies
to 9.21. The 9.21 release note was mistakenly included in the release
notes for 9.20 and 9.18. This commit removes it.
Merge branch 'andoni/fix-doc-duplicate-note-5826' into 'bind-9.20'
See merge request isc-projects/bind9!12067
Issue #5826 has two different fixes: one released in April 2026 that
applies to 9.20 and 9.18, and another released in May 2026 that applies
to 9.21. The 9.21 release note was mistakenly included in the release
notes for 9.20 and 9.18. This commit removes it.
When `nxdomain-redirect` is in use, and a recursive query is used to get the redirected answer, a flag is set to distinguish it from a normal recursive response. Previously, that flag was left set afterward, which could trigger an assertion if a normal recursive query was sent later on behalf of the same client: for example, because the `filter-aaaa` plugin was in use. This has been fixed.
Closes#5936
Backport of MR !12073
Merge branch 'backport-5936-clear-redirect-flag-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12076
The NS_QUERYATTR_REDIRECT flag is set when processing a recursive
NXDOMAIN redirection lookup, so that if that lookup also returns
NXDOMAIN we don't end up looping.
Previously, the flag was left active after use, but if the
same client triggered a subsequent recursive lookup (for example,
in the filter-aaaa plugin), then the wrong branch could be reached
in query_resume(), potentially leading to an assertion failure. This
has been fixed.
(cherry picked from commit 3ff0018308)
The nsec3hash tool parsed its algorithm, flags, and iterations
arguments with atoi(), then range-checked the result. For values
that overflow int during digit-by-digit accumulation, atoi() is
undefined; in practice on musl libc the modular wrap leaves
n == 0, which silently passes the "iterations > 0xffffU" check.
On Alpine Linux this made nsec3hash succeed with iterations
treated as 0 for inputs like 4294967296 (2^32).
The latent bug only surfaced when the recent image rebuild pulled
in Hypothesis 6.152.9 (2026-05-19), which unified the distribution
used for bounded and unbounded integers() strategies. The new
smoother distribution explores the 2^32 boundary on unbounded
ranges like integers(min_value=65536); earlier versions did not
reach there, so test_nsec3hash_too_many_iterations only started
failing on Alpine after the image refresh.
Replace the three atoi() calls with isc_parse_uint8 /
isc_parse_uint16, which uniformly reject overflow, trailing
garbage, leading sign, and non-numeric input across libc
implementations. As a side effect, error messages now include
the offending argument and a specific reason ("out of range" vs
"not a valid number").
Assisted-by: Claude:claude-opus-4-7
Closes#6013
Backport of MR !12062
Merge branch 'backport-6013-nsec3hash-iterations-overflow-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12074
The nsec3hash tool parsed its algorithm, flags, and iterations
arguments with atoi(), then range-checked the result. For values
that overflow int during digit-by-digit accumulation, atoi() is
undefined; in practice on musl libc the modular wrap leaves
n == 0, which silently passes the "iterations > 0xffffU" check.
On Alpine Linux this made nsec3hash succeed with iterations
treated as 0 for inputs like 4294967296 (2^32).
The latent bug only surfaced when the recent image rebuild pulled
in Hypothesis 6.152.9 (2026-05-19), which unified the distribution
used for bounded and unbounded integers() strategies. The new
smoother distribution explores the 2^32 boundary on unbounded
ranges like integers(min_value=65536); earlier versions did not
reach there, so test_nsec3hash_too_many_iterations only started
failing on Alpine after the image refresh.
Replace the three atoi() calls with isc_parse_uint8 /
isc_parse_uint16, which uniformly reject overflow, trailing
garbage, leading sign, and non-numeric input across libc
implementations. As a side effect, error messages now include
the offending argument and a specific reason ("out of range" vs
"not a valid number").
Assisted-by: Claude:claude-opus-4-7
(cherry picked from commit e13302a6bc)
Apply assorted cleanups to `bin/tests/system/resend_loop/ans3/ans.py`.
Backport of MR !12063
Merge branch 'backport-michal/resend_loop-test-ans3-cleanup-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12071
Make the handlers defined in bin/tests/system/resend_loop/ans3/ans.py
follow canonical naming conventions used in other system tests. Keep
all server initialization code in the main() function.
(cherry picked from commit c5a30a7220)
Since the _get_cookie() function is only used by the CookieHandler
class, make the former a method of the latter to keep related logic
close in the source code.
(cherry picked from commit c3839e830c)
The "len(cookie.server) == 0" condition is superfluous for the
"resend_loop" system test, so remove it. Add a return type annotation
to the _get_cookie() function.
(cherry picked from commit 5fa2bd7e53)
dnspython 2.7.0 is now required to run the BIND 9 system test suite.
Drop the workarounds for older dnspython versions as they are now
redundant.
(cherry picked from commit c9ceb191e8)
The "yield" keyword does not cause a function to return. By design,
get_responses() may yield multiple DNS responses in a single call. As
currently implemented, CookieHandler.get_responses() sends two responses
to each client query that does not contain a COOKIE option. Make the
logic in that method consistent with code comments by only sending one
response to every query - either SERVFAIL or BADCOOKIE, never both.
(cherry picked from commit de42425bbd)
The ans3 custom server instance is created with default_aa=True. Do not
pass the authoritative=True keyword argument to the DnsResponseSend
constructor in CookieHandler.get_responses() as it is redundant.
(cherry picked from commit c61539279d)
The ans3 custom server does not have any zones defined, so the responses
passed to its handlers by core isctest.asyncserver code are guaranteed
to be empty. Remove a call to qctx.prepare_new_response() from
CookieHandler.get_responses() as it is redundant.
(cherry picked from commit 802c03313f)
The NoErrorHandler class does not get matched to any query sent by ns4
in the "resend_loop" test. Remove it as it is redundant.
(cherry picked from commit a296bcf587)
The CookieHandler class handles all traffic for the "example." domain.
Make it a subclass of DomainHandler to simplify its definition.
(cherry picked from commit ba6eee2b80)
- Rewrite cherry-pick references during autorebases
- Fix autorebase error reporting
- Limit post-push pipelines for autorebased branches
- Only autorebase when there is anything to rebase
- Conflate missing commit reference notifications
- Support autorebasing backported security MRs
Backport of MR !12024
Merge branch 'backport-michal/autorebase-improvements-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!12069
Autorebasing a backported security fix enables convenient refreshing of
cherry-pick references, which makes it trivial for developers to satisfy
Danger rules just before the merge request is merged. Add a manual CI
job that is only created for backported merge requests targeting
security-* branches.
(cherry picked from commit dd723d93cb)
Instead of creating a separate (potentially lengthy) Danger notification
for every missing commit reference in a backport, produce a single
notification with a list of all unreferenced commit hashes. This makes
Danger output more concise while retaining all the relevant feedback for
the developer.
(cherry picked from commit 086780dcf0)
In an optimistic future, security-* branches will become empty, at least
intermittently. When that happens, there will be nothing left to rebase
on those branches, so when something gets merged into their base
branches, an autorebase will effectively be a fast-forward. While the
existing autorebase logic would handle such a case perfectly fine, it is
prudent to avoid creating a test pipeline after pushing such a
fast-forward update as the code revision getting pushed will have
already been tested by other pipelines. However, the push should still
happen as non-empty downstream autorebased branches may exist and those
will still need to be rebased. Achieve both of these objectives by
checking early whether there is anything to rebase and pushing the
fast-forwarded version of the branch without setting the AUTOREBASE CI
variable if there is not.
(cherry picked from commit 497f771ae3)
Current CI job triggering rules cause a full pipeline to be started
after every push to security-* branches. In this context, "push" means
"branch update", which covers both "git push" invocations and merging a
merge request. Meanwhile, running a test pipeline is only desired after
a rebase; if a branch is fast-forwarded, it means that a merge request
has been merged into it and a pipeline should have already been run for
that merge request itself. Limit resource use by only triggering
pipelines for security-* branches when they are pushed to with a "magic"
CI variable that is only set in autorebase jobs. Leave all the other
triggering rules (for scheduled/manual pipelines) intact.
(cherry picked from commit 5cd870053e)
The logic used for detecting the commit breaking an autorebase does not
work correctly if the offending commit is not the first one applied
during the "reverse rebase". Fix by using REBASE_HEAD instead of
processing the output of "git status" in a convoluted way.
Furthermore, the approach used for identifying the first offending merge
request in the case of a successful autorebase followed by a failed
build only works correctly if the base branch is not autorebased itself.
Since a solution that would work correctly for a branch autorebased on
top of a branch that only moves forward does not work correctly for a
branch autorebased on top of another autorebased branch and vice versa,
accurately identifying the most likely culprit after a successful
autorebase is a very complicated and brittle task. Since reporting no
details at all is arguably better than reporting false details, only
produce a minimal error notification if the build fails after a
successful autorebase.
(cherry picked from commit 4c0e93108e)
Use a custom rebasing script instead of "git rebase" to enable rewriting
cherry-pick references during autorebases.
(cherry picked from commit 98c3f339bf)
