When processing a query with the "checking disabled" bit set (CD=1), `named` stores the unvalidated result in the cache, marked "pending". When the same query is sent with CD=0, the cached data is validated, and either accepted as an answer, or ejected from the cache as invalid. This deferred validation was not attempted for DS and DNSKEY records if they had no cached signatures, causing spurious validation failures. We now complete the deferred validation in this scenario.
Also, if deferred validation fails, we now re-query the data to find out whether the zone has been corrected since the invalid data was cached.
Closes#5066
Backport of MR !10104
Merge branch 'backport-5066-fix-strip-dnssec-rrsigs-9.18' into 'bind-9.18'
See merge request isc-projects/bind9!10106
If a deferred validation on data that was originally queried with
CD=1 fails, we now repeat the query, since the zone data may have
changed in the meantime.
(cherry picked from commit 04b1484ed8)
When a query is made with CD=1, we store the result in the
cache marked pending so that it can be validated later, at
which time it will either be accepted as an answer or removed
from the cache as invalid. Deferred validation was not
attempted when there were no cached RRSIGs for DNSKEY and
DS. We now complete the deferred validation in this scenario.
(cherry picked from commit 8b900d1808)
The text that stale-cache-enable is set to no has no effect on
max-cache-ttl, but on max-stale-ttl.
Closes#5181
Backport of MR !10108
Merge branch 'backport-5181-max-stale-ttl-typo-arm-9.18' into 'bind-9.18'
See merge request isc-projects/bind9!10116
Views use two types of reference counting - regular and weak, and
when there are no more regular references, the `view_flushanddetach()`
function destroys or detaches some parts of the view, including
`view->zonetable`, while other parts are freed by `destroy()` when
the last weak reference is detached. Since catalog zones use weak
references to attach a view, it's currently possible that during
shutdown catalog zone processing will try to add a new zone into
an otherwise unused view (because it's shutting down) which doesn't
have an attached zonetable any more. This could cause an assertion
failure. Fix this issue by modifying the `dns_view_addzone()` function
to expect that `view->zonetable` can be `NULL`, and in that case just
return `ISC_R_SHUTTINGDOWN`.
Closes#5138
Merge branch '5138-fix-dns_view_addzone-race-9.18' into 'bind-9.18'
See merge request isc-projects/bind9!10086
Views use two types of reference counting - regular and weak, and
when there are no more regular references, the view_flushanddetach()
function destroys or detaches some parts of the view, including
'view->zonetable', while other parts are freed by destroy() when
the last weak reference is detached. Since catalog zones use weak
references to attach a view, it's currently possible that during
shutdown catalog zone processing will try to add a new zone into
an otherwise unused view (because it's shutting down) which doesn't
have an attached zonetable any more. This could cause an assertion
failure. Fix this issue by modifying the dns_view_addzone() function
to expect that 'view->zonetable' can be NULL, and in that case just
return ISC_R_SHUTTINGDOWN.
An incorrect optimization caused "CNAME and other data" errors not to be detected if certain types were at the same node as a CNAME. This has been fixed.
Closes#5150
Backport of MR !10033
Merge branch 'backport-5150-cname-and-other-data-check-not-applied-to-all-types-9.18' into 'bind-9.18'
See merge request isc-projects/bind9!10101
prio_type was being used in the wrong place to optimize cname_and_other.
We have to first exclude and accepted types and we also have to
determine that the record exists before we can check if we are at
a point where a later CNAME cannot appear.
(cherry picked from commit 5e49a9e4ae)
This is a complement to the already present system test "stress" test.
Backport of MR !9474
Merge branch 'backport-mnowak/generate-tsan-unit-stress-tests-9.18' into 'bind-9.18'
See merge request isc-projects/bind9!10095
GitLab CI Runner's $builds_dir variable is set to "/builds" by default.
For technical reasons, the FreeBSD Runners, using the "instance"
executor, sets the path differently.
The value of $CI_PROJECT_DIR is based on $builds_dir, so if the
generate-stress-test-configs.py script generates jobs with
$CI_PROJECT_DIR (or variables like $INSTALL_PATH that are based on it)
evaluated, it is calcified to whatever was the value in the particular
environment, disregarding the FreeBSD "instance" executor specifics in
the child pipeline.
Instead of evaluating $CI_PROJECT_DIR in the script, evaluate it in the
runtime environment.
Backport of MR !10075
Merge branch 'backport-mnowak/fix-CI_PROJECT_DIR-variable-evaluation-9.18' into 'bind-9.18'
See merge request isc-projects/bind9!10078
GitLab CI Runner's $builds_dir variable is set to "/builds" by default.
For technical reasons, the FreeBSD Runners, using the "instance"
executor, sets the path differently.
The value of $CI_PROJECT_DIR is based on $builds_dir, so if the
generate-stress-test-configs.py script generates jobs with
$CI_PROJECT_DIR (or variables like $INSTALL_PATH that are based on it)
evaluated, it is calcified to whatever was the value in the particular
environment, disregarding the FreeBSD "instance" executor specifics in
the child pipeline.
Instead of evaluating $CI_PROJECT_DIR in the script, evaluate it in the
runtime environment.
(cherry picked from commit dab7d28b09)
Print the expiration time of the stale RRsets in the cache dump.
Backport of MR !10057
Merge branch 'backport-ondrej/print-expiration-time-of-stale-records-9.18' into 'bind-9.18'
See merge request isc-projects/bind9!10062
In #1870, the expiration time of ANCIENT records were printed, but
actually the ancient records are very short lived, and the information
carries a little value.
Instead of printing the expiration of ANCIENT records, print the
expiration time of STALE records.
The ANS servers were not to written to handle NS queries at the QNAME, resulting in gratuitous protocol errors that will break tests when NS requests are made for the QNAME: i.e., NXDOMAIN for NS vs data for expected type, CNAME not being returned for all query types.
Prerequisite for !9155Closes#5062
Backport of MR !9786
Merge branch 'backport-5062-fix-ans-servers-ns-at-qname-9.18' into 'bind-9.18'
See merge request isc-projects/bind9!10065
The ANS servers were not to written to handle NS queries at the
QNAME resulting in gratuitious protocol errors that will break tests
when NS requests are made for the QNAME.
(cherry picked from commit 0680eb6f64)
Under rare circumstances, the RRSet that expired at the time of
the query could be returned with TTL far in the future. This
has been fixed.
As a side-effect, the expiration time of expired RRSets are no
longer printed out in the cache dump.
Closes#5094
Backport of MR !10048
Merge branch 'backport-5094-fix-timestamp-in-ttl-9.18' into 'bind-9.18'
See merge request isc-projects/bind9!10060
When the mark_header_ancient() helper function was introduced, couple of
places with duplicate (or almost duplicate) code was missed. Add
missing set_ttl() calls before mark_header_ancient(), so the handling of
expiring headers is same in all places.
(concept cherry picked from commit 58179e6a19)
If we know that the header has ZEROTTL set, the server should never send
stale records for it and the TTL should never be anything else than 0.
The comment was already there, but the code was not matching the
comment.
(cherry picked from commit cfee6aa565)
When the header has been marked as ANCIENT, but the ttl hasn't been
reset (this happens in couple of places), the rdataset TTL would be
set to the header timestamp instead to a reasonable TTL value.
Since this header has been already expired (ANCIENT is set), set the
rdataset TTL to 0 and don't reuse this field to print the expiration
time when dumping the cache. Instead of printing the time, we now
just print 'expired (awaiting cleanup'.
(cherry picked from commit 1bbb57f81b)
The search for the deepest known zone cut in the cache could improperly reject a node if it contained any stale data, regardless of whether it was the NS RRset that was stale.
Closes#5155
Backport of MR !10047
Merge branch 'backport-5155-fix-findzonecut-9.18' into 'bind-9.18'
See merge request isc-projects/bind9!10051
the search for the deepest known zone cut in the cache could
improperly reject a node containing stale data, even if the
NS rdataset wasn't the data that was stale.
this change also improves the efficiency of the search by
stopping it when both NS and RRSIG(NS) have been found.
(cherry picked from commit 1f095b902c)
Backport of MR !10029
Backport of MR !10042
Merge branch 'backport-pspacek/no-cross-project-after-merge-jobs-9.18' into 'bind-9.18'
See merge request isc-projects/bind9!10044
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.
(cherry picked from commit 6014060774)
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.18' into 'bind-9.18'
See merge request isc-projects/bind9!10038
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.
(cherry picked from commit e39e7afc16)
Clean up the pattern in the newref() and decref() functions in RBTDB databases.
Related to #5134
Backport of MR !10006
Merge branch 'backport-5134-refactor-decref-functions-in-qpdb-9.18' into 'bind-9.18'
See merge request isc-projects/bind9!10036
Change the names of the node reference counting functions
and add comments to make the mechanism easier to understand:
- new_reference() and decrement_references() are now called
dns__rbtnode_acquire() and dns__rbtnode_release()
respectively; this reflects the fact that they modify both
the internal and external reference counters for a node.
- rbtnode_newref() and rbtnode_decref are now called
rbtnode_erefs_increment() and rbtnode_erefs_decrement(),
to reflect that they only increase and decrease the node's
external reference counters, not internal.
(cherry picked from commit 857225aeb6)
Refactor the pattern in the newref() and decref() functions in rbtdb.c
following the pattern, so it follows the similar pattern we already have
for QPDB.
(cherry picked from commit 9c45de9473)
From https://gitlab.isc.org/isc-projects/bind9/-/issues/5087, the relevant MRs have been merged in the January 2025 release. Hence this MR removes `allow_failure: true` in CI.
Backport of MR !10026
Merge branch 'backport-andoni/remove-allow-failure-in-cross-version-config-tests-9.18' into 'bind-9.18'
See merge request isc-projects/bind9!10028
Remove `allow_failure: true` from .gitlab-ci.yaml, as the relevant
MRs have been merged in the January 2025 release.
(cherry picked from commit 5d07df807a)
:option:`rndc flushname` did not work for name server names longer
than 16 bytes. This has been fixed.
Closes#3885
Merge branch '3885-fix-rndc-flushname-for-longer-name-server-names' into 'bind-9.18'
See merge request isc-projects/bind9!10025
dns_adb_flushname() calls dns_name_hash() to determine the ADB bucket
number to search for the given name. Meanwhile, all other functions in
lib/dns/adb.c call dns_name_fullhash() for determining the bucket number
instead. This discrepancy causes dns_adb_flushname() to have virtually
no chances of actually removing the given name from the ADB if the
name is longer than 16 bytes (since dns_name_hash() only hashes the
first 16 bytes of the name provided to it) - more specifically, the
probability of success for names longer than 16 bytes is inversely
proportional to the number of ADB buckets in use, i.e. 1:1021 at best.
Fix by using dns_name_fullhash() instead of dns_name_hash() in
dns_adb_flushname(), so that the logic for determining the bucket number
that a given name belongs to is consistent throughout lib/dns/adb.c.
Mark Andrews
Michal Nowak
Matthijs Mekking
Arаm Sаrgsyаn
Petr Špaček
Petr MenšíkandPetr Špaček
Andoni Duarte
Ondřej Surý
Michał Kępień