dns_rdata_fromstruct in dns_keytable_deletekey can potentially
fail with ISC_R_NOSPACE. Handle the error condition.
(cherry picked from commit b5df9b8591)
In selfsigned_dnskey only call dns_dnssec_verify if the signature's
key id matches a revoked key, the trust is pending and the key
matches a trust anchor. Previously named was calling dns_dnssec_verify
unconditionally resulted in busy work.
(cherry picked from commit e68fecbdaa)
Remove the reference to setting the DF-flag as we don't do that right
now. Rephrase the paragraph that the default value should not be
causing fragmentation.
(cherry picked from commit 61f276d5a4)
The doc file doc/dnssec-guide/validation.rst points to a resolver test
site that is now down. Remove the dead link.
(cherry picked from commit 8e78f8fc0f)
"Unstable" Debian "bullseye" unit and system jobs differ from unit and
system jobs on the Debian "bullseye" image by running a few more tests
enabled by the CI_ENABLE_ALL_TESTS environmental variable. These tests
are no less stable than the rest, and thus to have distinct jobs for
them wastes resources.
Run "unstable" unit and system tests as part of stock Debian "bullseye"
jobs.
(cherry picked from commit 2b9111b435)
amd64cross32 jobs run a cross-compiled 32-bit BIND 9 on the 64-bit
platform. This approach brings no build issues, and it is a good way to
catch 32-bit issues in BIND 9 code-base and ensure cross-compilation
keeps working.
Unfortunately, running unit and system tests is a problem:
- #3269 - doth-ns1 frequently failed to start
- #3316 - quota_test sometimes fails to create new thread
- #3956 - tcp-ns1 sometimes fails to allocate memory
There's little value in running unit and system tests on the
amd64cross32 platform, and it only means the effort spent by QA by
looking into what turns out to be 32-bit limitations.
(cherry picked from commit f86d4f3bd8)
Depending upon when the directory is sampled there may be 2
(oldest version removed and rename / reopen is in progresss) or
3 old versions of the log file.
(cherry picked from commit f485bb19c0)
due to comparing logfile suffixes as 32 bit rather than 64 bit
integers, logfiles with timestamp suffixes that should have been
removed when rolling could be left in place. this has been fixed.
(cherry picked from commit 9a9e906306)
the logfileconfig system test did not conform to the style of
other tests, and was difficult to read and maintain. it has
been cleaned up and simplifeid in several ways:
- named.args used when appropriate so that named can be started with
specified command line arguments, instead of having it launched
directly from tests.sh
- unused root zone removed from named configuration
- an existing directory used instead of using 'mkdir' to create one
- dnssec-validation disabled to stop the server sending unnecessary
queries
incidental fix: removed leftover debugging printfs from logconf.c.
(manually picked from commit 76baed3343)
Git clean in GitLab CI can take up to a thousand lines, thus cluttering
the output for no good reason.
The default GitLab GIT_CLEAN_FLAGS variable is extended with "q" as in
"quiet.
(cherry picked from commit ddb33a12fc)
The serve-stale system test was intermittently failing due to a timing
issue:
I:serve-stale:check stale data.example TXT was refreshed...
I:serve-stale:failed
The RRset is refreshed, however, it first checks for an expected log
line, prior checking that the stale data.example TXT was refreshed
(using dig). This log line is there to ensure the record is actually
refreshed before we start querying again. Alternatively we could just
retry_quiet 10 <wait for dig output matches expectations>. It would
lower the chances for intermittent test failures, since there is no
longer a "check for log line, sleep one second if check fails, check
for log line, ...", prior to the check.
(cherry picked from commit 0bf36da305)
Avoid creating any temporary files in the current workdir.
Additional/changing files in the bin/tests/system directory are
problematic for pytest/xdist collection phase, which assumes the list of
files doesn't change between the collection phase of the main pytest
thread and the subsequent collection phase of the xdist worker threads.
Since the testcrypto.sh is also called during pytest initialization
through conf.sh.common (to detect feature support), this could
occasionally cause a race condition when the list of files would be
different for the main pytest thread and the xdist worker.
(cherry picked from commit 61330a7863)
Previously, an AXFR request would be issued every second while waiting
for the zone to be signed. This might've been the cause of issues in CI
where many tests are running in parallel and any extra load may increase
test instability.
Instead, check for the last NSEC record to have a signature before
commencing the AXFR request to check the zone has been fully signed.
Also increase the time for the zone signing to a total of 60+10 seconds
up from the previous 30.
(cherry picked from commit 3291c891f6)
There's no point in continuing the dupsigs test if a failure is
detected. End the test early to avoid wasting time and resources.
(cherry picked from commit ad647dca13)
Ensure messages from dupsigs system test end up in its log rather than
stdout. Previously, the output was hard to debug when running the tests
in parallel and messages wouldn't end up in the dupsigs.log.
(cherry picked from commit cbe2559f37)
In v9.16, the number of expected signatures for the fully signed dupsigs
zone is 1009 rather than 1008, since there is one extra DNSKEY
signature. The test itself checks for the correct number, but the
barrier which waits for the zone to be fully signed doesn't.
In practice, this had the effect of always waiting the full 30 seconds
for the zone to be signed. Afterwards, the wait barrier would fail.
However, the return code isn't handled, so the test would proceed and
succeed anyway, since 30 seconds was enough time for the zone to get
fully signed.
This issue was introduced during a backport in commit
4840d6f9c9.
