RSASHA1 and RSASHA1-NSEC-SHA1 DNSKEY algorithms have been deprecated
by the IETF and should no longer be used for DNSSEC. DS digest type
1 (SHA1) has also been deprecated. Validators are now expected
to treat these algorithms and digest as unknown, resulting in
some zones being treated as insecure when they were previously treated
as secure. Warnings have been added to named and tools when these
algorithms and this digest are being used for signing.
Zones signed with RSASHA1 or RSASHA1-NSEC-SHA1 should be migrated
to a different DNSKEY algorithm.
Zones with DS or CDS records with digest type 1 (SHA1) should be
updated to use a different digest type (e.g. SHA256) and the digest
type 1 records should be removed.
Related to #5358
Backport of MR !10559
Merge branch 'backport-5358-add-sha1-deprecation-warnings-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10738
DNSKEY algorithms RSASHA1 and RSASHA-NSEC3-SHA1 and DS digest type
SHA1 are deprecated. Log when these are present in primary zone
files and when generating new DNSKEYs, DS and CDS records.
(cherry picked from commit cb6903c55e)
Replace the custom DNS server used in the "tsig" system test with
new code based on the isctest.asyncserver module.
Changes to isctest.asyncserver are required, previously it did not
handle TSIG signed queries at all. Now, with some hacking around
a [dnspython bug](https://github.com/rthalley/dnspython/issues/1205) it does.
Backport of MR !10566
Merge branch 'backport-stepan/tsig-asyncserver-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10732
Replace the custom DNS server used in the "tsig" system test with
new code based on the isctest.asyncserver module.
(cherry picked from commit e34e831cab)
Previously, upon receiving a query with TSIG, the server would log
an error and timeout. As there is no way to set up the keyring in the
class anyway (and I believe we don't need it), this commit lets such
queries parse but logs the fact that the query has TSIG.
However, there is a bug [1] in dnspython, which causes `make_response`
and `to_wire` to crash on messages constructed by `from_wire` with
`keyring=False`, so the hack with `message.__class__` is needed to work
around this.
This makes just enough changes for the tsig system test to work with
dnspython >= 2.0.0. On older version the server gives up.
[1] https://github.com/rthalley/dnspython/issues/1205
(cherry picked from commit 72ac1fe234)
The ADB memory cleaning is opportunistic even when we are under
memory pressure (in the overmem condition). Split the opportunistic
LRU cleaning and overmem cleaning and make the overmem cleaning
always cleanup double of the newly allocated adbname/adbentry to
ensure we never allocate more memory than the assigned limit.
Backport of MR !10637
Merge branch 'backport-ondrej/enforce-memory-cleanup-in-ADB-when-overmem-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10707
The purge_stale_names()/purge_stale_entries() is opportunistic even when
we are under memory pressure (overmem). Split the opportunistic LRU
cleaning and overmem cleaning. This makes the stale purging much
simpler as we don't have to try that hard and makes the overmem cleaning
always cleanup double the amount of the newly allocated ADB name/entry.
(cherry picked from commit eb0ffa0d5f)
When used with the ``+keepopen`` option with a TCP connection, iscman:`dig`
could terminate unexpectedly in rare situations. Additionally, iscman:`dig`
could hang and fail to shutdown properly when interrupted during a query.
These have been fixed.
Closes#5381
Backport of MR !10681
Merge branch 'backport-5381-dig-keepalive-crash-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10727
When send_done() is called with a ISC_R_CANCELED status (e.g. because
of a signal from ctrl+c), dig can fail to shutdown because
check_if_done() is not called in the branch. Add a check_if_done()
call.
(cherry picked from commit 5d1a8fe755)
When reusing a TCP connection (because of the '+keepopen' option),
dig detaches from the query after launching it. This can cause a
crash in dig in rare cases when the "receive" callback is called
earlier than the "send" callback.
The '_cancel_lookup()' function detaches a query only if it's
found in the 'lookup->q' list. Before this commit, with one
additional detach happening before recv_done() -> _cancel_lookup()
is called, it didn't cause problems because an earlier _query_detach()
was unlinking the query from 'lookup->q' (because it was the last
reference), so the additional detach and the skipped detach were
undoing each other.
That is unless the "receive" callback was called earlier than the
"send" callback, in which case the additional detach wasn't destroying
the query (and wasn't unlinking it from 'lookup->q') because the "send"
callback's attachment was still there, and so _cancel_lookup() was
trying to "steal" the "send" callback's attachment and causing an
assertion on 'INSIST(query->sendhandle == NULL);'.
Delete the detachment which caused the described situation.
(cherry picked from commit a2685696aa)
Responses which were dropped or slipped because of RRL (Response Rate
Limiting) were logged in the ``rate-limit`` category instead of the
``query-errors`` category, as documented in ARM. This has been fixed.
Closes#5388
Backport of MR !10676
Merge branch 'backport-5388-rrl-log-category-fix-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10725
As mentioned in the comments block before the changed code block,
the dropped or slipped responses should be logged in the query
category (or rather query-errors category as done in lib/ns/client.c),
so that requests are not silently lost.
Also fix a couple of errors/typos in the code comments.
(cherry picked from commit 27e7961479)
A query for a zone that was not yet loaded may yield an unexpected result such as a CNAME or DNAME, triggering an assertion failure. This has been fixed.
Closes#5357
Backport of MR !10562
Merge branch 'backport-5357-resume-qmin-cname-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10718
Print optionally a bit more details not passed to event in case
dns_view_findzonecut returns unexpected result. Result would be
visible later in foundevent, but found fname would be lost. Print it
into the log.
(cherry picked from commit d2c6966232)
When authoritative zone is loaded when query minimization query for the
same zone is already pending, it might receive unexpected result codes.
Normally DNS_R_CNAME would follow to query_cname after processing sent
events, but dns_view_findzonecut does not fill CNAME target into
event->foundevent. Usual lookup via query_lookup would always have that
filled.
Ideally we would restart the query with unmodified search name, if
unexpected change from recursing to local zone cut were detected. Until
dns_view_findzonecut is modified to export zone/cache source of the cut,
at least fail queries which went into unexpected state.
(cherry picked from commit 2fd3da54f9)
System tests' after_script missed the PYTHON environmental variable
setup.
Backport of MR !10683
Merge branch 'backport-mnowak/fix-parse_tsan-invocation-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10710
Tweak various system test which have been unstable in the past weeks.
Closes#5406
Backport of MR !10690
Merge branch 'backport-nicki/improve-system-test-stability-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10703
The code which checks for both IPv4 and IPv6 mixed usage is inherently
unstable, since the address family is chosen randomly for each
connection.
Closes#5406
(cherry picked from commit b98660e93e)
It's possible to use pytest.mark.flaky, which achieves the exact same
thing as our custom-defined isctest.mark.flaky -- attempts to rerun the
test on failure, but only is flaky package is available.
(cherry picked from commit 4c487c811d)
The test_kasp_case[secondary.kasp] can sometimes fail on freebsd13. It
appears the test gets stuck on some operation which should be very
quick, but for some reason takes at least a few seconds, causing the
cb_ixfr_is_signed() function to time out.
In one of the cases I investigated, it wasn't a query/response that
caused a timeout, but rather some operation in between. The test
attempts to read from a keyfile/statefile, but I see no reason why that
should block.
In any case, try to increase the timeout for the verification, as that
shouldn't hurt. Also allow the test to be re-run on freebsd13, as it's
likely to be caused by some odd behaviour on that platform -- the issue
doesn't appear anywhere else.
(cherry picked from commit 126a59cef2)
The check "unix socket message counts" sometimes fails with "dnstap
output file smaller than expected". This only happens on freebsd13 and
can't be reproduced easily. There was an attempt to decrease the
required file size in the past, but apparently, the issue can still
occur.
(cherry picked from commit 34867e1693)
The serve_stale test has some inherent instabilities affecting many
different checks. While the failure rate isn't too high (about four
failures in past three weeks of nightlies), it gets ignored, because the
test has been unstable for a very long time.
(cherry picked from commit 1e0df480c7)
This removes a leftover check which should've been removed in a prior
change (see #5244). The softhsm2 failures when attempting to delete the
token should be ignored.
(cherry picked from commit 6755d741e4)
The enginepkcs11 test has been chronically unstable for quite a while.
With no fix in sight, increase the number of allowed re-runs to reduce
the number of failures we see in the CI.
(cherry picked from commit 87ab198b73)
These tests have been unstable under TSAN in the past, but it appears
that the same failure mode can happen outside of TSAN tests as well.
These tests have produced 12 failures combined in the past three weeks
in nightlies.
(cherry picked from commit 66f6f4bba9)
The fetchlimit test has failed 8 times in the nightly CI over the past
three weeks. That makes the overall failure rate somewhere around 1 %,
which isn't a lot, but is still annoying when lots of testing is going
on.
(cherry picked from commit ae932eefc5)
Rndc test "test 'rndc reconfig' with a broken config" was failing
intermittently.
Wait for 'running' to be logged rather than just using 'sleep 1' before
calling 'rndc reconfig' a second time to get the expected error message
rather than 'reconfig request ignored: already running'.
Closes#5408
Backport of MR !10687
Merge branch 'backport-5408-rndc-test-second-rndc-reconfig-happens-too-soon-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10700
Rndc test "test 'rndc reconfig' with a broken config" was failing
intermittently.
Wait for 'running' to be logged rather than just using 'sleep 1' before
calling 'rndc reconfig' a second time to get the expected error message
rather than 'reconfig request ignored: already running'.
(cherry picked from commit 8b7bbda2f1)
There are three adbname flags that are used to identify different
types of adbname lookups when hashing rather than using multiple
hash tables. Separate these to their own structure element as these
need to be able to be read without locking the adbname structure.
Closes#5404
Backport of MR !10677
Merge branch 'backport-5404-seperate-out-adbname-type-flags-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10695
There are three adbname flags that are used to identify different
types of adbname lookups when hashing rather than using multiple
hash tables. Separate these to their own structure element as these
need to be able to be read without locking the adbname structure.
(cherry picked from commit 9158e63218)
There are many system tests where we set `dnssec-validation yes;` only
to also set `trust-anchors { };` which effectively disables the
validation.
This MR replaces this convoluted setup with just `dnssec-validation no;`.
Backport of MR !10684
Merge branch 'backport-stepan/empty-trust-anchors-in-system-tests-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10698
There are many system tests where we set `dnssec-validation yes;` only
to also set `trust-anchors { };` which effectively disables the
validation.
This commit replaces this convoluted setup with just
`dnssec-validation no;`.
(cherry picked from commit 01d1ad7988)
On MRs it uses the merge target as the reference.
In schedules it uses the latest released version for this branch as the reference.
This MR lays the ground work for using respdiff on non-standard configurations (like ECS) in the public repo, see https://gitlab.isc.org/isc-private/bind9/-/merge_requests/807#note_573140.
To reduce the future hassle when maintaining the -S version, most of the work (including an added job, so we know that it actually works) is done here.
Backport of MR !10664
Merge branch 'backport-stepan/respdiff-against-merge-target-or-last-release-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10696
On MRs it uses the merge target as the reference.
In schedules it uses the latest released version for this branch as the
reference.
(cherry picked from commit 9a6e8b9190)
