When both input and output files are the same, it creates unnecesary
troubles in debugging issues with the JUnit files.
Keep the Pytest-generated file in the artifacts and output the checked
version as a new file.
Create a signed zone file that contains malformed ZSKs with colliding
key tags. The ZSKs don't represent valid ECDSA keys and will cause a
crypto failure when attempting to use them. Sign the zone with KSK, with
the exception of one record which is "signed" with the invalid ZSKs.
Check that the resolver aborts the DNSSEC verification after
encountering the first crypto failure, indicating malformed DNSKEY.
Closes#5343
Merge branch '5343-count-invalid-keys-into-validation-fails-test' into 'main'
See merge request isc-projects/bind9!11425
Ensure that named can handle a situation where the zone is signed with a
truncated, self-signed revoked DNSKEY. The signatures are inevitably
bogus and a SERVFAIL is expected. However, prior to CVE-2025-8677 fix,
this could trigger an assertion failure.
Create a signed zone file that contains malformed ZSKs with colliding
key tags. The ZSKs don't represent valid ECDSA keys and will cause a
crypto failure when attempting to use them. Sign the zone with KSK, with
the exception of one record which is "signed" with the invalid ZSKs.
Check that the resolver aborts the DNSSEC verification after
encountering the first crypto failure, indicating malformed DNSKEY.
In !11179 I mistakenly set the default for `default_aa` for
`AsyncDnsServer()` to `True` and then explicitly set it to True in
cases where all the `ResponseHandlers` said
`yield DnsResponseSend(..., authoritative=True)` as if the default was
`False`.
Also the rest of `AsyncDnsServer` code (namely `_prepare_responses`)
reads like `default_aa` is `False` by default.
This accidentally changed the behavior of servers which don't set the
`default_aa` and where AA is not set from the zone data
(e.g. `dispatch/ans3`).
Merge branch 'stepan/set-asyncdnsserver-dafault-aa-to-false-by-default' into 'main'
See merge request isc-projects/bind9!11419
In 6e684d44 I mistakenly set the default for `default_aa` for
`AsyncDnsServer()` to `True` and then explicitly set it to True in
cases where all the `ResponseHandlers` said
`yield DnsResponseSend(..., authoritative=True)` as if the default was
`False`.
Also the rest of `AsyncDnsServer` code (namely `_prepare_responses`)
reads like `default_aa` is `False` by default.
This accidentally changed the behavior of servers which don't set the
`default_aa` and where AA is not set from the zone data
(e.g. `dispatch/ans3`).
While building on uclibc this error is thrown:
In file included from ./include/dns/log.h:20,
from callbacks.c:19:
../../lib/isc/include/isc/log.h:141:9: error: unknown type name ‘off_t’
141 | off_t maximum_size;
| ^~~~~
This is due to missing include unistd.h, so let's add it on top of
isc/log.h
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Merge branch 'fix/uclibc-off_t-main' into 'main'
See merge request isc-projects/bind9!11422
While building on uclibc this error is thrown:
In file included from ./include/dns/log.h:20,
from callbacks.c:19:
../../lib/isc/include/isc/log.h:141:9: error: unknown type name ‘off_t’
141 | off_t maximum_size;
| ^~~~~
This is due to missing include unistd.h, so let's add it on top of
isc/log.h
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Revert the wait for log change for the rollover-zsk-prepub test.
Closes#5692
Merge branch '5692-rollover-zsk-prepub-step3-intermittent-test-fail' into 'main'
See merge request isc-projects/bind9!11413
Commit c17ac42608 changed some tests to
wait for "zone_needdump" messages instead of "sending notifies", because
notifies are rate limited and "zone_needdump" happen on every change.
However, inspecting the logs, the "zone_needdump" changes happen more
than once (likely because the re-signing is done in batches):
received control channel command 'sign step3.zsk-prepub.manual'
zone_journal: zone step3.zsk-prepub.manual/IN (signed): enter
zone_needdump: zone step3.zsk-prepub.manual/IN (signed): enter
zone_journal: zone step3.zsk-prepub.manual/IN (signed): enter
zone_needdump: zone step3.zsk-prepub.manual/IN (signed): enter
zone_journal: zone step3.zsk-prepub.manual/IN (signed): enter
zone_needdump: zone step3.zsk-prepub.manual/IN (signed): enter
zone step3.zsk-prepub.manual/IN (signed): sending notifies
This means we are running the rollover step checks too fast in some
test runs.
Revert the wait for log change for the rollover-zsk-prepub test.
Change the notify configuration to be more flexible for other types of generalized DNS notifications.
Also allow for notify-cfg SOA.
Merge branch 'matthijs-notify-cfg' into 'main'
See merge request isc-projects/bind9!11384
Add a type to all dns_zone_(get|set) functions that apply to sending
notifies, so the options can be set and retrieved separately per type.
This affects dns_zone_setnotifydefer, dns_zone_getnotifydefer,
dns_zone_setnotifydelay, dns_zone_getnotifydelay,
dns_zone_setnotifysrc4, and dns_zone_setnotifysrc6.
The functions dns_zone_getnotifysrc4 and dns_zone_getnotifysrc6 are
unused and can be removed.
It was not explicitly clear that ``rndc sign`` replaces signatures of inactive keys and updates signatures that are not so fresh.
Closes#5490
Merge branch '5490-clear-rndc-sign-on-error' into 'main'
See merge request isc-projects/bind9!11396
A single spoofed DNAME answer can impact many names, and because of the
nature of DNAME, the attacker can use randomized query names to get
unlimited number of tries to spoof the answer. To limit impact, we
should not be accepting DNAME over insecure transport, like UDP without
cookies etc.
In short, the attacker tries to spoof at least one answer that has the
following form:
opcode QUERY
rcode NOERROR
flags QR AA
;QUESTION
trigger$RANDOM.test. IN A
;ANSWER
trigger$RANDOM.test. 3600 IN CNAME trigger$RANDOM.attacker.net.
test. 3600 IN DNAME attacker.net.
;AUTHORITY
;ADDITIONAL
This has been discovered internally.
Co-authored-by: Michał Kępień <michal@isc.org>
In short, the attacker tries to spoof at least one answer that has the
following form:
rcode NOERROR
flags QR
;QUESTION
trigger$RANDOM.victim. IN TXT
;ANSWER
;AUTHORITY
trigger$RANDOM.victim. 3600 IN NS ns.victim.
;ADDITIONAL
ns.victim. 3600 IN A 10.53.0.3
This attack was originally reported as "test case 2".
Co-authored-by: Michał Kępień <michal@isc.org>
Before the fixes for CVE-2025-40778, an unsolicited in-bailiwick NS
record was accepted from a (spoofed) answer, enabling a single spoofed A
query/response to redirect traffic for a whole delegation.
In short, the attacker tries to spoof at least one answer that has the
following form:
rcode NOERROR
flags QR AA
;QUESTION
trigger$RANDOM.victim. IN TXT
;ANSWER
trigger$RANDOM.victim. 3600 IN TXT "spoofed answer with extra NS"
;AUTHORITY
victim. 3600 IN NS ns.attacker.
;ADDITIONAL
This attack was originally reported as "test case 1".
Co-authored-by: Michał Kępień <michal@isc.org>
Before the fixes for CVE-2025-40778, a positive answer was allowed to
overwrite sibling NS RRs. The answer had to be a positive AA=1 answer
with a fake NS along with it. This combination of conditions avoided
the code path with "unrelated <RRTYPE>" detection logic.
If it were some other answer, named from the main branch would detect
the attempt and log:
DNS format error from 10.53.0.1#16386 resolving trigger/A for <unknown>: unrelated NS victim in trigger authority section
In short, the attacker tries to spoof at least one answer that has the
following form:
opcode QUERY
rcode NOERROR
flags QR AA
;QUESTION
trigger$RANDOM. IN A
;ANSWER
trigger$RANDOM. 3600 IN A 10.53.0.3
;AUTHORITY
victim. 3600 IN NS ns.attacker.
;ADDITIONAL
ns.attacker. 3600 IN A 10.53.0.3
This attack was originally reported as "test case 1c".
Co-authored-by: Michał Kępień <michal@isc.org>
Add bin/tests/system/ans.py, a bare-bones DNS server that can be used in
system tests instead of full-blown named instances when a server is only
required to return zone-based data. Where applicable, this reduces load
on the test host and the amount of generated logs.
Use a static dns_name_t for the "_dsync" label. Remove some
unnecessary dns_fixedname_t variables. Remove unnecessary dsyncname
dns_name_t from dns_dsyncfetch and rename dns_fixedname_t fname to
dsyncname.
Due to the way various asyncio-related objects (tasks, streams,
transports, selectors) are referencing each other, pausing reads for a
TCP transport (which in practice means removing the client socket from
the set of descriptors monitored by a selector) can cause the client
task (AsyncDnsServer._handle_tcp()) to be prematurely garbage-collected,
causing asyncio code to raise a "Task was destroyed but it is pending!"
exception. Who knew that solutions as elegant as the one introduced by
e407888507 could cause unexpected trouble?
Fix by making a horrible hack even more horrible, specifically by
keeping a reference to each incoming TCP connection to protect its
related asyncio objects from getting garbage-collected. This prevents
AsyncDnsServer from closing any of the ignored TCP connections
indefinitely, which is obviously a pretty brain-dead idea for a
production-grade DNS server, but AsyncDnsServer was never meant to be
one and this hack reliably solves the problem at hand.
Only apply this change for the IgnoreAllConnections handler as the
ConnectionReset handler triggers a connection reset immediately after
pausing reads for an incoming TCP connection.
As pointed out in e407888507, the proper
solution would require implementing a custom asyncio transport from
scratch and that is still deemed to be too much work for the purpose at
hand. Let's see how much longer we can limp along with the existing
approach.
Calling asyncio.Future.set_exception() or asyncio.Future.set_result()
more than once for a given Future object raises an
asyncio.InvalidStateError exception.
In the case of AsyncServer:
- it is enough to capture the first exception raised by higher-level
logic as no exceptions at all are expected to be raised in the first
place,
- no distinction is made between SIGINT and SIGTERM; the only purpose
of the signal handler is to make the server exit cleanly.
Given the above, make both AsyncServer._handle_exception() and
AsyncServer._signal_done() idempotent by ignoring
asyncio.InvalidStateError exceptions raised by the relevant
asyncio.Future.set_*() calls.
Where applicable, use the more detailed CMocka generated JUnit
reports which include subtest results and timings instead of the
one generated by Meson.
Prerequisites:
- bind9-qa!137
Closes#5511
Merge branch '5511-cmocka-junit-ouput' into 'main'
See merge request isc-projects/bind9!11100
Where applicable, use the more detailed CMocka generated JUnit
reports which include subtest results and timings instead of the
one generated by Meson.
Flaky tests also require retrying, so use a wrapper and mark them
with a environment variable. This is done to avoid the need to compute
an intersection of suites in Meson which is not supported out-of-the-box
(`meson test --suite=foo,bar` runs the union of foo and bar).
CMocka uses group names in the JUnit output.
Use dirname_filename as the group name, as there duplicate testnames
(e.g. time exists both in isc/ and dns/)
A zone that is signed with NSEC3, opt-out enabled, and then reconfigured to use NSEC, causes the zone to be published with missing NSEC records. This has been fixed.
Closes#5679
Merge branch '5679-nsec3-optout-to-nsec' into 'main'
See merge request isc-projects/bind9!11359
If we change from NSEC3 to NSEC we should not produce a zone with
missing NSEC records.
The code only considered having seen a record if there was previously
a signature present at the owner name. However with opt-out, insecure
delegations don't have a RRSIG record. Reconfiguring to NSEC causes
all insecure delegations to have a missing NSEC record.
Add a DNAME record to the test zone to also cover DNAME delegations.
This reverts commit 21295bc188.
In a sense, the ans6 black holeserver, based on asyncserver, "does
nothing". In our case, it won't respond to any query, and if the
IgnoreAllConnections connection handler was installed, it would not read
anything from the client socket.
Previously, sending notifications to an unconfigured address resulted in
no communication from the target (10.53.10.53); hence, the ns3
configuration comment requested a "non-responsive notify recipient (no
reply, no ICMP errors)".
However, examining the PCAP of ans6 reveals some communication from the
10.53.0.6 server to the 10.53.0.3 client, including ICMP Destination
Unreachable (Port Unreachable), and TCP SYN/ACK.
The ans6 communication seems to be sufficiently different to touch
different code paths in named, resulting in the BIND 9.20 backport
failing in the "checking notify retries expire within 30 seconds" test.
But we better revert it from "main" as well.
A new configuration option, ``notify-cfg CDS``, is added to enable Generalized DNS Notifications for CDS and/or CDNSKEY RRset changes, as specified in RFC 9859.
Closes#5611
Merge branch '5611-generalized-dns-notifications-rfc-9859' into 'main'
See merge request isc-projects/bind9!11315
The RFC says There MUST NOT be more than one DSYNC record for each
combination of RRtype and Scheme. If we encounter more we should drop
the response, as the DSYNC RRset is invalid.
When doing rollover and the CDS/CDNSKEY RRset is updated, test that a
NOTIFY(CDS) message is sent. For other steps in the rollover, prohibit
any dsyncfetch activity.
