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.
When starting up the services, send notifies for the existing CDS RRset.
This requires setting up a chain of trust for the test, so the DSYNC
records can be retrieved and validated.
This feature requires enabling 'notify-cds' and 'dnssec-validation'.
In this test, the scanner is pointed to ns2. Since there is no code
for receiving NOTIFY(CDS) messages for delegations, this is treated
as "not authoritative". Checking for this log message ensures us that
the NOTIFY(CDS) message was actually sent.
When the CDS/CDNSKEY RRset gets updated, schedule a NOTIFY(CDS) to be
sent to the parental agent. The parental agent is published in the
parent zone as a DSYNC RRset, so first we need to figure out the
parent owner name. This is done by finding the zonecut (querying for
NS RRset until we find a postive answer).
In nsfetch_dsync, we then schedule a zone fetch for the DSYNC record
at <child-labels>._dsync.<parent-labels>. Then we queue the notify
for each target in the DSYNC records that matches the NOTIFY scheme
and CDS RRtype.
Now that we log the type of the notify, some expected log messages
in the system tests need to be adjusted accordingly.
The bin/tests/system/nsec3/tests_nsec3_retransfer.py log is changed
to zone_needdump because it is more reliable. Other tests were
adjusted similar in MR !11265, but !11226 introduced a new
"sending notify" log line.
With Generalized DNS Notifications, a zone may need to send different
type of NOTIFY messages for different reasons. When creating a new
notify, allow for specifying the type.
The DSYNC record has a Port rdata field, so NOTIFY(CDS) messages may be
configured at different ports. When creating a new notify, allow for
specifying the port.
With Generalized DNS Notifications, a zone may need to send different
NOTIFY messages for different reasons. Introduce a method to
initialize a notify context and maintain a notify contexts per RRtype.
Update the functions 'dns_dnssec_syncupdate()' and
'dns_dnssec_syncdelete()' to make a distinction between a changed RRset
and no changes made.
The return code will be used later to determine if we need to send a
NOTIFY(CDS) to DSYNC endpoints.
Symlink ns1 and ns2 to rollover/ns1 and rollover/ns2.
Symlink ns3/template.db.j2.manual to rollover/ns3/template.db.j2.manual.
Since the bootstrapping is done before the templates are rendered
automatically, replace @DEFAULT_ALGORITHM@ in ns3/kasp.conf.j2 to
ecdsa256 and rename to ns3/kasp.conf.
Symlink ns1 and ns2 to rollover/ns1 and rollover/ns2.
Symlink ns3/template.db.j2.manual to rollover/ns3/template.db.j2.manual.
Since the bootstrapping is done before the templates are rendered
automatically, replace @DEFAULT_ALGORITHM@ in ns3/kasp.conf.j2 to
ecdsa256 and rename to ns3/kasp.conf.
Symlink ns1 and ns2 to rollover/ns1 and rollover/ns2.
Symlink ns3/template.db.j2.manual to rollover/ns3/template.db.j2.manual.
Since the bootstrapping is done before the templates are rendered
automatically, replace @DEFAULT_ALGORITHM@ in ns3/kasp.conf.j2 to
ecdsa256 and rename to ns3/kasp.conf.
Now we have to fake different lifetimes, so adjust fake_lifetime
to update a single key.
Note that we have changed the setup slightly: We also sign the
step2 zones, but with post validation disabled. This is more
accurate because we need to test that the public keys and signatures
are being removed from the zone.
