BIND merge requestshttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests2024-03-12T10:10:59Zhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8850[9.18] Test secure chain that includes inactive KSK2024-03-12T10:10:59ZMatthijs Mekkingmatthijs@isc.org[9.18] Test secure chain that includes inactive KSKPartial Backport of MR !8848
Add a regression test case for the scenario where a secure chain of trust includes an inactive KSK, that is a KSK that is not signing the DNSKEY RRset.
(cherry picked from commit f0bfd276e02f861b7a98d569b03...Partial Backport of MR !8848
Add a regression test case for the scenario where a secure chain of trust includes an inactive KSK, that is a KSK that is not signing the DNSKEY RRset.
(cherry picked from commit f0bfd276e02f861b7a98d569b03e267b0261f599)
Also see #4625May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8835[9.18.25] Move the task creation into cache_create_db()2024-03-08T11:47:36ZMichał Kępień[9.18.25] Move the task creation into cache_create_db()Cherry-pick of !8830
Closes #4621Cherry-pick of !8830
Closes #4621March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8830[9.18] Move the task creation into cache_create_db()2024-03-08T11:42:17ZOndřej Surý[9.18] Move the task creation into cache_create_db()The dns_cache_flush() drops the old database and creates a new one, but
it forgets to create the task(s) that runs the node pruning and cleaning
the rbtdb when flushing it next time. This causes the cleaning to skip
cleaning the parent ...The dns_cache_flush() drops the old database and creates a new one, but
it forgets to create the task(s) that runs the node pruning and cleaning
the rbtdb when flushing it next time. This causes the cleaning to skip
cleaning the parent nodes (with .down == NULL) leading to increased
memory usage over time until the database is unable to keep up and just
stays overmem all the time.
Also includes a backport of !8823
Closes #4621
See also #4596May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8823Restore the parent cleaning logic in prune_tree()2024-03-08T11:42:16ZOndřej SurýRestore the parent cleaning logic in prune_tree()Reconstruct the variant of the prune_tree() parent cleaning to consider
all elibible parents in a single loop as we were doing before all the
changes that led to this commit.Reconstruct the variant of the prune_tree() parent cleaning to consider
all elibible parents in a single loop as we were doing before all the
changes that led to this commit.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8801[9.18.25] Remove expired rdataset headers from the heap2024-03-10T06:46:32ZOndřej Surý[9.18.25] Remove expired rdataset headers from the heapIt was discovered that an expired header could sit on top of the heap
a little longer than desireable. Remove expired headers (headers with
rdh_ttl set to 0) from the heap completely, so they don't block the next
TTL-based cleaning.
(c...It was discovered that an expired header could sit on top of the heap
a little longer than desireable. Remove expired headers (headers with
rdh_ttl set to 0) from the heap completely, so they don't block the next
TTL-based cleaning.
(cherry picked from commit a9383e4b95256a65f9f05e64a79b086a9a1ed035)
(cherry picked from commit 756555dbcf8b813942420f8ec059c2df9e543308)
Closes #4591
Backport of !8754March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8796[9.18.25] Reduce lock contention during RBTDB tree pruning2024-03-10T06:42:21ZOndřej Surý[9.18.25] Reduce lock contention during RBTDB tree pruningThe log message for commit a9af1ac5ae67d266a913ba8a7118ac6f47723d95
explained:
In some older BIND 9 branches, the extra queuing overhead eliminated by
this change could be remotely exploited to cause excessive memory use.
Du...The log message for commit a9af1ac5ae67d266a913ba8a7118ac6f47723d95
explained:
In some older BIND 9 branches, the extra queuing overhead eliminated by
this change could be remotely exploited to cause excessive memory use.
Due to architectural shift, this branch is not vulnerable to that issue,
but applying the fix to the latter is nevertheless deemed prudent for
consistency and to make the code future-proof.
However, it turned out that having a single queue for the nodes to be
pruned increased lock contention to a level where cleaning up nodes from
the RBTDB took too long, causing the amount of memory used by the cache
to grow indefinitely over time.
This commit reverts the change to the pruning mechanism introduced by
commit a9af1ac5ae67d266a913ba8a7118ac6f47723d95 as BIND branches newer
than 9.16 were not affected by the excessive event queueing overhead
issue mentioned in the log message for the above commit.
(cherry picked from commit eed17611d8ceeb99ec3ff282aaea4d38bd334932)
(cherry picked from commit 4b32456705a9812ee21b815da361fe1adf1f1b94)
Closes #4596
Backport of !8765March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8776[9.18] Do not use header_prev in expire_lru_headers2024-03-08T11:03:31ZOndřej Surý[9.18] Do not use header_prev in expire_lru_headersdns__cacherbt_expireheader can unlink / free header_prev underneath
it. Use ISC_LIST_TAIL after calling dns__cacherbt_expireheader
instead to get the next pointer to be processed.
(cherry picked from commit 7ce2e86024f022decb2678963538...dns__cacherbt_expireheader can unlink / free header_prev underneath
it. Use ISC_LIST_TAIL after calling dns__cacherbt_expireheader
instead to get the next pointer to be processed.
(cherry picked from commit 7ce2e86024f022decb2678963538515ca39ab4ab)
Closes #4595
Backport of !8773March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8773Do not use header_prev in expire_lru_headers2024-03-08T11:03:30ZOndřej SurýDo not use header_prev in expire_lru_headersdns__cacherbt_expireheader can unlink / free header_prev underneath
it. Use ISC_LIST_TAIL after calling dns__cacherbt_expireheader
instead to get the next pointer to be processed.
Closes #4595dns__cacherbt_expireheader can unlink / free header_prev underneath
it. Use ISC_LIST_TAIL after calling dns__cacherbt_expireheader
instead to get the next pointer to be processed.
Closes #4595March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8766[9.18] Remove the contention when pruning RBTDB nodes2024-03-10T06:42:20ZOndřej Surý[9.18] Remove the contention when pruning RBTDB nodesIn #4383, we reported:
In some older BIND 9 branches, the extra queuing overhead eliminated by
this change could be remotely exploited to cause excessive memory use.
Due to architectural shift, this branch is not vulnerable ...In #4383, we reported:
In some older BIND 9 branches, the extra queuing overhead eliminated by
this change could be remotely exploited to cause excessive memory use.
Due to architectural shift, this branch is not vulnerable to that issue,
but applying the fix to the latter is nevertheless deemed prudent for
consistency and to make the code future-proof.
The single queue for pruning the nodes increased the lock contention to
the level where cleaning up nodes from the RBTDB would take too long and
the memory that the cache was using would grow indefinitely.
This commit reverts the change to the pruning mechanism as the 9.18+
release was not affected by affor mentioned problem with queueing
overhead.
Closes #4596
Backport of !8765May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8765Reduce lock contention during RBTDB tree pruning2024-03-10T06:42:19ZOndřej SurýReduce lock contention during RBTDB tree pruningIn #4383, we reported:
In some older BIND 9 branches, the extra queuing overhead eliminated by
this change could be remotely exploited to cause excessive memory use.
Due to architectural shift, this branch is not vulnerable ...In #4383, we reported:
In some older BIND 9 branches, the extra queuing overhead eliminated by
this change could be remotely exploited to cause excessive memory use.
Due to architectural shift, this branch is not vulnerable to that issue,
but applying the fix to the latter is nevertheless deemed prudent for
consistency and to make the code future-proof.
The single queue for pruning the nodes increased the lock contention to
the level where cleaning up nodes from the RBTDB would take too long and
the memory that the cache was using would grow indefinitely.
This commit reverts the change to the pruning mechanism as the 9.18+
release was not affected by affor mentioned problem with queueing
overhead.
Closes #4596March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8762Draft: Revert "Merge branch '4383-limit-tree-pruning-overhead-9.18' into 'v9....2024-02-22T08:26:56ZOndřej SurýDraft: Revert "Merge branch '4383-limit-tree-pruning-overhead-9.18' into 'v9.18.22-release'"This reverts commit febc027ea49c75d0b836415c4a94e1a9c5fa7b34, reversing
changes made to efbe5b660d8663e54fbaece087f930eab11d8784.
Closes #4383This reverts commit febc027ea49c75d0b836415c4a94e1a9c5fa7b34, reversing
changes made to efbe5b660d8663e54fbaece087f930eab11d8784.
Closes #4383Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8761Draft: WIP: Make prunenodes bucketed and don't hold the tree lock for too long2024-02-22T08:14:37ZOndřej SurýDraft: WIP: Make prunenodes bucketed and don't hold the tree lock for too longCloses #4383Closes #4383Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8760Revert "Merge branch '4383-limit-tree-pruning-overhead' into 'v9.19.20-release'"2024-02-22T07:58:42ZOndřej SurýRevert "Merge branch '4383-limit-tree-pruning-overhead' into 'v9.19.20-release'"This reverts commit 07dce62da4625217765c27fe4ca2f41f9cc13d33, reversing
changes made to cddf3b267b4865c6fc9c65a3de06aacfda096db9.
Closes #4383This reverts commit 07dce62da4625217765c27fe4ca2f41f9cc13d33, reversing
changes made to cddf3b267b4865c6fc9c65a3de06aacfda096db9.
Closes #4383Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8755[9.18] Remove expired rdataset headers from the heap2024-03-10T06:46:31ZOndřej Surý[9.18] Remove expired rdataset headers from the heapIt was discovered that an expired header could sit on top of the heap
a little longer than desireable. Remove expired headers (headers with
rdh_ttl set to 0) from the heap completely, so they don't block the next
TTL-based cleaning.
Cl...It was discovered that an expired header could sit on top of the heap
a little longer than desireable. Remove expired headers (headers with
rdh_ttl set to 0) from the heap completely, so they don't block the next
TTL-based cleaning.
Closes #4591
Backport of !8754May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8754Remove expired rdataset headers from the heap2024-03-10T06:46:31ZOndřej SurýRemove expired rdataset headers from the heapIt was discovered that an expired header could sit on top of the heap
a little longer than desireable. Remove expired headers (headers with
rdh_ttl set to 0) from the heap completely, so they don't block the next
TTL-based cleaning.
Cl...It was discovered that an expired header could sit on top of the heap
a little longer than desireable. Remove expired headers (headers with
rdh_ttl set to 0) from the heap completely, so they don't block the next
TTL-based cleaning.
Closes #4591March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8730[9.18] Resolve "findnsec3proofs failed to disassociate all rdatasets returned...2024-03-08T08:24:37ZMark Andrews[9.18] Resolve "findnsec3proofs failed to disassociate all rdatasets returned by dns_ncache_current"Backport of MR !8725
Closes #4571Backport of MR !8725
Closes #4571May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8725Resolve "findnsec3proofs failed to disassociate all rdatasets returned by dns...2024-03-08T08:24:37ZMark AndrewsResolve "findnsec3proofs failed to disassociate all rdatasets returned by dns_ncache_current"Closes #4571Closes #4571March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8690[9.18] Fix the DNS_GETDB_STALEFIRST flag2024-03-08T05:41:26ZArаm Sаrgsyаn[9.18] Fix the DNS_GETDB_STALEFIRST flagBackport of !8683.Backport of !8683.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8683Fix the DNS_GETDB_STALEFIRST flag2024-03-08T05:41:25ZArаm SаrgsyаnFix the DNS_GETDB_STALEFIRST flagThe DNS_GETDB_STALEFIRST flag is defined as 0x0C, which is the
combination of the DNS_GETDB_PARTIAL (0x04) and the
DNS_GETDB_IGNOREACL (0x08) flags (0x04 | 0x08 == 0x0C) , which is
an obvious error.
All the flags should be power of two,...The DNS_GETDB_STALEFIRST flag is defined as 0x0C, which is the
combination of the DNS_GETDB_PARTIAL (0x04) and the
DNS_GETDB_IGNOREACL (0x08) flags (0x04 | 0x08 == 0x0C) , which is
an obvious error.
All the flags should be power of two, so they don't interfere with
each other. Fix the DNS_GETDB_STALEFIRST flag by setting it to 0x10.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8556[9.18] Resolve "Improve LRU cleaning behaviour" !85162023-12-08T12:19:53ZMark Andrews[9.18] Resolve "Improve LRU cleaning behaviour" !8516Backport of MR !8516
Closes #4448Backport of MR !8516
Closes #4448December 2023 (9.18.21, 9.18.21-S1, 9.19.19)