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:02 +0000 (18:15 +0200)]
[9.16] 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.16' into 'bind-9.16'
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.
Ondřej Surý [Wed, 6 May 2026 08:12:35 +0000 (10:12 +0200)]
Pass empty string instead of NULL to ns_client_dumpmessage()
The two new call sites added by the CLASS-validation work passed NULL
as the reason, but ns_client_dumpmessage() bails out early on a NULL
reason — so the message dump never happened. The intent was to dump
the message and let the follow-up ns_client_log() carry the reason
text, so pass "" to suppress the prefix without short-circuiting the
dump.
Ondřej Surý [Wed, 6 May 2026 07:33:37 +0000 (09:33 +0200)]
[9.16] [CVE-2026-5946] sec: usr: Disable recursion, UPDATE, and NOTIFY for non-IN views
Recursion, dynamic updates (UPDATE), and zone change notifications
(NOTIFY) are now disabled for views with a class other than IN
(such as CHAOS or HESIOD); authoritative service for non-IN zones
(e.g. version.bind in class CHAOS) continues to work as before.
Servers configured with recursion yes in a non-IN view will log a
warning at startup, and named-checkconf flags the same condition.
UPDATE and NOTIFY messages that specify the meta-classes ANY or NONE
in the question section are now rejected with FORMERR.
This addresses a set of closely related security issues collectively
identified as CVE-2026-5946. ISC would like to thank Mcsky23 for
bringing these issues to our attention.
Backport of https://gitlab.isc.org/isc-private/bind9/-/merge_requests/936
Merge branch 'each-security-disable-chaos-recursion-security-bind-9.16' into 'security-bind-9.16'
Evan Hunt [Tue, 17 Mar 2026 20:24:43 +0000 (13:24 -0700)]
Skip "deny-answer-address" for non-IN addresses
Ensure that we don't attempt an ACL match for answer addresses
when handling a class-CHAOS zone. This is an additional line of
defense for YWH-PGM40640-74.
Mark Andrews [Tue, 3 Mar 2026 23:00:56 +0000 (10:00 +1100)]
Reject meta-classes in UPDATE and NOTIFY messages
NOTIFY and UPDATE messages must specify a data class in the
QUESTION/ZONE section. NONE and ANY are meta-classes and not
appropriate here. Return FORMERR if either is used.
Rejecting messages with a query class of NONE addresses YWH-PGM40640-72,
YWH-PGM40640-82, and YWH-PGM40640-83. Rejecting messages with a query
class of ANY addresses YWH-PGM40640-87, YWH-PGM40640-88, and
YWH-PGM40640-117.
Ondřej Surý [Wed, 4 Mar 2026 09:46:58 +0000 (10:46 +0100)]
Validate DNS message CLASS early in request processing
Reject requests with unsupported or misused CLASS values before
further processing. Only IN, CH, HS, RESERVED0 (for DNS Cookies),
ANY (for TKEY negotiation), and NONE (for DNS UPDATE) are accepted;
all other classes return NOTIMP. Misuse of NONE or ANY outside
their allowed contexts returns FORMERR.
This adds further protection against bugs of the same general class
as YWH-PGM40640-70 and YWH-PGM40640-73.
Evan Hunt [Wed, 4 Mar 2026 21:24:52 +0000 (13:24 -0800)]
Disable UPDATE and NOTIFY for non-IN classes
Return NOTIMP for UPDATE and NOTIFY requests received for views with a
class other than IN. Only QUERY is now supported for non-IN views such
as CHAOS.
When running dns dns_rdata_tostruct() with types that are only defined
for class IN, ensure that the class is correct before proceeding.
Add an assertion that any zone being updated is of class IN. (Note
that previously, a DLZ zone could have its class value set incorrectly
to NONE; this has been fixed.)
This addresses YWH-PGM40640-70 and YWH-PGM40640-73 (as well as any
similar problems that might have occurred in the future) by minimizing
the code paths that can be reached by rdata classes other than IN, so it
is safe for the implementation to assume that rdatatypes that are only
defined for class IN, such as SVCB or WKS, have been parsed and
validated, and not accepted as unknown/opaque data.
Evan Hunt [Tue, 3 Mar 2026 22:00:38 +0000 (14:00 -0800)]
Disable recursion for non-IN classes
Force recursion off, and set allow-recursion/allow-recursion-on ACLs
to none, for views with a class other than IN. Log a configuration
warning if recursion is explicitly enabled for a non-IN view.
This addresses YWH-PGM40640-74 and YWH-PGM40640-75 by preventing any
attempt at recursive processing in a class-CHAOS view, ensuring that
server addresses used for recursive queries and received in recursive
responses are of the expected format.
Fixed a memory leak where each GSS-API TKEY negotiation leaked a security context inside the GSS library. An unauthenticated attacker could exhaust server memory by sending repeated TKEY queries to a server with tkey-gssapi-keytab configured. The leaked memory was allocated by the GSS library, bypassing BIND's memory accounting.
Multi-round GSS-API negotiation (GSS_S_CONTINUE_NEEDED) is now rejected, as BIND never supported it correctly and Kerberos/SPNEGO completes in a single round.
Also implemented missing RFC 3645 requirement: the client now verifies that mutual authentication and integrity flags are granted by the GSS-API mechanism (Section 3.1.1).
Closes: https://gitlab.isc.org/isc-projects/bind9/-/issues/5752
Backport of !965
Merge branch 'backport-5752-fix-memory-leak-in-TKEY-negotiation-9.16' into 'security-bind-9.16'
Fix output token and GSS context leaks in TKEY/GSS-API error paths
In dst_gssapi_acceptctx(), rename outtoken to outtokenp (matching BIND
convention for output pointer parameters) and free the allocated output
token buffer on error in the cleanup path.
In process_gsstkey(), route the empty-principal error path through
cleanup via CLEANUP() instead of returning early, so that the output
token, GSS context, and TSIG key are all freed consistently by the
existing cleanup block.
Ondřej Surý [Tue, 17 Mar 2026 23:10:35 +0000 (00:10 +0100)]
Fix GSS-API context leak in TKEY negotiation
Reject multi-round GSS-API negotiation (GSS_S_CONTINUE_NEEDED) in
dst_gssapi_acceptctx(). Each call to gss_accept_sec_context()
allocates a context inside the GSS library; without this fix, the
context handle was passed back to process_gsstkey() which did not
store it persistently, leaking it on every incomplete negotiation.
An unauthenticated attacker could exhaust server memory by sending
repeated TKEY queries with GSSAPI tokens, each leaking one GSS
context. The leaked memory is allocated by the GSS library via
malloc(), bypassing BIND's memory accounting.
In practice, Kerberos/SPNEGO (the only mechanism used with BIND)
completes in a single round, so rejecting continuation does not
affect real-world deployments. See RFC 3645 Section 4.1.3.
Colin Vidal [Thu, 30 Apr 2026 18:49:41 +0000 (20:49 +0200)]
[9.16] [CVE-2026-3592] sec: usr: Limit resolver server list size
When resolving a domain with many nameservers that share overlapping IP addresses (e.g., 10 NS records all pointing at the same set of addresses), BIND could previously waste time querying duplicate addresses and build up excessively large server lists. Deduplicate addresses in the resolver's server list so that each unique IP is only queried once per resolution attempt, regardless of how many NS records point to it and cap the number of addresses stored per nameserver name to 6 (combined A and AAAA), preventing memory and CPU overhead from domains with unusually large NS/glue sets.
Closes isc-projects/bind9#5641
Backport of !909
Merge branch 'backport-5641-selfpointedglue-9.16' into 'security-bind-9.16'
Colin Vidal [Wed, 4 Feb 2026 09:18:42 +0000 (10:18 +0100)]
Remove duplicate addresses from the resolver SLIST
The SLIST (essentially `fctx->finds`, forwarders and dual-stack
alternatives aside) can have duplicate server addresses when multiple
in-domain nameservers share the same IP addresses:
sub.example. NS ns1.sub.example.
sub.example. NS ns2.sub.example.
ns1.sub.example. A 1.2.3.4
ns1.sub.example. A 5.6.7.8
ns2.sub.example. A 1.2.3.4
ns2.sub.example. A 5.6.7.8
If both 1.2.3.4 and 5.6.7.8 fail to return a valid answer, the resolver
would query each address twice.
The problem is fixed by replacing the two-phase server selection (sort
each find list by SRTT, sort finds by head SRTT) with a single linear
scan in nextaddress() that finds the lowest-SRTT unmarked, non-duplicate
address across all find lists.
The old approach had a correctness bug: after sorting, the resolver
picked the next address from the "current" find list rather than
globally. For example, with find lists [1, 15, 26] and [3, 4, 5], the
second pick would be SRTT 15 instead of the correct SRTT 3.
The new approach is both simpler and correct: each call to nextaddress()
walks all addresses, skips marked and duplicate entries, and returns the
one with the lowest SRTT. While this walk is repeated for each server
attempt, it operates on a small bounded list and is negligible compared
to the network I/O of querying the server.
Colin Vidal [Thu, 5 Feb 2026 08:46:01 +0000 (09:46 +0100)]
Limit the number of addresses returned per ADB find
Add a hard limit on the number of addresses that ADB returns from a
single NS lookup (dns_adbfind_t). This mitigates a flood attack
where an attacker controls a zone with many addresses for a
nameserver, each returning an invalid response. The global
max-query count (default 50) also limits this, but significant harm
can be done before that limit is reached.
The default limit is now 6 (v4 and/or v6) addresses for an ADB find (so,
ADB looking up for A/AAAA addresses of a name server name).
A bug during bad server handling could cause the resolver to enter an infinite loop, continuously sending queries to an upstream server with no exit condition, until the resolver query timeout was hit. This has been fixed.
ISC would like to thank Billy Baraja (BielraX) for bringing this issue to our attention.
Closes isc-projects/bind9#5804
Backport of !985
Merge branch 'backport-5804-resend-loop-9.16' into 'security-bind-9.16'
Colin Vidal [Tue, 7 Apr 2026 20:18:58 +0000 (22:18 +0200)]
rctx_resend() increment query counters
Calls to `rctx_resend()` are done internally within the resolver, in
flow which are not supposed to happens more than once. For instance,
if some query fails, and a specific flag "F" wasn't set, then set the
flag and try again. This wouldn't occur more than once because if the
query fails the next attempt, the flag "F" would be set already, so the
resolver would move to the next server (or give up).
However, a subtle bug missing checking a flag, for instance, could lead
to an unbounded loop re-trying to query the same server. This is now
impossible as `rctx_resend()` also increment the query counters (so if
such case occurs, it would stop once the maximum limit is reached).
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.16' into 'bind-9.16'
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.
Michał Kępień [Wed, 25 Mar 2026 09:15:37 +0000 (10:15 +0100)]
[9.16] [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.16' into 'bind-9.16-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:45:05 +0000 (18:45 +0200)]
[9.16] [CVE-2025-40780] sec: usr: Cache-poisoning due to weak pseudo-random number generator
It was discovered during research for an upcoming academic paper that a
xoshiro128\*\* internal state can be recovered by an external 3rd party,
allowing the prediction of UDP ports and DNS IDs in outgoing queries.
This could lead to an attacker spoofing the DNS answers with great
efficiency and poisoning the DNS cache.
The internal random generator has been changed to a cryptographically
secure pseudo-random generator.
ISC would like to thank Prof. Amit Klein and Omer Ben Simhon from Hebrew
University of Jerusalem for bringing this vulnerability to our
attention.
Backport of !831
Closes isc-projects/bind9#5484
Merge branch '5484-security-make-isc_random-csprng-9.16' into 'bind-9.16-release'
Ondřej Surý [Tue, 19 Aug 2025 17:22:18 +0000 (19:22 +0200)]
Use cryptographically-secure pseudo-random generator everywhere
It was discovered in an upcoming academic paper that a xoshiro128**
internal state can be recovered by an external 3rd party allowing to
predict UDP ports and DNS IDs in the outgoing queries. This could lead
to an attacker spoofing the DNS answers with great efficiency and
poisoning the DNS cache.
Change the internal random generator to system CSPRNG with buffering to
avoid excessive syscalls.
Thanks Omer Ben Simhon and Amit Klein of Hebrew University of Jerusalem
for responsibly reporting this to us. Very cool research!
Michał Kępień [Wed, 22 Oct 2025 16:41:51 +0000 (18:41 +0200)]
[9.16] [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.16' into 'bind-9.16-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 [Wed, 1 Oct 2025 08:36:49 +0000 (10:36 +0200)]
Drop gcc:sid:amd64 jobs
They fail to build with GCC 15.2.0:
rdata/in_1/wks_11.c: In function 'totext_in_wks':
rdata/in_1/wks_11.c:238:77: error: '%u' directive output may be truncated writing between 1 and 10 bytes into a region of size 6 [-Werror=format-truncation=]
238 | snprintf(buf, sizeof(buf), "%u",
| ^~
rdata/in_1/wks_11.c:238:76: note: directive argument in the range [1, 4294967295]
238 | snprintf(buf, sizeof(buf), "%u",
| ^~~~
rdata/in_1/wks_11.c:238:49: note: 'snprintf' output between 2 and 11 bytes into a destination of size 6
238 | snprintf(buf, sizeof(buf), "%u",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
239 | i * 8 + j);
| ~~~~~~~~~~
nolibtool:sid:amd64 keeps building, so keep it.
Move -O3 and --without-lmdb to gcc:noble:amd64.
Move RUN_MAKE_INSTALL=1 to gcc:trixie:amd64 as Sphinx is needed to build
man pages that are checked for in util/check-make-install.
Petr Špaček [Wed, 28 May 2025 13:46:14 +0000 (15:46 +0200)]
Run CI danger job even if user canceled it while it was running
Limitation: The after_script is not executed if the job did not start at
all, i.e. if the user canceled the job before it got onto a runner.
See https://gitlab.com/groups/gitlab-org/-/epics/10158
[9.16] [9.18] fix: dev: Unify the int32_t vs int_fast32_t when working with atomic types
There's a mismatch between the atomic and non-atomic types that could
potentialy lead to a rwlock deadlock (after two billion 2^32) writes.
Use int_fast32_t when loading the atomic_int_fast32_t types in the
isc_rwlock unit.
Closes #5280
Backport of MR !10390
Merge branch 'backport-5280-match-the-types-in-isc_rwlock-9.18-9.16' into 'bind-9.16'
Unify the int32_t vs int_fast32_t when working with atomic types
There's a mismatch between the atomic and non-atomic types that could
potentialy lead to a rwlock deadlock (after two billion 2^32) writes.
Use int_fast32_t when loading the atomic_int_fast32_t types in the
isc_rwlock unit.
[9.16] 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.16' into 'bind-9.16'
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 12:42:59 +0000 (12:42 +0000)]
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.
Merge branch 'mnowak/drop-bsd-images-from-ci' into 'bind-9.16'
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:37:54 +0000 (09:37 +0000)]
[9.16] 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.16' into 'bind-9.16'
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.
projects / thirdparty / bind9.git / log
