Tweak and reword release notes

Add release note for [GL #4708]

Add release note for [GL #4736]

Add release note for [GL #3472]

Prepare release notes for BIND 9.19.25

This version won't be released. This commit is just a preparation for
9.20.0.

Add another placeholder for [GL #4480]

(cherry picked from commit 1680916d6709dce8c45e49079b37f19a2f09297c)

Merge branch 'tcp-reset-connection-on-failed-send' into 'v9.20.0-release'

[CVE-2024-0760 (part 3)] Reset the TCP connection on a failed send

See merge request isc-private/bind9!721

Drop expired but not accepted TCP connections

This commit ensures that we are not attempting to accept an expired
TCP connection as we are not interested in any data that could have
been accumulated in its internal buffers. Now we just drop them for
good.

Reset the TCP connection on a failed send

When sending fails, the ns__client_request() would not reset the
connection and continue as nothing is happening.  This comes from the
model that we don't care about failed UDP sends because datagrams are
unreliable anyway, but it greatly affects TCP connections with
keep-alive.

The worst case scenario is as follows:

1. the 3-way TCP handshake gets completed
2. the libuv calls the "uv_connection_cb" callback
3. the TCP connection gets queue because of the tcp-clients quota
4. the TCP client sends as many DNS messages as the buffers allow
5. the TCP connection gets dropped by the client due to the timeout
6. the TCP connection gets accepted by the server
7. the data already sent by the client gets read
8. all sending fails immediately because the TCP connection is dead
9. we consume all the data in the buffer in a very tight loop

As it doesn't make sense to trying to process more data on the TCP
connection when the sending is failing, drop the connection immediately
on the first sending error.

Remove ns_query_init() cannot fail, remove the error paths

As ns_query_init() cannot fail now, remove the error paths, especially
in ns__client_setup() where we now don't have to care what to do with
the connection if setting up the client could fail.  It couldn't fail
even before, but now it's formal.

Throttle the reading when writes are asynchronous

Be more aggressive when throttling the reading - when we can't send the
outgoing TCP synchronously with uv_try_write(), we start throttling the
reading immediately instead of waiting for the send buffers to fill up.

This should not affect behaved clients that read the data from the TCP
on the other end.

Merge branch '3405-security-limit-the-number-of-resource-records-in-rrset-nxdomain' into 'v9.20.0-release'

[CVE-2024-1737 (part 2)] Be smarter about refusing to add many RR types to the database

See merge request isc-private/bind9!712

Add more tests for adding many RR types to the database

More reclimit tests that test various scenarios adding combinations of
priority and non-priority RR types into the database.

Be smarter about refusing to add many RR types to the database

Instead of outright refusing to add new RR types to the cache, be a bit
smarter:

1. If the new header type is in our priority list, we always add either
   positive or negative entry at the beginning of the list.

2. If the new header type is negative entry, and we are over the limit,
   we mark it as ancient immediately, so it gets evicted from the cache
   as soon as possible.

3. Otherwise add the new header after the priority headers (or at the
   head of the list).

4. If we are over the limit, evict the last entry on the normal header
   list.

Make the resolver qtype ANY test order agnostic

Instead of relying on a specific order of the RR types in the databases
pick the first RR type as returned from the cache.

Expand the list of the priority types and move it to db_p.h

Add HTTPS, SVCB, SRV, PTR, NAPTR, DNSKEY and TXT records to the list of
the priority types that are put at the beginning of the slabheader list
for faster access and to avoid eviction when there are more types than
the max-types-per-name limit.

Merge branch 'tcp-do-not-unthrottle-on_isc_nm_read' into 'v9.20.0-release'

[CVE-2024-0760 (part 2)] Do not un-throttle TCP connections on isc_nm_read()

See merge request isc-private/bind9!708

Do not un-throttle TCP connections on isc_nm_read()

Due to omission it was possible to un-throttle a TCP connection
previously throttled due to the peer not reading back data we are
sending.

In particular, that affected DoH code, but it could also affect other
transports (the current or future ones) that pause/resume reading
according to its internal state.

Merge branch 'nicki/add-another-placeholder-for-4480' into 'main'

Add another placeholder for [GL #4480]

See merge request isc-projects/bind9!9100

Add another placeholder for [GL #4480]

Merge branch 'nicki/add-placeholder-entries' into 'main'

Add placeholder entries to CHANGES

See merge request isc-projects/bind9!9096

Merge branch '4507-confidential-clear-zversion' into 'v9.20.0-release'

[CVE-2024-4076] serve-stale zversion crash

See merge request isc-private/bind9!631

Add release note for [GL #4507]

Add CHANGES note for [GL #4507]

Clear qctx->zversion

Clear qctx->zversion when clearing qctx->zrdataset et al in
lib/ns/query.c:qctx_freedata.  The uncleared pointer could lead to
an assertion failure if zone data needed to be re-saved which could
happen with stale data support enabled.

Merge branch '4480-sig0-can-be-used-to-exhaust-cpu-resources-v6' into 'v9.20.0-release'

[CVE-2024-1975] Mitigate SIG(0) CPU resources exhaustion attack vectors

See merge request isc-private/bind9!689

Require local KEYs for SIG(0) verification

This is additional hardening. There is no known use-case for KEY RRs
from DNS cache and it potentially allows attackers to put weird keys
into cache.

Mark SIG(0) quota settings as experimantal

A different solution in the future might be adopted depending
on feedback and other new information, so it makes sense to mark
these options as EXPERIMENTAL until we have more data.

Avoid running get_matching_view() asynchronously on an error path

Also create a new ns_client_async_reset() static function to decrease
code duplication.

Test that named checks maximum two keys for SIG(0)-signed messages

Send three updates with three different keys, and expect that one
of them should fail.

Also retain more artifacts for neighboring nsupdate calls.

Add a release note for [GL #4480]

Add a CHANGES note for [GL #4480]

Limit the number of keys for SIG(0) message verification

Check at most two KEY RRs agains a SIG(0) signature. This should
limit potential abuse and at the same time allow key rollover.

Run resolver message signature checking asynchronously

Remove sig0checks-quota-maxwait-ms support

Waiting for a quota to appear complicates things and wastes
rosources on timer management. Just answer with REFUSE if
there is no quota.

Implement asynchronous view matching for SIG(0)-signed queries

View matching on an incoming query checks the query's signature,
which can be a CPU-heavy task for a SIG(0)-signed message. Implement
an asynchronous mode of the view matching function which uses the
offloaded signature checking facilities, and use it for the incoming
queries.

Implement asynchronous message signature verification

Add support for using the offload threadpool to perform message
signature verifications. This should allow check SIG(0)-signed
messages without affecting the worker threads.

Remove dns_message_rechecksig()

This is a tiny helper function which is used only once and can be
replaced with two function calls instead. Removing this makes
supporting asynchronous signature checking less complicated.

Document the SIG(0) signature checking quota options

Add documentation entries for the 'sig0checks-quota',
'sig0checks-quota-maxwait-ms', and 'sig0checks-quota-exempt'
optoins.

Add a quota for SIG(0) signature checks

In order to protect from a malicious DNS client that sends many
queries with a SIG(0)-signed message, add a quota of simultaneously
running SIG(0) checks.

This protection can only help when named is using more than one worker
threads. For example, if named is running with the '-n 4' option, and
'sig0checks-quota 2;' is used, then named will make sure to not use
more than 2 workers for the SIG(0) signature checks in parallel, thus
leaving the other workers to serve the remaining clients which do not
use SIG(0)-signed messages.

That limitation is going to change when SIG(0) signature checks are
offloaded to "slow" threads in a future commit.

The 'sig0checks-quota-exempt' ACL option can be used to exempt certain
clients from the quota requirements using their IP or network addresses.

The 'sig0checks-quota-maxwait-ms' option is used to define a maximum
amount of time for named to wait for a quota to appear. If during that
time no new quota becomes available, named will answer to the client
with DNS_R_REFUSED.

Merge branch '3405-security-limit-the-number-of-resource-records-in-rrset' into 'v9.20.0-release'

Limit the number of RRs in RRSets

See merge request isc-private/bind9!694

Add CHANGES and release note for [GL #3403]

Log rekey failure as error if too many records

By default we log a rekey failure on debug level. We should probably
change the log level to error. We make an exception for when the zone
is not loaded yet, it often happens at startup that a rekey is
run before the zone is fully loaded.

Log error when update fails

The new "too many records" error can make an update fail without the
error being logged. This commit fixes that.

fix a memory leak that could occur when signing

when signatures were not added because of too many types already
existing at a node, the diff was not being cleaned up; this led to
a memory leak being reported at shutdown.

Add new test cases with DNSSEC signing

kasp-max-types-per-name (named2.conf.in):
An unsigned zone with RR type count on a name right below the
configured limit. Then sign the zone using KASP. Adding a RRSIG would
push it over the RR type limit per name. Signing should fail, but
the server should not crash, nor end up in infinite resign-attempt loop.

kasp-max-records-per-type-dnskey (named1.conf.in):
Test with low max-record-per-rrset limit and a DNSSEC policy requiring
more than the limit. Signing should fail.

kasp-max-types-per-name (named1.conf.in):
Each RRSIG(covered type) is counted as an individual RR type. Test the
corner case where a signed zone, which is just below the limit-1,
adds a new type - doing so would trigger signing for the new type and
thus increase the number of "types" by 2, pushing it over the limit
again.

Check if restart works

Switch to inline-signing no

Add test cases that use DNSSEC signing

Add two new masterformat tests that use signing. In the case of
'under-limit-kasp', the signing will keep the number of records in the
RRset under the limit. In the case of 'on-limit-kasp', the signing
will push the number of records in the RRset over the limit, because
of the added RRSIG record.

Remove duplicated empty zone files

masterformat: rename zone names to reflect intended meaning

Test owner name rename: a b c d e -> <number>-txt

Test variable rename i->_attempt

Test variable rename a->rrcount

Add test for not-loading many RRsets per name on a secondary

This tests makes sure the zone with many RRsets per name is not loaded
via XFR on the secondary server.

Add a test for not caching large number of RRsets

Send a recursive query for a large number of RRsets, which should
fail when using the default max-types-per-name setting of 100, but
succeed when the cap is disabled.

Add a limit to the number of RR types for single name

Previously, the number of RR types for a single owner name was limited
only by the maximum number of the types (64k).  As the data structure
that holds the RR types for the database node is just a linked list, and
there are places where we just walk through the whole list (again and
again), adding a large number of RR types for a single owner named with
would slow down processing of such name (database node).

Add a configurable limit to cap the number of the RR types for a single
owner.  This is enforced at the database (rbtdb, qpzone, qpcache) level
and configured with new max-types-per-name configuration option that
can be configured globally, per-view and per-zone.

Add a test for not caching large RRset

Send a recursive query for a large (2500 record) RRset, which should
fail when using the default max-records-per-type setting of 100, but
succeed when the cap is disabled.

Add test for not-loading and not-transfering huge RRSets

Add two new masterformat tests - the 'huge' zone fits within the ns1
limit and loads on the primary ns1 server, but must not transfer to the
ns2 secondary, and the 'uber' zone should not even load on the primary
ns1 server.

Add a limit to the number of RRs in RRSets

Previously, the number of RRs in the RRSets were internally unlimited.
As the data structure that holds the RRs is just a linked list, and
there are places where we just walk through all of the RRs, adding an
RRSet with huge number of RRs inside would slow down processing of said
RRSets.

Add a configurable limit to cap the number of the RRs in a single RRSet.
This is enforced at the database (rbtdb, qpzone, qpcache) level and
configured with new max-records-per-type configuration option that can
be configured globally, per-view and per-zone.

Merge branch '4481-security-tcp-flood' into 'v9.20.0-release'

[CVE-2024-0760] Throttle reading from TCP if the sends are not getting through

See merge request isc-private/bind9!639

Add CHANGES and release note for [GL #4481]

Remove the extra memory context with own arena for sending

The changes in this MR prevent the memory used for sending the outgoing
TCP requests to spike so much.  That strictly remove the extra need for
own memory context, and thus since we generally prefer simplicity,
remove the extra memory context with own jemalloc arenas just for the
outgoing send buffers.

Limit the number of DNS message processed from a single TCP read

The single TCP read can create as much as 64k divided by the minimum
size of the DNS message.  This can clog the processing thread and trash
the memory allocator because we need to do as much as ~20k allocations in
a single UV loop tick.

Limit the number of the DNS messages processed in a single UV loop tick
to just single DNS message and limit the number of the outstanding DNS
messages back to 23.  This effectively limits the number of pipelined
DNS messages to that number (this is the limit we already had before).

Replace the tcp_buffers memory pool with static per-loop buffer

As a single thread can process only one TCP send at the time, we don't
really need a memory pool for the TCP buffers, but it's enough to have
a single per-loop (client manager) static buffer that's being used to
assemble the DNS message and then it gets copied into own sending
buffer.

In the future, this should get optimized by exposing the uv_try API
from the network manager, and first try to send the message directly
and allocate the sending buffer only if we need to send the data
asynchronously.

ns_client: reuse TCP send buffers

Constantly allocating, reallocating and deallocating 64K TCP send
buffers by 'ns_client' instances takes too much CPU time.

There is an existing mechanism to reuse the ns_clent_t structure
associated with the handle using 'isc_nmhandle_getdata/_setdata'
(see ns_client_request()), but it doesn't work with TCP, because
every time ns_client_request() is called it gets a new handle even
for the same TCP connection, see the comments in
streamdns_on_complete_dnsmessage().

To solve the problem, we introduce an array of available (unused)
TCP buffers stored in ns_clientmgr_t structure so that a 'client'
working via TCP can have a chance to reuse one (if there is one)
instead of allocating a new one every time.

Throttle reading from TCP if the sends are not getting through

When TCP client would not read the DNS message sent to them, the TCP
sends inside named would accumulate and cause degradation of the
service.  Throttle the reading from the TCP socket when we accumulate
enough DNS data to be sent.  Currently this is limited in a way that a
single largest possible DNS message can fit into the buffer.

Merge branch '4473-fix-doh-intermittent-crash' into 'v9.20.0-release'

DoH:  Avoid potential data races in our DoH implementation related to to HTTP/2 session object management and endpoints set object management

See merge request isc-private/bind9!614

Modify release notes [GL #4473]

Mention that an intermittent BIND process termination in DoH code has
been fixed.

Modify CHANGES [GL #4473]

Mention that an intermittent BIND process termination in DoH code has
been fixed.

Keep the endpoints set reference within an HTTP/2 socket

This commit ensures that an HTTP endpoints set reference is stored in
a socket object associated with an HTTP/2 stream instead of
referencing the global set stored inside a listener.

This helps to prevent an issue like follows:

1. BIND is configured to serve DoH clients;
2. A client is connected and one or more HTTP/2 stream is
created. Internal pointers are now pointing to the data on the
associated HTTP endpoints set;
3. BIND is reconfigured - the new endpoints set object is created and
promoted to all listeners;
4. The old pointers to the HTTP endpoints set data are now invalid.

Instead referencing a global object that is updated on
re-configurations we now store a local reference which prevents the
endpoints set objects to go out of scope prematurely.

DoH: avoid potential use after free for HTTP/2 session objects

It was reported that HTTP/2 session might get closed or even deleted
before all async. processing has been completed.

This commit addresses that: now we are avoiding using the object when
we do not need it or specifically check if the pointers used are not
'NULL' and by ensuring that there is at least one reference to the
session object while we are doing incoming data processing.

This commit makes the code more resilient to such issues in the
future.

Add placeholder entries to CHANGES

Add placeholders for the following issues:

- [GL #4473]
- [GL #4481]
- [GL #497] [GL #3405]
- [GL #3403] [GL #4548]
- [GL #4480]
- [GL #4507]

Merge branch 'nicki/add-placeholder-for-4661' into 'main'

Add a CHANGES placeholder for [GL #4661]

See merge request isc-projects/bind9!9097

Add a CHANGES placeholder for [GL #4661]

Merge branch '4728-allow-transfer-none' into 'main'

change allow-transfer default to "none"

Closes #4728

See merge request isc-projects/bind9!9046

CHANGES and relnotes for [GL #4728]

change allow-transfer default to "none"

Changed the default value for 'allow-transfer' to 'none'; zone
transfers now require explicit authorization.

Updated all system tests to specify an allow-transfer ACL when needed.

Revised the ARM to specify that the default is 'none'.

Merge branch 'ondrej/use-rcu-stack-for-qpcache-deadnodes' into 'main'

Use RCU wait-free stack for qpcache deadnodes

See merge request isc-projects/bind9!8907

Use isc_queue to implement wait-free deadnodes queue

Replace the ISC_LIST based deadnodes implementation with isc_queue which
is wait-free and we don't have to acquire neither the tree nor node lock
to append nodes to the queue and the cleaning process can also
copy (splice) the list into a local copy without acquiring the list.

Currently, there's little benefit to this as we need to hold those
locks anyway, but in the future as we move to RCU based implementation,
this will be ready.

To align the cleaning with our event loop based model, remove the
hardcoded count for the node locks and use the number of the event loops
instead.  This way, each event loop can have its own cleaning as part of
the process.  Use uniform random numbers to spread the nodes evenly
between the buckets (instead of hashing the domain name).

Add isc_queue implementation on top of cds_wfcq

Add an isc_queue implementation that hides the gory details of cds_wfcq
into more neat API.  The same caveats as with cds_wfcq.

TODO: Add documentation to the API.

Merge branch '4736-isc_r_hostdown-was-not-being-handled-by-resolver-c' into 'main'

Resolve "ISC_R_HOSTDOWN was not being handled by resolver.c"

Closes #4736

See merge request isc-projects/bind9!9055

Add CHANGES note for [GL #4736]

Update resquery_senddone handling of ISC_R_TIMEDOUT

Treat timed out as an address specific error.

Update resquery_senddone handling of ISC_R_CONNECTIONRESET

Treat connection reset as an address specific error.

Handle ISC_R_HOSTDOWN and ISC_R_NETDOWN in resolver.c

These error codes should be treated like other unreachable error
codes.

Merge branch '4706-4707-add-more-label-checks-to-dangerfile.py' into 'main'

Add more label checks to dangerfile.py

Closes #4706 and #4707

See merge request isc-projects/bind9!9040

Fail for merge requests with "Affects v9.x" labels

Setting "Affects v9.x" labels on a merge request duplicates information
already present on the GitLab issue associated with that merge request.
For trivial merge requests that are not associated with any GitLab
issue, setting the "Affects v9.x" label(s) is considered unnecessary.
Trigger a failure for every merge request marked with at least one
"Affects v9.x" label.

Warn about auto-generated merge request titles

Merge request titles auto-generated by GitLab are often a source of
confusion regarding the actual contents of a given merge request.  Warn
for merge requests containing titles that look like auto-generated ones.

Fail for branches using old-style version suffixes

Using "-v9_x" and "-v9.x" version suffixes for branch names is now
deprecated since some automation logic does not handle these.  Fail for
any merge request using such old-style version suffixes.

Fail for backports with "Affects v9.x" labels set

Backports are not expected to have any "Affects v9.x" labels set since
those are only meant to be set for merge requests that should have
backports created for them.

Merge branch '3472-ipv4-only-mode-not-respected-for-zone-transfers' into 'main'

Resolve "IPv4-only mode not respected for zone transfers"

Closes #3472

See merge request isc-projects/bind9!8522

Add CHANGES note for [GL #6288]

Don't do DS checks over disabled address families

Don't forward UPDATE messages over disabled address families

Don't send NOTIFY over disabled address families

Check that no primaries is logged with -4 or -6

When in -4 mode check that "IPv6 disabled and no IPv4 primaries"
is logged and when in -6 mode check that "IPv4 disabled and no IPv6
primaries" is logged.

Report non-effective primaries

When named is started with -4 or -6 and the primaries for a zone
do not have an IPv4 or IPv6 address respectively issue a log message.

Zone transfers should honour -4 and -6 options

Check if the address family has been disabled when transferring
zones.

Add helper function isc_sockaddr_disabled