Michal Nowak [Wed, 25 Mar 2026 12:31:49 +0000 (13:31 +0100)]
Set RUNNER_SCRIPT_TIMEOUTs
Sometimes jobs can get stuck and be terminated by GitLab, leaving us
without artefacts that could contain useful information about why the
job got stuck.
Michał Kępień [Thu, 7 May 2026 16:15:05 +0000 (18:15 +0200)]
[9.11] chg: ci: Mark merged security fixes as "Not released yet"
Adjust the triggering rules for the "merged-metadata" CI job so that
merge requests merged into security-* branches are automatically
assigned to the "Not released yet" milestone, just like merge requests
targeting public branches. This enables merge requests containing
security fixes to be correctly processed by release automation scripts.
Backport of MR !11984
Merge branch 'backport-pspacek/extend-not-released-yet-milestone-9.11' into 'bind-9.11'
Petr Špaček [Tue, 5 May 2026 13:04:36 +0000 (15:04 +0200)]
Mark merged security fixes as "Not released yet"
Adjust the triggering rules for the "merged-metadata" CI job so that
merge requests merged into security-* branches are automatically
assigned to the "Not released yet" milestone, just like merge requests
targeting public branches. This enables merge requests containing
security fixes to be correctly processed by release automation scripts.
When processing a catalog zone member's primaries definition and
there is a TXT record containing an invalid name TSIG key name,
dns_name_free was incorrectly called triggering an assertion.
This has been fixed.
Closes #5858
Backport of MR !11832
Merge branch 'backport-5858-remove-unnecessary-dns-name-free-call-9.11' into 'bind-9.11'
Mark Andrews [Fri, 10 Apr 2026 03:07:26 +0000 (13:07 +1000)]
Remove unnecessary dns_name_free call
When processing a catalog zone member's primaries definition and
there is a TXT record containing an invalid name TSIG key name,
dns_name_free was incorrectly called triggering an assertion.
This has been fixed.
[9.11] fix: dev: Fix buffer overflow in check_zoneconf
The following line caused a buffer overflow due to `tmp` and `len` having the wrong values:
```
(void)snprintf(tmp, len, "%u/%s", zclass,
(ztype == CFG_ZONE_INVIEW) ? target :
(viewname != NULL) ? viewname : "_default");
```
Merge branch 'matthijs-fix-buffer-overflow' into 'bind-9.11'
Michał Kępień [Wed, 25 Mar 2026 09:16:02 +0000 (10:16 +0100)]
[9.11] [CVE-2026-1519] sec: usr: Fix unbounded NSEC3 iterations when validating referrals to unsigned delegations
DNSSEC-signed zones may contain high iteration-count NSEC3 records,
which prove that certain delegations are insecure. Previously, a
validating resolver encountering such a delegation processed these
iterations up to the number given, which could be a maximum of 65,535.
This has been addressed by introducing a processing limit, set at 150.
Now, if such an NSEC3 record is encountered, the delegation will be
treated as insecure.
ISC would like to thank Samy Medjahed/Ap4sh for bringing this
vulnerability to our attention.
Closes isc-projects/bind9#5708
Backport of MR !935
Merge branch '5708-confidential-nsec3-delegation-iteration-fix-fallback-to-insecure-9.11' into 'bind-9.11-release'
In many places we only create a validator if the RRset has too low
trust (the RRset is pending validation, or could not be validated
before). This check was missing prior to validating negative response
data.
When looking up an NSEC3 as part of an insecurity proof, check the
number of iterations. If this is too high, treat the answer as insecure
by marking the answer with trust level "answer", indicating that they
did not validate, but could be cached as insecure.
Nicki Křížek [Fri, 21 Nov 2025 14:05:36 +0000 (15:05 +0100)]
Increase the threshold for respdiff-third-party
There are multiple reasons for the increased amount of differences we've
been seeing lately and for the raise of the threshold:
1. Recent hardening against cache poisoning (CVE-2025-40778) have
uncovered a few edge cases where the domain can't be properly
resolved with the new protections in place, but those are issues with
upstream configuration and DNS setup.
2. The same hardening magnified some behaviour differences between 9.21
and older versions. Some misconfigured domains, which can be resolved
with BIND 9.20 and older are no longer resolvable in 9.21+. This can
be again attributed to upstream DNS misconfiguration. See #5649.
3. A change in the respdiff CI job to include timeouts in the
comparison, or rather, increasing the timeouts to resolve the
previously timed out queries, which are typically failures. With the
previous job configuration, those were omitted from comparison,
because they were timeouts. Now, there should be no timeouts, but
there is a slight increase in the amount of differences for the
threshold evaluation.
Michał Kępień [Wed, 22 Oct 2025 16:48:06 +0000 (18:48 +0200)]
[9.11] [CVE-2025-40778] sec: usr: Address various spoofing attacks
Previously, several issues could be exploited to poison a DNS cache with
spoofed records for zones which were not DNSSEC-signed or if the
resolver was configured to not do DNSSEC validation. These issues were
assigned CVE-2025-40778 and have now been fixed.
As an additional layer of protection, :iscman:`named` no longer accepts
DNAME records or extraneous NS records in the AUTHORITY section unless
these are received via spoofing-resistant transport (TCP, UDP with DNS
cookies, TSIG, or SIG(0)).
ISC would like to thank Yuxiao Wu, Yunyi Zhang, Baojun Liu, and Haixin
Duan from Tsinghua University for bringing this vulnerability to our
attention.
Backport of !838
Closes isc-projects/bind9#5414
Merge branch '5414-security-check-name-vs-qname-again-9.11' into 'bind-9.11-release'
To prevent spoofed unsigned DNAME responses being accepted retry
response with unsigned DNAMEs over TCP if the response is not TSIG
signed or there isn't a good DNS CLIENT COOKIE.
To prevent test failures, this required adding TCP support to the
ans3 and ans4 servers in the chain system test.
Further restrict addresses that are cached when processing referrals
Use the owner name of the NS record as the bailwick apex name
when determining which additional records to cache, rather than
the name of the delegating zone (or a parent thereof).
Tighten restrictions on caching NS RRsets in authority section
To prevent certain spoofing attacks, a new check has been added
to the existing rules for whether NS data can be cached: the owner
name of the NS RRset must be an ancestor of the name being queried.
Michal Nowak [Wed, 19 Mar 2025 13:02:32 +0000 (14:02 +0100)]
Set more lenient respdiff limits
After !9950, respdiff's maximal disagreement percentage needs to be
adjusted as target disagreements between the tested version of the
"main" branch and the reference one jumped for the respdiff,
respdiff:asan, and respdiff:tsan jobs from on average 0.07% to 0.16% and
from 0.12% to 0.17% for the respdiff-third-party job.
In !9950, we concluded setting MAX_DISAGREEMENTS_PERCENTAGE to double
the average disagreement percentage works fine in the CI.
Michal Nowak [Fri, 3 Oct 2025 11:21:36 +0000 (13:21 +0200)]
Allow further system test jobs to fail
The "coverage" and "keymgr" system tests have been reliably failing
under ASAN and in tarball-based GitLab CI jobs ever since commit 4467114191b2d60ab4c5fd16d6650b67c449ddef moved the relevant jobs to
Debian "bookworm". As the above tests work fine in other jobs, these
particular failures will not be investigated further.
[9.11] new: ci: Allow pushing branches and tags to customer git repos
For pipelines in the private repository, add an optional manual job,
which allows the current branch to be pushed into the specified
customer's git repository. This can be useful to provide patch previews
for early testing.
For tags created in a private repository, add a manual job which pushes
the created tag to all entitled customers.
Backport of MR !10323
Merge branch 'backport-nicki/ci-customer-git-automation-9.11' into 'bind-9.11'
Nicki Křížek [Tue, 25 Mar 2025 15:51:24 +0000 (16:51 +0100)]
Allow pushing branches and tags to customer git repos
For pipelines in the private repository, add an optional manual job,
which allows the current branch to be pushed into the specified
customer's git repository. This can be useful to provide patch previews
for early testing.
For tags created in a private repository, add a manual job which pushes
the created tag to all entitled customers.
Michal Nowak [Tue, 11 Mar 2025 13:12:46 +0000 (13:12 +0000)]
[9.11] Drop FreeBSD and OpenBSD from CI
Both FreeBSD and OpenBSD in the CI are tested on outdated images.
Current FreeBSD images can't even be rebuild because in the maintained
branches they were ported from QCOW2 to the AWS autoscaler (also a
future of the OpenBSD image). This is something we don't want to
backport to EoL branches.
Michal Nowak [Tue, 11 Mar 2025 09:56:18 +0000 (10:56 +0100)]
Drop FreeBSD and OpenBSD from CI
Both FreeBSD and OpenBSD in the CI are tested on outdated images.
Current FreeBSD images can't even be rebuild because in the maintained
branches they were ported from QCOW2 to the AWS autoscaler (also a
future of the OpenBSD image). This is something we don't want to
backport to EoL branches.
Petr Špaček [Thu, 30 Jan 2025 10:24:59 +0000 (11:24 +0100)]
Do not trigger post-merge jobs for cross-project pushes
We need to avoid double-triggering of post-merge jobs in the following
scenario:
1. A private MR gets merged into the private BIND 9 repository.
2. This merge operation triggers a "push" pipeline in the private
repository, which correctly runs post-merge jobs, e.g. to set MR
metadata in the private project.
3. When a release is published, a script is run to change the
automatically assigned milestone value ("Not released yet") to
something else.
4. Shortly afterwards, the result of the merge from step 1 is merged
back into a maintenance branch in the public repository.
5. The push operation triggers another "push" pipeline, this time in
the public project.
At this point there are two problems:
- If the script is dumb (like it currently is), it will extract the
merge request ID from the merge commit description and change the
milestone for a merge request in the wrong project namespace.
- Even if the script was fixed to extract and use the correct GitLab
project reference, it would reset the milestone for the merge
request in the private repository back to "Not released yet" - while
the milestone set in step 3 should be retained.
An alternative would be to change the order of operations so that
post-release milestoning happens at a later stage, while also fixing the
script to correctly follow cross-project references, but that approach
seems more fragile than simply failing on all cross-project pushes. The
rule to enforce is: each project should only take care of its own
post-merge tasks.
Michał Kępień [Fri, 31 Jan 2025 09:40:33 +0000 (09:40 +0000)]
[9.11] chg: ci: Use default cloning depth for the Danger CI job
With shallow fetching working reliably in pygit2 1.17.0+, there is no
longer any need for GitLab CI runners to clone the BIND 9 repository
with a fixed depth of 1000 during every "danger" CI job as Hazard is now
able to fetch remote refs with an arbitrary depth, controlled by the
HAZARD_FETCH_DEPTH environment variable. The latter can be defined via
GitLab project's CI settings and adjusted as needed over time, without
the need to update .gitlab-ci.yml every time its value needs to be
changed.
Backport of MR !9946
Merge branch 'backport-michal/use-default-cloning-depth-for-the-danger-ci-job-9.11' into 'bind-9.11'
Michał Kępień [Fri, 31 Jan 2025 09:25:56 +0000 (10:25 +0100)]
Use default cloning depth for the Danger CI job
With shallow fetching working reliably in pygit2 1.17.0+, there is no
longer any need for GitLab CI runners to clone the BIND 9 repository
with a fixed depth of 1000 during every "danger" CI job as Hazard is now
able to fetch remote refs with an arbitrary depth, controlled by the
HAZARD_FETCH_DEPTH environment variable. The latter can be defined via
GitLab project's CI settings and adjusted as needed over time, without
the need to update .gitlab-ci.yml every time its value needs to be
changed.
Nicki Křížek [Mon, 20 Jan 2025 16:17:36 +0000 (16:17 +0000)]
[9.11] [CVE-2024-11187] sec: usr: Limit the additional processing for large RDATA sets
When answering queries, don't add data to the additional section if the answer has more than 13 names in the RDATA. This limits the number of lookups into the database(s) during a single client query, reducing query processing load.
Backport of MR !750
See isc-projects/bind9#5034
Merge branch '5034-security-limit-additional-9.11' into 'bind-9.11-release'
Ondřej Surý [Thu, 19 Dec 2024 15:40:52 +0000 (16:40 +0100)]
Limit the additional processing for large RDATA sets
When answering queries, don't add data to the additional section if
the answer has more than 13 names in the RDATA. This limits the
number of lookups into the database(s) during a single client query,
reducing query processing load.
Also, don't append any additional data to type=ANY queries. The
answer to ANY is already big enough.
Ondřej Surý [Wed, 8 Jan 2025 15:46:48 +0000 (16:46 +0100)]
Isolate using the -T noaa flag only for part of the resolver test
Instead of running the whole resolver/ns4 server with -T noaa flag,
use it only for the part where it is actually needed. The -T noaa
could interfere with other parts of the test because the answers don't
have the authoritative-answer bit set, and we could have false
positives (or false negatives) in the test because the authoritative
server doesn't follow the DNS protocol for all the tests in the resolver
system test.
Petr Špaček [Mon, 5 Aug 2024 08:21:46 +0000 (10:21 +0200)]
Automatically adjust MR metadata after merge
1. Set milestone to 'Not released yet' after merge
We will set milestone to actual version number when we actually tag a
particular version. This will get rid of mass MR reassignment when we
do last minute changes to a release plan etc.
2. Adjust No CHANGES and Release Notes MR labels to match gitchangelog
workflow.
Ondřej Surý [Thu, 22 Aug 2024 09:32:16 +0000 (09:32 +0000)]
[9.11] new: usr: Tighten 'max-recursion-queries' and add 'max-query-restarts' option
There were cases in resolver.c when the `max-recursion-queries` quota was ineffective. It was possible to craft zones that would cause a resolver to waste resources by sending excessive queries while attempting to resolve a name. This has been addressed by correcting errors in the implementation of `max-recursion-queries`, and by reducing the default value from 100 to 32.
In addition, a new `max-query-restarts` option has been added which limits the number of times a recursive server will follow CNAME or DNAME records before terminating resolution. This was previously a hard-coded limit of 16, and now defaults to 11.
Closes #4741
Backport of MR !9281
Merge branch 'backport-4741-reclimit-restarts-9.11' into 'bind-9.11'
Evan Hunt [Wed, 26 Jun 2024 06:49:00 +0000 (23:49 -0700)]
implement 'max-query-restarts'
implement, document, and test the 'max-query-restarts' option
which specifies the query restart limit - the number of times
we can follow CNAMEs before terminating resolution.
Evan Hunt [Tue, 25 Jun 2024 21:30:20 +0000 (14:30 -0700)]
make "max_restarts" a configurable value
MAX_RESTARTS is no longer hard-coded; ns_server_setmaxrestarts()
and dns_client_setmaxrestarts() can now be used to modify the
max-restarts value at runtime. in both cases, the default is 11.
Evan Hunt [Tue, 25 Jun 2024 19:28:23 +0000 (12:28 -0700)]
reduce MAX_RESTARTS to 11
the number of steps that can be followed in a CNAME chain
before terminating the lookup has been reduced from 16 to 11.
(this is a hard-coded value, but will be made configurable later.)
Evan Hunt [Wed, 22 May 2024 20:02:16 +0000 (13:02 -0700)]
attach query counter to NS fetches
there were cases in resolver.c when queries for NS records were
started without passing a pointer to the parent fetch's query counter;
as a result, the max-recursion-queries quota for those queries started
counting from zero, instead of sharing the limit for the parent fetch,
making the quota ineffective in some cases.
Ondřej Surý [Thu, 15 Aug 2024 17:54:58 +0000 (19:54 +0200)]
For TSAN builds, use libraries from /opt/tsan
The new TSAN images, the TSAN-enabled images install libraries to
/opt/tsan, synchronize the configure options and CFLAGS between gcc:tsan
and clang:tsan images and set the PKG_CONFIG_PATH to /opt/tsan/lib.
Nicki Křížek [Mon, 5 Aug 2024 15:56:02 +0000 (15:56 +0000)]
[9.11] chg: Remove danger checks for release notes and CHANGES
Since 9.21.0-dev, the release notes and changelog process has been
changed. Backport to the EoL branch are no longer expected to have
either CHANGES or release notes, as we aren't going to release any more
versions anyway.
Related #75
Merge branch '75-gitchangelog-9.11' into 'bind-9.11'
Remove danger checks for release notes and CHANGES
Since 9.21.0-dev, the release notes and changelog process has been
changed. Backport to the EoL branch are no longer expected to have
either CHANGES or release notes, as we aren't going to release any more
versions anyway.
[9.11][CVE-2024-1737 (part 2)] Be smarter about refusing to add many RR types to the database
Add HTTPS, SVCB, SRV, PTR, NAPTR, DNSKEY and TXT records to the list of
the priority types that are put at the beginning of the slabheader list
for faster access and to avoid eviction when there are more types than
the max-types-per-name limit.
Ondřej Surý [Mon, 17 Jun 2024 09:40:40 +0000 (11:40 +0200)]
Be smarter about refusing to add many RR types to the database
Instead of outright refusing to add new RR types to the cache, be a bit
smarter:
1. If the new header type is in our priority list, we always add either
positive or negative entry at the beginning of the list.
2. If the new header type is negative entry, and we are over the limit,
we mark it as ancient immediately, so it gets evicted from the cache
as soon as possible.
3. Otherwise add the new header after the priority headers (or at the
head of the list).
4. If we are over the limit, evict the last entry on the normal header
list.
Ondřej Surý [Mon, 17 Jun 2024 09:40:40 +0000 (11:40 +0200)]
Expand the list of the priority types
Add HTTPS, SVCB, SRV, PTR, NAPTR, DNSKEY and TXT records to the list of
the priority types that are put at the beginning of the slabheader list
for faster access and to avoid eviction when there are more types than
the max-types-per-name limit.
[9.11][CVE-2024-1737] Add a limit to the number of RRs in RRSets
Previously, the number of RRs in the RRSets were internally unlimited.
As the data structure that holds the RRs is just a linked list, and
there are places where we just walk through all of the RRs, adding an
RRSet with huge number of RRs inside would slow down processing of said
RRSets.
The fix for end-of-life branches make the limit compile-time only for
simplicity and the limit can be changed at the compile time by adding
following define to CFLAGS:
-DDNS_RDATASET_MAX_RECORDS=<limit>
Backport of https://gitlab.isc.org/isc-private/bind9/-/merge_requests/698
See isc-projects/bind9#3405
Merge branch '3405-limit-the-number-of-resource-records-in-rrset-9.11' into 'bind-9.11'
Ondřej Surý [Wed, 29 May 2024 06:43:39 +0000 (08:43 +0200)]
Add a limit to the number of RR types for single name
Previously, the number of RR types for a single owner name was limited
only by the maximum number of the types (64k). As the data structure
that holds the RR types for the database node is just a linked list, and
there are places where we just walk through the whole list (again and
again), adding a large number of RR types for a single owner named with
would slow down processing of such name (database node).
Add a hard-coded limit (100) to cap the number of the RR types for a single
owner. The limit can be changed at the compile time by adding following
define to CFLAGS:
Ondřej Surý [Fri, 1 Mar 2024 07:26:07 +0000 (08:26 +0100)]
Add a limit to the number of RRs in RRSets
Previously, the number of RRs in the RRSets were internally unlimited.
As the data structure that holds the RRs is just a linked list, and
there are places where we just walk through all of the RRs, adding an
RRSet with huge number of RRs inside would slow down processing of said
RRSets.
The fix for end-of-life branches make the limit compile-time only for
simplicity and the limit can be changed at the compile time by adding
following define to CFLAGS:
Michał Kępień [Fri, 26 Apr 2024 16:43:07 +0000 (18:43 +0200)]
Update URLs and paths for the BIND 9 QA repository
Since the BIND 9 QA repository has been made public, adjust the relevant
URLs and paths used in .gitlab-ci.yml so that they work with the public
version of that repository.
Michał Kępień [Fri, 29 Mar 2024 07:27:49 +0000 (08:27 +0100)]
Do not check CHANGES in pre-release pipelines
Since pre-release testing is usually carried out for branches in which
CHANGES entries are intentionally malformed to prevent entry numbering
conflicts down the road, do not run the "changes" GitLab CI job in
pipelines that are triggered by a parent pipeline (which can currently
only be a pre-release testing pipeline) to prevent triggering job
failures that would be meaningless anyway.
projects / thirdparty / bind9.git / log
