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.

(cherry picked from commit bc3e713317df838b4bbe6582b357cd8d78e585cd)

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

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

See merge request isc-private/bind9!713

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.

(cherry picked from commit 57cd34441a1b4ecc9874a4a106c2c95b8d7a3120)

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.

(cherry picked from commit 58f660cf2b800963fa649bc9823a626009db3a7e)

Expand the list of the priority types

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.

(cherry picked from commit b27c6bcce894786a8e082eafd59eccbf6f2731cb)

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

[9.18][CVE-2024-0760 (part 2)] Do not un-throttle TCP connections on isc_nm_read(), add throttling to TLS DNS

See merge request isc-private/bind9!709

Use smaller pools of requests and handles for sockets

This commit ensures that socket objects use smaller sizes for its
internal requests and handles pools. That prevents a memory allocator
from thrashing.

Avoid indefinite send re-scheduling in TLS DNS

When a peer is not reading the data we are sending it was for the TLS
DNS code to end up in a situation when it would indefinitely
reschedule send requests, effectively turning the 'uv_loop' into a
busy loop that would consume CPU cycles in endless efforts to send
outgoing data.

The main reason for that was only one send buffer dedicated for sends:
the code would re-queue sends until it is empty - that would never
happen when the remote side is not reading data.

That seems like an omission from the older day of the Network Manager
as it is quiet simple to make the code use multiple buffers for
sends. That ultimately breaks the cycle of futile send request
rescheduling.

As a side effect, this commit also gets rid of one memory copying on a
hot path.

Introduce TCP throttling into TLS DNS code

Throttling functionality was omitted from the
c6f13f12cd862ffae071e56ee7e1fa9998fc23c3. This commit fixes that,
taking into account the latest developments in this area.

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.

(cherry picked from commit d228aa8bbb944fbd04baf22d151fde5c33561e26)

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

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

See merge request isc-private/bind9!687

Add release note for [GL #4507]

(cherry picked from commit 454f245a7047571afdfda62978ea75dda119a712)

Add CHANGES note for [GL #4507]

(cherry picked from commit 09ff8b1169f8be6867c0b2004d0369d246ad2994)

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.

(cherry picked from commit 179fb3532ab8d4898ab070b2db54c0ce872ef709)

Merge branch 'security-4480-drop-sig0-support' into 'v9.18.28-release'

[9.18] [CVE-2024-1975] Remove support for SIG(0) message verification

See merge request isc-private/bind9!690

Add release note for GL #4480

Add CHANGES note for [GL #4480]

Adapt the upforwd test to the SIG(0) removal

Change the check so that update with SIG(0) is expected to fail.

Adapt the tsiggss test to the SIG(0) removal

Test that SIG(0) signer is NOT sent to the external socket for
authorization. It MUST NOT be considered a valid signature by
any chance.

Also check that the signer's name does not appear in authsock.pl
output.

Enable stdout autoflush in authsock.pl

With enabled buffering the output gets lost when the process
receives a TERM signal. Disable the buffering.

Document SIG(0) verification removal

Remove support for SIG(0) message verification

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

[9.18] Add a limit to the number of RRs in RRSets

See merge request isc-private/bind9!697

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.

(cherry picked from commit 68b840c731527e01699afaf084559152124b717a)

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.

(cherry picked from commit 558923e5405894cf976d102f0d246a28bdbb400c)

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.

(cherry picked from commit 2825bdb1ae5be801e7ed603ba2455ed9a308f1f7)

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.

(cherry picked from commit 14e5230f897a178221b606c242b8fbcb357704aa)

Check if restart works

(cherry picked from commit 4e69ece8f27f3623a4c7a9100477a5547b94c311)

Switch to inline-signing no

(cherry picked from commit 0949221c07fe102ca608899b21f1f5ac5e271953)

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.

(cherry picked from commit 4c677882e66883670990a771337ecbb5206a6faa)

Remove duplicated empty zone files

(cherry picked from commit 1456b4fc7778b851256107dbc79fb67d45f752f5)

masterformat: rename zone names to reflect intended meaning

(cherry picked from commit d34bfb1eeaa2f8faab80b1620b992b5495e6f88c)

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

(cherry picked from commit 6ce03f75d1935c2e1991e9c0a01c49b0099a58cb)

Test variable rename i->_attempt

(cherry picked from commit 13417eb277cc8a30ee4ddbb6fc02442b0d8e6d3c)

Test variable rename a->rrcount

(cherry picked from commit 338b45ae713cded921fd3e5494ca38bd59ff9ee8)

Add CHANGES and release note for [GL #3403]

(cherry picked from commit 54bcbe9a2af6332ce8ffb7190edf40533404c93d)

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.

(cherry picked from commit 4cfeed912a5e7440f04cb088a461ff47305da2e7)

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.

(cherry picked from commit 7e4530f847c8dc541c5e5bf9f790deed520aaa16)

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.

(cherry picked from commit 00d16211d6368b99f070c1182d8c76b3798ca1db)

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.

(cherry picked from commit 8e3efb4e06ba68cc3f9bc5be2bacb2596bd74cb3)

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.

(cherry picked from commit cee9ad81db6e5a1167b311e5c2f42cf65ba457cd)

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.

(cherry picked from commit 3fbd21f69a1bcbd26c4c00920e7b0a419e8762fc)

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

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

See merge request isc-private/bind9!641

Add CHANGES and release note for [GL #4481]

(cherry picked from commit 3e4babc58e1ed169a25ae9083f8f3c7d3e8389a3)

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).

This reverts commit 780a89012d8627b9284983702dced8a3f65688aa.

Remove the extra memory context with own arena for sending

(cherry picked from commit 8d4cc41c291f8a77a723ae8e62533538b3632d50)

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.

(cherry picked from commit 297cc840fbaf34b9dfa1d02d88a023cd5bf5dc4a)

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.

(cherry picked from commit 26006f7b44474819fac2a76dc6cd6f69f0d76828)

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

[9.18] 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!701

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.

(cherry picked from commit 773a8108f307b4f6cc7776050d85432295b13a4d)

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.

(cherry picked from commit b9b5d0c01a3a546c4a6a8b3bff8ae9dd31fee224)

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.

(cherry picked from commit 0cca550dff403c6100b7c0da8f252e7967765ba7)

Merge branch '4661-confidential-clear-dns-fetchopt-trystale-ontimeout' into 'v9.18.28-release'

Prevent passing DNS_EVENT_TRYSTALE events to resume_dslookup()

See merge request isc-private/bind9!678

Add release note for [GL #4661]

Add CHANGES not for [GL #4661]

Clear DNS_FETCHOPT_TRYSTALE_ONTIMEOUT

When calling dns_resolver_createfetch in resolver.c with a callback
of resume_dslookup, clear DNS_FETCHOPT_TRYSTALE_ONTIMEOUT from
options as DNS_EVENT_TRYSTALE is not an expected event type and
triggers a REQUIRE.

Merge branch '2744-warning-checkhints-unable-to-get-root-ns-rrset-from-cache-not-found-9.18' into 'bind-9.18'

[9.18] Resolve "warning: checkhints: unable to get root NS rrset from cache: not found"

See merge request isc-projects/bind9!9080

Add CHANGES entry for [GL #2744]

(cherry picked from commit 5be6ceebc47e8f87aaa215fedb8618821dbc4e79)

Pass a memory context in to dns_cache_create

(cherry picked from commit 87e3b9dbf378c67a3e6822cedebbac0d57f0c64e)

Use a new memory context when flushing the cache

When the cache's memory context was in over memory state when the
cache was flushed it resulted in LRU cleaning removing newly entered
data in the new cache straight away until the old cache had been
destroyed enough to take it out of over memory state.  When flushing
the cache create a new memory context for the new db to prevent this.

(cherry picked from commit 5e77edd07482a69fdf578e7680a495e00ace8b7b)

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

[9.18] Resolve "ISC_R_HOSTDOWN was not being handled by resolver.c"

See merge request isc-projects/bind9!9088

Add CHANGES note for [GL #4736]

(cherry picked from commit 71cfa8dfbaf92e76717e3149b2bf09cbfd8fc58e)

Update resquery_senddone handling of ISC_R_TIMEDOUT

Treat timed out as an address specific error.

(cherry picked from commit 56c3dcc5d779d0365b385cf393317cae18526949)

Update resquery_senddone handling of ISC_R_CONNECTIONRESET

Treat connection reset as an address specific error.

(cherry picked from commit 4e3dd85b8ddcb3ec7c9e7031ff844a3c4a987c53)

Handle ISC_R_HOSTDOWN and ISC_R_NETDOWN in resolver.c

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

(cherry picked from commit 180b1e79398a7120929c413c7c0392ae15ccf69c)

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

[9.18] Resolve "IPv4-only mode not respected for zone transfers"

See merge request isc-projects/bind9!9085

Add CHANGES note for [GL #6288]

(cherry picked from commit 3834e433f7f625c4f1a177715b96d6eb3c441866)

Don't do DS checks over disabled address families

(cherry picked from commit 05472e63e8930753d7fa8d3bbf840be2085a2f23)

Don't forward UPDATE messages over disabled address families

(cherry picked from commit d026dbe5367df775fdc22a3e05c63710499dcf07)

Don't send NOTIFY over disabled address families

(cherry picked from commit 5d9962551547e13274ff7d7f5af9abf4f4982341)

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.

(cherry picked from commit 07cdf3e94580b99beaa393649e76f760ef6e16c3)

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.

(cherry picked from commit 2cd43032498752d2ab4527475ba21beee133b30b)

Zone transfers should honour -4 and -6 options

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

(cherry picked from commit ecdde04e63277e2bed8d1d861470de80ab0f49e1)

Add helper function isc_sockaddr_disabled

(cherry picked from commit 9be1873ef37a4f20e01dc2ad1e64112b7104d942)

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

[9.18] Add more label checks to dangerfile.py

See merge request isc-projects/bind9!9086

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.

(cherry picked from commit aae51cf28d4466907e152591c8a00525f7ec7038)

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.

(cherry picked from commit 80ec57f198e5706e653ebe2016f41dc6f856db8c)

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.

(cherry picked from commit 09851e62309f55bb3e6e3bc7299db95929827f76)

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.

(cherry picked from commit 9359cb9c99454626b65b3863e10e710a329ca99c)

Merge branch '4708-uv-tcp-close-reset-issue-9.18' into 'bind-9.18'

[9.18] Deal with uv_tcp_close_reset more gracefully

See merge request isc-projects/bind9!9084

Add CHANGES entry for [GL #4708]

(cherry picked from commit 113968f3a04a236fbf5a7f97c1e23154ca72662f)

Call reset_shutdown if uv_tcp_close_reset failed

If uv_tcp_close_reset() returns an error code, this means the
reset_shutdown callback has not been issued, so do it now.

(cherry picked from commit c40e5c865313c8d538650a8bab71fc4c576705c2)

Do not runtime check uv_tcp_close_reset

When we reset a TCP connection by sending a RST packet, do not bother
requiring the result is a success code.

(cherry picked from commit 5b94bb21295560aed8b3f1968fbfae261c57aab9)

Merge branch '4742-tcp4clients-statistic-is-inaccurate' into 'bind-9.18'

Increase TCP4Clients/TCP6Clients after point of no failure

See merge request isc-projects/bind9!9066

Document TCP4Clients/TCP6Clients

Commit abc47f5ce4a50ab2d3b23505914e9c65f856262b added two new statistics
counters without documenting them.  Add the missing counter descriptions
to the ARM.

add CHANGES and release note for GL #4425

increase TCP4Clients/TCP6Clients after point of no failure

Failing to accept TCP/TLS connections in 9.18 detaches the quota in
isc__nm_failed_accept_cb, causing TCP4Clients and TCP6Clients statistics
to not decrease inside cleanup.

Fix by increasing the counter after the point of no failure but before
handling statistics through the client's socket is no longer valid.

Merge branch '4750-set-loop-on-incoming-transfer-9.18' into 'bind-9.18'

[9.18] Create the new database for AXFR from the dns_zone API

See merge request isc-projects/bind9!9075

Create the new database for AXFR from the dns_zone API

The `axfr_makedb()` didn't set the loop on the newly created database,
effectively killing delayed cleaning on such database.  Move the
database creation into dns_zone API that knows all the gory details of
creating new database suitable for the zone.

(cherry picked from commit 3310cac2b0b83e20a8ce2da67d3e5ede9bee4c)

Merge branch 'nicki/use-bind-team-gitlab-tokens-9.18' into 'bind-9.18'

[9.18] Use bind-team tokens for CI gitlab access

See merge request isc-projects/bind9!9068

Use BIND_TEAM_WRITE_TOKEN for autobackport bot

This is done to unify the token usage across our repositories to
simplify token maintenance.

(cherry picked from commit d391f0c9586c619a2ceead562327ebad8840e69d)

Use BIND_TEAM_API_TOKEN for danger bot

This is done to unify the token usage across our repositories to
simplify token maintenance.

(cherry picked from commit 6767172bc0fc2f7fbb44c24144ea40c0836b9913)

Merge branch 'mnowak/alpine-3.20-9.18' into 'bind-9.18'

[9.18] Add Alpine Linux 3.20

See merge request isc-projects/bind9!9060

Add Alpine Linux 3.20

(cherry picked from commit 6f22e79ef99c83498922fccb1c9e5547828f536d)

Merge branch 'mnowak/short-stress-tests-should-keep-artifacts-9.18' into 'bind-9.18'

[9.18] Short stress tests should keep artifacts

See merge request isc-projects/bind9!9057

Short stress tests should keep artifacts

(cherry picked from commit aa72747c808ff55a53d724c7786032a7b522f904)

Merge branch '4730-clang-format-header-file-changes-bind-9.18' into 'bind-9.18'

[9.18] Resolve "Clang format header file changes"

See merge request isc-projects/bind9!9053