new: dev: generate changelog from git log

Use a single source of truth, the git log, to generate the list of CHANGES. Use the .rst format and include it in the ARM for a quick reference with proper gitlab links to issues and merge requests.

Closes #75

Merge branch 'nicki/add-gitchangelog' into 'main'

Closes #75

See merge request isc-projects/bind9!9152

Update docs and processes to use the new changelog

Update dangerfile for new changelog workflow

Skip pylint checks for contrib directory

The files in contrib/ directory shouldn't be subject to our pylint
check. They can come from external sources and we don't subject these to
the same standards as the rest of the BIND9 code / scripts.

Remove changes job and related scripts

These are no longer needed, since changelog is generated using
gitchangelog.

Add BIND9 configuration for gitchangelog

The configuration has been crafted to cater for BIND9 needs:
- Define actions that have an equivalent section in existing Release
  Notes
- Assume the commits that have the necessary changelog makrup are merge
  commits from GitLab and transform them into messages and proper links
- Put the resulting changelog into the proper place in
  doc/arm/changelog.rst
- Have a separate configuration for changelog and release notes. Both of
  these should be generated from the `git log`, with release notes being
  subject to more scrutiny and further editing

Add new changelog file

Create new changelog and include it in the documentation. Include the
previous CHANGES as plain text without any markup.

Address gitchangelog deprecation warning

Adjust gitchangelog whitespace

Format the output to produce a nicer looking rst output, similar to the
former CHANGES file.

Allow gitchangelog to include commit sha

Add an option which can be used to put short commit sha at the end of
each commit subject line in the generated changelog.

Remove authors from gitchangelog output

Given our workflow, this could easily lead to misattribution. It's also
not an actionable information and it can be found in the MR / git log
instead.

Reformat gitchangelog with black

Import gitchanglog 3.0.4

The  project hasn't seen any new development/changes since 2018 and it
seems unlikely we'd be able to get any changes into the upstream. Since
it's isolated into a single file and its task is fairly straighforward,
pull the code into our own repository and maintain it here as needed.

This also makes it easier to make any changes that are specific to our
project.

Set up version and release notes for BIND 9.21.0

Merge branch 'nicki/set-up-version-and-release-notes-for-bind-9.21.0' into 'main'

See merge request isc-projects/bind9!9166

Set up release notes for BIND 9.21.0

Update BIND version to 9.21.0-dev

Merge tag 'v9.20.0'

Update BIND version to 9.20.0

Add a CHANGES marker

Merge branch 'nicki/prepare-documentation-for-bind-9.20.0' into 'v9.20.0-release'

Prepare documentation for BIND 9.20.0

See merge request isc-private/bind9!710

Update documentation for 9.20.0

Create release notes for 9.20.0

Extend max-types-per-name documentation

Document new -J option for dnssec-signzone and dnssec-verify

Reorder release notes

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]