The uv_stream_get_write_queue_size() is supported only in relatively newer versions of libuv (1.19.0 or higher). Provide a compatibility shim for this function , so BIND 9 can be built in environments with older libuv version.
Fixes: #4822
Backport of MR !9153
Merge branch 'backport-uv_stream_get_write_queue_size_wrapper-9.16' into 'bind-9.16'
See merge request isc-projects/bind9!9248
The doc/misc/options{,.active} were built on system with different
configuration than we have in the CI, so the docs job just keeps
failing. Pull the files from the CI, so they match what we have
in the CI images.
Merge branch 'ondrej/make-docs-job-happy-9.16' into 'bind-9.16'
See merge request isc-projects/bind9!9242
The doc/misc/options{,.active} were built on system with different
configuration than we have in the CI, so the docs job just keeps
failing. Pull the files from the CI, so they match what we have
in the CI images.
The system tests were overriding the local locale by setting LANG to C.
This does not override the locale in case there are individual LC_<*>
variables like LC_CTYPE explicitly set.
Use LC_ALL=C instead which is the proper way of overriding all currently
set locales.
Backport of MR !9109
Merge branch 'backport-ondrej/use-LC_ALL-not-LANG-9.16' into 'bind-9.16'
See merge request isc-projects/bind9!9237
The system tests were overriding the local locale by setting LANG to C.
This does not override the locale in case there are individual LC_<*>
variables like LC_CTYPE explicitly set.
Use LC_ALL=C instead which is the proper way of overriding all currently
set locales.
When fuzzing it is useful for all signing operations to happen
at a specific time for reproducability. Add two variables to
the message structure (fuzzing and fuzztime) to specify if a
fixed time should be used and the value of that time.
(cherry picked from commit 3e85d8c3d6)
Closes#4777
Backport of MR !9107
Merge branch '4777-retry-job-aws-spot-instance-interruption-event-9.16' into 'bind-9.16'
See merge request isc-projects/bind9!9186
This aligns the fix for large number of RRs in RRSet with 9.18 and up
by backporting to `max-records-per-type` configuration option to
BIND 9.16.
Merge branch 'ondrej/max-types-per-rr-backport-9.16' into 'bind-9.16'
See merge request isc-projects/bind9!9178
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)
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)
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)
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 57cd34441a)
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)
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)
This aligns the fix for large number of RRs in RRSet with 9.18 and up
by backporting to `max-records-per-type` configuration option to
BIND 9.16.
Merge branch 'ondrej/max-records-per-type-backport-9.16' into 'bind-9.16'
See merge request isc-projects/bind9!9177
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 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)
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)
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)
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.
(cherry picked from commit cf8838085905171fbc00747eb210e8b8284ca0e1)
With enabled buffering the output gets lost when the process
receives a TERM signal. Disable the buffering.
(cherry picked from commit a0311dfb6e2a51f89dfa8b200b96a0f4675fb654)
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 57cd34441a)
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 58f660cf2b)
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 b27c6bcce8)
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-rrset configuration option that can
be configured globally, per-view and per-zone.
(cherry picked from commit c5c4d00c38530390c9e1ae4c98b65fbbadfe9e5e)
Not a backport, closes https://gitlab.isc.org/isc-projects/bind9/-/issues/3405 for 9.16
Merge branch '3405-limit-the-number-of-resource-records-in-rrset-9.16' into 'bind-9.16'
See merge request isc-projects/bind9!9170
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 hard-coded limit (100) to cap the number of the RR types for a single
owner. The limit can be changed at the compile time by adding following
define to CFLAGS:
-DDNS_RBTDB_MAX_RTYPES=<limit>
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.
The fix for end-of-life branches make the limit compile-time only for
simplicity and the limit can be changed at the compile time by adding
following define to CFLAGS:
-DDNS_RDATASET_MAX_RECORDS=<limit>
(cherry picked from commit c5c4d00c38530390c9e1ae4c98b65fbbadfe9e5e)
Ondřej Surý
JINMEI TatuyaandOndřej Surý
Petr Špaček
Nicki Křížek
Emanuel PetrandNicki Křížek
Matthijs MekkingandOndřej Surý
Evan HuntandOndřej Surý
Mark AndrewsandNicki Křížek
Aram SargsyanandNicki Křížek