In a previous change, the "algorithm" value passed to
dns_tsigkey_create() was changed from a DNS name to an integer;
the name was then chosen from a table of known algorithms. A
side effect of this change was that a query using an unknown TSIG
algorithm was no longer handled correctly, and could trigger an
assertion failure. This has been corrected.
The dns_tsigkey struct now stores the signing algorithm
as dst_algorithm_t value 'alg' instead of as a dns_name,
but retains an 'algname' field, which is used only when the
algorithm is DST_ALG_UNKNOWN. This allows the name of the
unrecognized algorithm name to be returned in a BADKEY
response.
(cherry picked from commit decf461d68846d6754c1f64790c3f9006d158a1d)
`dig` was producing invalid YAML when displaying some EDNS options. This has been corrected.
Several other improvements have been made to the display of EDNS option data:
- We now use the correct name for the UPDATE-LEASE option, which was previously displayed as "UL", and split it into separate LEASE and LEASE-KEY components in YAML mode.
- Human-readable durations are now displayed as comments in YAML mode so as not to interfere with machine parsing.
- KEY-TAG options are now displayed as an array of integers in YAML mode.
- EDNS COOKIE options are displayed as separate CLIENT and SERVER components, and cookie STATUS is a retrievable variable in YAML mode.
Closes#5014
Backport of MR !9695
Merge branch 'backport-5014-improve-edns-yaml-processing-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10414
The test description "checking delv -c CH is ignored, and
treated like IN" in digdelv was garbled.
(cherry picked from commit 5424b30d7a4ac748c1ae548c323483a60c2c3b31)
Check that when an EDNS CLIENT-TAG or EDNS SERVER-TAG option is
present in the message, the emitted YAML is valid.
(cherry picked from commit 2efb15b54ad483ec2d7c4206d462730e38718e4b)
Check that when an EDNS EXPIRE option is present in the message,
the emitted YAML is valid.
(cherry picked from commit e611e2044a5a79308edbe6257166411973210e45)
Check that when there is an EDNS CLIENT-SUBNET option in the
message, the emitted YAML is valid.
(cherry picked from commit 641ca9044f7f05ed28704f43cefedd933b1c00ff)
Split the YAML display of the EDNS COOKIE option into CLIENT and SERVER
parts. The STATUS of the EDNS COOKIE in the reply is now a YAML element
rather than a comment.
(cherry picked from commit 5eeb31f0b9f630fc130d3876aad3eaa4c4ef8dee)
The EDNS LLQ option was not being emitted as valid YAML. Correct
the output to be valid YAML with each field of the LLQ being
individually selectable.
(cherry picked from commit 81334113c39d419528e540dcf94f0046544f6edb)
When using YAML, print the EDNS KEY-TAG as an array of integers
for easier machine parsing. Check the validity of the YAML output.
(cherry picked from commit 27e8732c1726aebc43d41e39b115d0c7eda5bb77)
This will allow the values to be parsed using standard yaml processing
tools, and still provide the value in a human friendly form.
(cherry picked from commit 378bc7cfa69c5f1d58551896e8aeb95e5acccd0c)
The offical EDNS option name for "UL" is "UPDATE-LEASE". We now
emit "UPDATE-LEASE" instead of "UL", when printing messages, but
"UL" has been retained as an alias on the command line.
Update leases consist of 1 or 2 values, LEASE and KEY-LEASE. These
components are now emitted separately so they can be easily extracted
from YAML output. Tests have been added to check YAML correctness.
(cherry picked from commit 68cdc4774c53fb439ebb0dca4e6fc98ba69577d5)
When rendering text, such as domain names or the EXTRA-TEXT
field of the EDE option, backslashes and quotation marks must
be escaped to ensure that the emitted message is valid YAML.
(cherry picked from commit 280e9b7cf4b28bffa6a281bb64b43e35829645ec)
The CHAIN and REPORT-CHANNEL EDNS options are both domain names, so they
can be combined. THE CLIENT-TAG and SERVER-TAG EDNS options are both 16
bit integers, so they can be combined.
(cherry picked from commit e7ef4e41ebd55ed1cfb2b2652b66a0f026aea1c7)
some EDNS option names, including DAU, DHU, N3U, and CHAIN,
were not printed in dns_message_pseudosectiontotext() or
_psuedosectiontoyaml(); they were displayed as unknown options.
this has been corrected.
that code was also refactored to use switch instead of if/else,
and to look up the option code names in a table to prevent
inconsistencies between the two formats. one such inconsistency
was corrected: the "TCP-KEEPALIVE" option is now always printed
with a hyphen, instead of being "TCP KEEPALIVE" when not using
YAML. the keepalive system test has been updated to expect this.
EDNS options that print DNS names (i.e., CHAIN and Report-Channel)
now enclose them in quotation marks to ensure YAML correctness.
the auth system test has been updated to expect this when grepping
for Report-Channel options.
(cherry picked from commit e2393ba27bd334fb2146e1540c0dafcc75e9d688)
Report-Channel and ZONEVERSION EDNS options can now be sent
using `dig +ednsopt=report-channel` (or `dig +ednsopt=rc` for
short), and `dig +ednsopt=zoneversion`.
(cherry picked from commit c30754f28b82cec4467c05452aae62ab56198830)
The performance improvements for NSEC3 closest encloser lookups that
were restored in BIND 9.20.8 turned out to cause incorrect NSEC3 records
to be returned in nonexistence proofs and were therefore reverted again.
Closes#5292
Merge branch '5292-revert-nsec3-closest-encloser-lookup-improvements' into 'bind-9.20'
See merge request isc-projects/bind9!10443
Some domains tested by linkchecker may think that we connect to them too
often and will refuse connection or reply with an error code, which makes
this job fail. Let's check links only on Wednesdays.
Backport of MR !10439
Merge branch 'backport-mnowak/run-linkchecker-only-sometimes-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10440
Some domains tested by linkchecker may think that we connect to them too
often and will refuse connection or reply with and error code, which
makes this job fail. Let's check links only on Wednesdays.
(cherry picked from commit f745a9212a3cb5d938a418a294955886d90e268c)
The check fails with the following error for some time:
broken https://www.gnu.org/software/libidn/#libidn2 - HTTPSConnectionPool(host='www.gnu.org', port=443): Max retries exceeded with url: /software/libidn/ (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f5bd4c14590>: Failed to establish a new connection: [Errno 111] Connection refused'))
Backport of MR !10436
Merge branch 'backport-mnowak/linkcheck-disable-www-gnu-org-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10437
The check fails with the following error for some time:
broken https://www.gnu.org/software/libidn/#libidn2 - HTTPSConnectionPool(host='www.gnu.org', port=443): Max retries exceeded with url: /software/libidn/ (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f5bd4c14590>: Failed to establish a new connection: [Errno 111] Connection refused'))
(cherry picked from commit 0ea4ebf7d1bcf37c5e7e28b12a69212b434856dd)
The two-tone ksr subtest (test_ksr_twotone) depended on the dnssec-policy keys algorithm values in named.conf being entered in numerical order. As the algorithms used in the test can be selected randomly this does not always happen. Sort the dnssec-policy keys by algorithm when adding them to the key list from named.conf.
Closes#5286
Backport of MR !10395
Merge branch 'backport-5286-ksr-two-tone-test-only-work-by-luck-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10435
Extract each section of the bundle and check that the expected
records are there. The old code was assuming that the records in
each section where in a particular order which didn't happen in
practice.
(cherry picked from commit 92a50dab28f28b3aa1f72a8ab2c7cb61597b6b64)
These tests do not easily fit in the standard test case framework, so they go into their own suite.
- zsk retired case
- checkds cases
- reload/restart
- inheritance tests
Backport of MR !10278
Merge branch 'backport-matthijs-pytest-rewrite-kasp-system-test-4-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10424
These tests ensure that if dnssec-policy is set on a higher level, the
zone is still signed (or unsigned) as expected. Or if a higher level
has an override, the new policy is honored as expected.
(cherry picked from commit 2e4cc706267d08a515adaca1f1bb863600a4e938)
This test checks that the SOA SERIAL and TTL are adjusted correctly
after a reload/restart.
(cherry picked from commit bff7453e50b38ce1adf556beac2dcb1a80665f6b)
This converts the checkds test cases that deal with the 'rndc checkds'
command and setting the 'DSPublish' and 'DSRemoved' metadata.
(cherry picked from commit 44b4d5ebd66163b97b3ba0a08e01b8d99523a58e)
This test case does not easily fit in the standard test case framework,
so it goes into its own suite.
(cherry picked from commit 1940aa1d0b4a1c3b5820a1513bccee74bc53d6f1)
Over the past few years, some of the initial decisions made about which
GitLab CI jobs to run for all merge requests and which of them to run
just for scheduled/web-triggered pipelines turned out to be less than
ideal in practice: test coverage was found to be too lax in some areas
and on the other hand unnecessarily repetitive in others. For example,
compilation failures for certain build types that are not exercised for
every merge request (e.g. FIPS-enabled builds) turned out to be much
more common in practice than e.g. test failures happening only on a
subset of releases of a given Linux distribution.
To limit excessive resource use while retaining broad test coverage,
adjust GitLab CI job triggering rules for merge request pipelines as
follows:
- run all possible build jobs for every merge request; compilation
failures triggered for build flavors that were only tested in
scheduled pipelines turned out to be surprisingly commonplace and
became a nuisance over time, particularly given that the run times
of build jobs are much lower than those of test jobs,
- for every merge request, run at least one system & unit test job for
each build flavor (e.g. sanitizer-enabled, FIPS-enabled,
out-of-tree, tarball-based, etc.),
- limit the amount of test jobs run for each distinct operating
system; for example, only run system & unit test jobs for Ubuntu
24.04 Noble Numbat in merge request pipelines, skipping those for
Ubuntu 22.04 Jammy Jellyfish and Ubuntu 20.04 Focal Fossa (while
still running them in other pipeline types, e.g. in scheduled
pipelines),
- ensure every merge request is tested on Oracle Linux 8, which is the
operating system with the oldest package versions out of the systems
that are still supported by this BIND 9 branch,
- decrease the number of test jobs run with sanitizers enabled while
still testing with both ASAN and TSAN and both GCC and Clang for
every merge request.
These changes do not affect the set of jobs created for any other
pipeline type (triggered by a schedule, by a GitLab API call, by the web
interface, etc.); only merge request pipelines are affected.
Backport of MR !10349
Merge branch 'backport-michal/revise-ci-job-triggering-rules-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10430
Over the past few years, some of the initial decisions made about which
GitLab CI jobs to run for all merge requests and which of them to run
just for scheduled/web-triggered pipelines turned out to be less than
ideal in practice: test coverage was found to be too lax in some areas
and on the other hand unnecessarily repetitive in others. For example,
compilation failures for certain build types that are not exercised for
every merge request (e.g. FIPS-enabled builds) turned out to be much
more common in practice than e.g. test failures happening only on a
subset of releases of a given Linux distribution.
To limit excessive resource use while retaining broad test coverage,
adjust GitLab CI job triggering rules for merge request pipelines as
follows:
- run all possible build jobs for every merge request; compilation
failures triggered for build flavors that were only tested in
scheduled pipelines turned out to be surprisingly commonplace and
became a nuisance over time, particularly given that the run times
of build jobs are much lower than those of test jobs,
- for every merge request, run at least one system & unit test job for
each build flavor (e.g. sanitizer-enabled, FIPS-enabled,
out-of-tree, tarball-based, etc.),
- limit the amount of test jobs run for each distinct operating
system; for example, only run system & unit test jobs for Ubuntu
24.04 Noble Numbat in merge request pipelines, skipping those for
Ubuntu 22.04 Jammy Jellyfish and Ubuntu 20.04 Focal Fossa (while
still running them in other pipeline types, e.g. in scheduled
pipelines),
- ensure every merge request is tested on Oracle Linux 8, which is the
operating system with the oldest package versions out of the systems
that are still supported by this BIND 9 branch,
- decrease the number of test jobs run with sanitizers enabled while
still testing with both ASAN and TSAN and both GCC and Clang for
every merge request.
These changes do not affect the set of jobs created for any other
pipeline type (triggered by a schedule, by a GitLab API call, by the web
interface, etc.); only merge request pipelines are affected.
(cherry picked from commit 4ad8c86cf2ba6e60f60fe7b0f60eb7d3bd3718b6)
With the ongoing process of moving CI workloads to AWS, OpenBSD poses a
challenge, as there is no OpenBSD AMI image in the AWS catalog. Building
our image from scratch is disproportionately complicated, given that
OpenBSD is not a common deployment platform for BIND 9. Otherwise,
OpenBSD stays at the "Best-Effort" level of support.
Backport of MR !10375
Merge branch 'backport-mnowak/drop-openbsd-from-ci-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10428
With the ongoing process of moving CI workloads to AWS, OpenBSD poses a
challenge, as there is no OpenBSD AMI image in the AWS catalog. Building
our image from scratch is disproportionately complicated, given that
OpenBSD is not a common deployment platform for BIND 9. Otherwise,
OpenBSD stays at the "Best-Effort" level of support.
(cherry picked from commit 0dc9b4573d98eb6c0d623f27288d548889e3a46c)
Write python-based tests for the many test cases from the kasp system test with the same pattern.
Backport of MR !10268
Merge branch 'backport-matthijs-pytest-rewrite-kasp-system-test-3-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10421
Make use of pytest.mark.parametrize to split up the many default kasp
test cases into separate tests.
(cherry picked from commit 7d670b7fe73619330132075c6fe8ad23520c0de9)
For 'keystore.kasp', a setting 'key-directories' is used. If set, this
will expect a list of two directories, the first one is where the KSKs
will be stored, the second in the list is the ZSK key directory. This
may be expanded in the future to test more complex key storage cases.
The 'rumoured.kasp' zone is weird, the key timings can never match
those key states. But it is a regression test for an early day bug,
so we convert it, but skip the expected key times check.
(cherry picked from commit ee7120eb34c889d571cca15ec1a3fb068e6e7545)
These test cases follow the same pattern as many other, but all require
some additional checks. These are set in "additional-tests".
The "zsk-missing.autosign" zone is special handled, as it expects the
KSK to sign the SOA RRset (because the ZSK is unavailable).
The kasp/ns3/setup.sh script is updated so the SyncPublish is not set
(named will initialize it correctly). For the test zones that have
missing private key files we do need to set the expected key timing
metadata.
Remove the counterparts for the newly added test from the kasp shell
tests script.
(cherry picked from commit 5f23f750c24ea734e52798276bbeb270cec2aed2)
The check_signatures code was initially created to be suitable for
the ksr system test, to test the Offline KSK feature. For that, a
key is expected to be signing if the current time is between
the timing metadata Active and Retired.
With dnssec-policy, the key timing metadata is indicative, the key
states determine the actual signing behavior.
Update the check_signatures function so that by default the signing
is derived from the key states (ksigning and zsigning). Add an
argument 'offline_ksk', if set the make sure that the zsigning is set
if the current time is between the Active and Retired timing metadata,
and for ksigning we just use the timing metadata (as the key is offline,
we cannot check the key states).
Another (upcoming) test case is where key files are missing. When the
ZSK private key file is missing, the KSK takes over. Add an argument
'zsk_missing', when set to True the expected zone signing (zsigning)
is reversed.
(cherry picked from commit fddf9f778b49f454e68cbefea8c897ac3bd0ea44)
The zone 'pregenerated.kasp' is a case where there already exist more
keys than required. For this we set the 'pregenerated' setting. This
will change the 'keydir_to_keylist' function behavior: Only keys in use
are considered. A key is in use if all of the states are either
undefined, or set to 'hidden'.
The 'some-keys.kasp' zone is similar to 'pregenerated.kasp', except
only some keys have been pregenerated.
(cherry picked from commit 43ded45ae9af1b5ad93a68444ac289574ae703a2)
Write python-based tests for the many test cases from the kasp system
test. These test cases all follow the same pattern:
- Wait until the zone is signed.
- Check the keys from the key-directory against expected properties.
- Set the expected key timings derived from when the key was created.
- Check the key timing metadata against expected timings.
- Check the 'rndc dnssec -status' output.
- Check the apex is signed correctly.
- Check a subdomain is signed correctly.
- Verify that the zone is DNSSEC correct.
Remove the counterparts for the newly added test from the kasp shell
tests script.
(cherry picked from commit 41481af1446ad3b0e319214b3ceee8805fd67e72)
When ``stale-answer-client-timeout 0`` option was enabled, it could be ignored
when resolving a zone which is a delegation of an authoritative zone belonging
to the resolver. This has been fixed.
Closes#5275
Backport of MR !10381
Merge branch 'backport-5275-stale-answer-client-timeout-0-and-delegation-fix-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10420
Add a new test which gets an answer for a delegated zone, then
checks whether the 'stale-answer-client-timeout 0' mode (i.e. the
'stalefirst' mode) works for it.
(cherry picked from commit 441b7d53f4c023f891f7404130b191bb575501c2)
When 'stale-answer-client-timeout' is 0, named is allowed to return
a stale answer immediately, while also initiating a new query to get
the real answer. This mode is activated in ns__query_start() by setting
the 'qctx->options.stalefirst' optoin to 'true' before calling the
query_lookup() function, but not when the zone is known to be
authoritative to the server. When the zone is authoritative, and
query_looup() finds out that the requested name is a delegation,
then before proceeding with the query, named tries to look it up
in the cache first. Here comes the issue that it doesn't consider
enabling 'qctx->options.stalefirst' in this case, and so the
'stale-answer-client-timeout 0' setting doesn't work for those
delegated zones - instead of immediately returning the stale answer
(if it exists), named tries to resolve it.
Fix this issue by enabling 'qctx->options.stalefirst' in the
query_zone_delegation() function just before named looks up the name
in the cache using a new query_lookup() call. Also, if nothing was
found in the cache, don't initiate another query_lookup() from inside
query_notfound(), and let query_notfound() do its work, i.e. it will
call query_delegation() for further processing.
(cherry picked from commit 412aa881f2ce0e9d07b9ab46d2d4863ba388b898)
With `dnssec-policy` you can pregenerate keys and if they are eligible, rather than creating a new key, a key is selected from the pregenerated keys. A key is eligible if it is unused, i.e it has no key timing metadata set.
Backport of MR !10385
Merge branch 'backport-matthijs-clarify-pregenerating-keys-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10388
With dnssec-policy you can pregenerate keys and if they are eligible,
rather than creating a new key, a key is selected from the pregenerated
keys. A key is eligible if it is unused, i.e it has no key timing
metadata set.
(cherry picked from commit 9880bfff63d853629afb85394a65dd4eaf9f90b0)
Apple broke custom memory allocation functions in the system-wide libxml2 starting with macOS Sequoia 15.4. Usage of the custom memory allocation functions has been disabled on macOS.
Closes#5268
Backport of MR !10374
Merge branch 'backport-5268-disable-libxml2-memory-management-on-macos-9.20' into 'bind-9.20'
See merge request isc-projects/bind9!10411
