A positive wildcard answer, and the NSEC3 proof that the requested
name doesn't exist in the zone, must both be from the same zone.
Otherwise, an NSEC3 from an ancestor zone could be used to interfere
with validation.
We now retrieve the signer name from a wildcard response's signature.
An NSEC3 record cannot be used as a NOQNAME proof for the
wildcard unless it exactly matches the name one level above the NSEC3.
Closes#5971
Merge branch '5971-wildcard-noqname-mismatch' into 'main'
See merge request isc-projects/bind9!12256
A positive wildcard answer, and the NSEC3 proof that the requested
name doesn't exist in the zone, must both be from the same zone.
Otherwise, an NSEC3 from an ancestor zone could be used to interfere
with validation.
We now retrieve the signer name from a wildcard response's signature.
An NSEC3 record cannot be used as a NOQNAME proof for the wildcard
unless it exactly matches the name one level above the NSEC3.
Fixes: isc-projects/bind9#5971
Under `forward-first` policy in a forwarding zone BIND could accept NS above the forward zone apex from negative responses. This has been fixed.
ISC would like to thank Qifan Zhang, of Palo Alto Networks, for the report.
Closes#5937
Merge branch '5937-fix-forward-first-referral-bailiwick-v2' into 'main'
See merge request isc-projects/bind9!12154
Apply the existing name_external() bailiwick check to NS RRsets
processed as referrals in rctx_authority_negative(), and enforce the
same check again in rctx_referral() before caching or following the
delegation.
This prevents a forward-first forwarder from installing a parent
zone-cut above the configured forward zone via an authority-section
NS RRset.
Add a system test covering authority-section NS referrals returned by
configured forwarders under forward first.
The test verifies that a forwarder for fwd.hack cannot install the
parent hack zone cut and redirect resolution for the sibling zone
sibling.hack.
Since internal communications are now Zulip based, CI jobs now target
Zulip instead of Mattermost. The `MATTERMOST_WEBHOOK_URL` environment
variable is no longer needed, scripts now use `ZULIP_SERVER_URL` and
`ZULIP_API_KEY`.
In order to harmonize Zulip messaging, `message_zulip.py` is used where
curl calls to the webhook were previously used.
Merge branch 'andoni/mattermost-to-zulip-migration' into 'main'
See merge request isc-projects/bind9!12199
Since internal communications are now Zulip based, CI jobs now target
Zulip instead of Mattermost. The MATTERMOST_WEBHOOK_URL environment
variable is no longer needed, scripts now use ZULIP_SERVER_URL and
ZULIP_API_KEY.
In order to harmonize Zulip messaging, message_zulip.py is used where
curl calls to the webhook were previously used.
When forwarding DNS queries, the CD bit is cleared on the first query, and the CD bit is only used as a fallback if the first query fails. However, due to a logic bug this could lead to an unbounded loop re-sending the same message, until the maximum query count is hit. This has been fixed.
Closes#5804
Merge branch '5804-resend-loop-forwarder-cd' into 'main'
See merge request isc-projects/bind9!12133
Commit `36cf1c6a5bf943ad718ddba9fbe6ea97810e3bc2` introduces the
`DNS_FETCHOPT_TRYCD` flag which enables, when sending a query to a
forwarder, the forwarder to validate the answer (CD=0). The crux is
that if for some reason the forwarder returns SERVFAIL, we can retry the
same query and disable the forwarder validation (CD=1) so the resolver
can attempt validation itself (or detect it's bogus).
The logic was to first set `DNS_FETCHOPT_TRYCD` to the query options but
not on the message (so CD=0), and, when getting a SERVFAIL answer, if
the option `DNS_FETCHOPT_TRYCD` was set, to also set it into the
message. However, there was no way to know if this was the first (or
second) query because the original message is discarded when getting the
answer. This can lead to an unbounded loop re-sending the same message
again and again (until the global query count stops it).
This is fixed by using two separate flags `DNS_FETCHOPT_TRYNOCD`, set on
the query options for the very first query, then, if it SERVFAIL,
check if `DNS_FETCHOPT_TRYNOCD` is set but `DNS_FETCHOPT_TRYCD` is not.
In this case, we know we're about to send the second query. If it also
fails, `DNS_FETCHOPT_TRYCD` will be set anyway, so there is no point
retrying. This breaks the unbounded loop.
Run malicious server: resend_loop/ans2/ans.py
Start BIND: ns1
Send single query to test.com
OBSERVED BEHAVIOR
The malicious server receives tens of thousands of resend packets
within seconds. CPU usage of the named worker thread remains elevated
(50–100% of one core) until the default fetch timeout (~10 seconds)
terminates the request. Instrumentation during testing confirmed that
isc_counter_used(fctx->qc) remains constant (value 1) throughout the
entire resend loop.
When caching delegation NS data, only use A/AAAA glue records if the resolver has the corresponding IPv4/IPv6 dispatcher configured. If IPv4 or IPv6 is disabled, ignore glue for that family and fall back to caching the nameserver name if there is no glue from the other supported family.
Merge branch 'colin/glues-supported-stack' into 'main'
See merge request isc-projects/bind9!11889
When caching delegation NS data, only use A/AAAA glue records if the
resolver has the corresponding IPv4/IPv6 dispatcher configured. If IPv4
or IPv6 is disabled, ignore glue for that family and fall back to
caching the nameserver name if there is no glue from the other supported
family.
The new `cache_delegns` system test is covering delegation NS caching
with dual-stack resolver, IPv4-only, IPv6-only configurations. It also
set up an authoritative sever with zones with A-only, AAAA-only, and
dual-stack glue, which are all queried, and checks the delegation
database dump to confirm that the cached delegation data correspond to
the resolver configuration.
The `geoip metro` and `geoip metrocode` configuration options has been
removed as metro code are deprecated from MaxMind library.
Merge branch 'colin/remove-geoip-metro' into 'main'
See merge request isc-projects/bind9!12217
Each response served on a JSON statistics endpoint released the wrong
pointer to the JSON library after the response was sent: the response
body string instead of the JSON document. With the current responses
this does not crash named in practice, but the call is incorrect and
can in principle corrupt memory. XML responses are not affected.
Closes#6024
Merge branch '6024-statschannel-json-response-invalid-free' into 'main'
See merge request isc-projects/bind9!12068
wrap_jsonfree() called json_object_put() on the response-body buffer
base, which is the JSON string returned by
json_object_to_json_string_ext(), not a struct json_object. The root
object is already passed in as the callback argument; release only
that.
Hit every JSON statistics endpoint several times. The current code
calls json_object_put() on the response-body string pointer, which
doesn't crash just by accident - the memory position contains large
value from static string.
Synced with the h2o/picohttpparser upstream repository up to commit
f4d94b48b31e0abae029ebeafcfd9ca0680ede58.
This commit is just hygiene and consistency by keeping the vendored copy
current.
Merge branch 'mnowak/picohttpparser-sync-a875a01' into 'main'
See merge request isc-projects/bind9!12159
This:
- makes sure all variables are initialized
- adds missing curly braces for single line statements
- use proper comment for fallthrough case statements
Pull in upstream commit a875a01 from h2o/picohttpparser: enforce use of
CRLF in chunk headers, by rejecting bare CR / LF. Replaces the lenient
CHUNKED_IN_CHUNK_CRLF state with strict CHUNKED_IN_CHUNK_HEADER_EXPECT_LF,
CHUNKED_IN_CHUNK_DATA_EXPECT_CR and CHUNKED_IN_CHUNK_DATA_EXPECT_LF states.
Synced with the h2o/picohttpparser upstream repository up to commit
f4d94b48b31e0abae029ebeafcfd9ca0680ede58.
This commit is just hygiene and consistency by keeping the vendored copy
current.
Assisted-by: Claude:claude-opus-4-7
The per-loop worker threads allocated their state from the loop manager's
memory context instead of the per-loop context that owns them. Allocate
from the owning loop's context and hold a reference to that loop for the
thread's lifetime, matching the context handling already used on the
work-enqueue and completion paths.
Already changed as part of 9.20 backport.
Merge branch 'ondrej/rewrite-threadpool-fixups' into 'main'
See merge request isc-projects/bind9!12268
Instead of running the work directly, run it asynchronously to prevent
dead-locks when then isc_work is scheduled from inside a lock and the
job itself is using locking.
A per-loop work thread referenced the loop manager's memory context,
which is not the context that backs the loop the thread serves. Pass
the owning loop instead and allocate from loop->mctx, keeping a loop
reference for the thread's lifetime. This matches how isc_work_enqueue
and work_done already obtain the context from the loop, and the
teardown uses loop->mctx before dropping the reference.
Replace the shell and Perl based FORMERR system test with a Python
test that constructs the malformed DNS packets directly and checks
the responses.
Remove the legacy shell and Perl test script and the intermediate
packet files in hex, leaving the packet construction inline in
tests_formerr.py.
Merge branch 'stepan/formerr-system-test-python' into 'main'
See merge request isc-projects/bind9!11898
Normalize the message ID to 0 and the TTL of records to 1 unless
required (OPT and UPDATE records require TTL=0).
Rename the questionclass test case to twoquestionclasses for
consistency.
Replace the shell and Perl based FORMERR system test with a Python
test that constructs the malformed DNS packets directly and checks
the responses.
Remove the legacy shell and Perl test script and the intermediate
packet files in hex, leaving the packet construction inline in
tests_formerr.py.
Preserve the same wire for all packets sent to the server, but
construct them in a more explicit and readable way.
Fold the libuv thread pool and the per-loop isc_helper threads into a single
isc_work pool. Each (loop, lane) gets its own SPSC queue and worker, which drops
the shared-queue contention, and the FAST/SLOW lanes keep short crypto tasks off
the long blocking ones (zone dump/load, xfrin). isc_work jobs are now cancelable:
isc_work_cancel() tombstones a still-queued job and its after_cb fires with
ISC_R_CANCELED, so abandoned work can be dropped instead of run to completion.
Merge branch 'ondrej/rewrite-threadpool' into 'main'
See merge request isc-projects/bind9!12226
Offloaded work used two different mechanisms: a per-loop isc_helper
thread for CPU-bound crypto (DNSSEC validation, message signature
checks) and the process-global libuv thread pool for blocking I/O (zone
load and dump, inbound transfer apply). Neither could cancel a queued
task, and the two disagreed about exclusive mode — the helper paused
with its loop under isc_loopmgr_pause() but the libuv pool did not, so
blocking offloaded work kept running while a loop held the exclusive
lock.
Unify both behind isc_work: each loop gets its own worker thread per
lane — FAST for short, bounded tasks and SLOW for long, blocking ones —
fed by a private queue. Separate lanes keep a short crypto task off the
path of a multi-second zone dump once both run on per-loop workers;
every lane parks with isc_loopmgr_pause() so exclusive mode now quiesces
offloaded work too; and a still-queued task can be canceled before it
starts (isc_work_cancel). isc_helper is removed and its callers select a
lane.
Due to a recent change which dropped the non-IN-class in views, the
following tests are failing in cross-version-config-tests:
auth
catz
class
resolver
unknown
This can be reverted once the July releases are public.
The code printing query statistics was ignoring the zone-statistics
option. This has been fixed.
Closes#6164
Merge branch '6164-no-per-zone-glue-stats' into 'main'
See merge request isc-projects/bind9!12262
Under certain circumstances, a cached SERVFAIL response could incorrectly prevent successful resolution of a CNAME target. This could cause resolution failures to persist until the cached SERVFAIL entry expired, even when the CNAME target itself was otherwise resolvable. This issue has been fixed.
Closes#5983
Merge branch '5983-servfail-cache-cname' into 'main'
See merge request isc-projects/bind9!12158
Instead of using `client->query.qname` when caching a SERVFAIL answer,
use `client->query.origqname` when available.
This avoids caching a SERVFAIL against a CNAME target when the failure
occurs while the resolver is following the CNAME chain. This is
problematic, for instance, when the SERVFAIL is triggered by the
`max-query-count` threshold being reached, which would incorrectly
prevent legitimate resolution of the CNAME target while in the SERVFAIL
cache.
Note that if the SERVFAIL genuinely originated from resolving the CNAME
target, that specific failure will no longer be cached, and a direct
query for the CNAME target will trigger a fresh (likely failing)
resolution attempt. However, this is still preferable to the previous
behaviour, which would wrongly prevent resolving the CNAME target if it
was cached for other reasons (like the example above).
Add a system test for the case where resolution SERVFAILs because the
fetch context reaches the `max-query-count` threshold while following a
CNAME.
Resolving the CNAME target independently should still work, because the
SERVFAIL cache stores the original query name rather than the target.
Previously, when the additional section of a response was being
populated, if cached data was found with pending trust, it would be
opportunistically validated. The code implementing this validation was
not quite formally correct. Rather than fixing it, the code has been
removed: RRsets with pending trust are now omitted from responses.
Closes#5966Closes#5968Closes#5972
Merge branch 'each-remove-lightweight-validator' into 'main'
See merge request isc-projects/bind9!12236
Merge the tests for #5966 (F-043) and #5972 (F-045), previously called
dnssec_wildcard_additional and dnssec_replayed_parent_wildcard, into a
single directory with two modules.
Previously, when the additional section of a response was being
populated, if cached data was found with pending trust, it would be
opportunistically validated. The code implementing this validation was
not quite formally correct; rather than fixing it, the code has been
removed; RRsets with pending trust are now omitted from responses.
Fixes: isc-projects/bind9#5966Fixes: isc-projects/bind9#5968Fixes: isc-projects/bind9#5972
We no longer want to encourage people to open new issues via email because we are getting too many spammy reports generated by LLM. By requiring people actually login to Gitlab to make their report, they will (hopefully) see our reporting template, and think at least a little bit about whether they are making a well-considered, valid report.
Merge branch 'vicky-main-patch-01884' into 'main'
See merge request isc-projects/bind9!12248
