BIND merge requestshttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests2019-03-20T08:26:33Zhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/145Resolve "Update the default for dnssec-validation to auto"2019-03-20T08:26:33ZOndřej SurýResolve "Update the default for dnssec-validation to auto"This MR changes the default on dnssec-validation from to 'auto', and add a configure option to revert to disable the automatic DNSSEC validation at compile time.
Closes #30This MR changes the default on dnssec-validation from to 'auto', and add a configure option to revert to disable the automatic DNSSEC validation at compile time.
Closes #30BIND-9.13.1Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8924[9.16] [CVE-2023-5679] Check dns64 + server-stale short timeout2024-03-28T17:57:59ZMichał Kępień[9.16] [CVE-2023-5679] Check dns64 + server-stale short timeoutBackport of !8922
Closes #4334Backport of !8922
Closes #4334April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8922[9.18] [CVE-2023-5679] Check dns64 + server-stale short timeout2024-03-28T15:04:46ZMichał Kępień[9.18] [CVE-2023-5679] Check dns64 + server-stale short timeoutCheck that named correctly returns a synthesized DNS64 answer when the
server stale timer triggers for the A lookup. Use a small value for
stale-answer-client-timeout (2ms) and delay the A response by 1 second.
As pointed out [elsewher...Check that named correctly returns a synthesized DNS64 answer when the
server stale timer triggers for the A lookup. Use a small value for
stale-answer-client-timeout (2ms) and delay the A response by 1 second.
As pointed out [elsewhere][1], it makes no sense to merge this test to
~"v9.19" any more, so it will only be merged into ~"v9.18" & ~"v9.16".
Closes #4334
[1]: https://gitlab.isc.org/isc-private/bind9/-/merge_requests/590#note_449136April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8851[9.16] Test secure chain that includes inactive KSK2024-03-12T12:49:00ZMatthijs Mekkingmatthijs@isc.org[9.16] 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)
Closes #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/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/8848Fix validate_dnskey_dsset when KSK is not signing2024-03-20T10:32:00ZMatthijs Mekkingmatthijs@isc.orgFix validate_dnskey_dsset when KSK is not signingWhen there is a secure chain of trust with a KSK that is not actively signing the DNSKEY RRset, the code for validating the DNSKEY RRset against the DS RRset could potentially skip DS records, thinking the
chain of trust is broken while ...When there is a secure chain of trust with a KSK that is not actively signing the DNSKEY RRset, the code for validating the DNSKEY RRset against the DS RRset could potentially skip DS records, thinking the
chain of trust is broken while there is a valid DS with corresponding DNSKEY record present.
This is because we pass the result ISC_R_NOMORE on when we are done checking for signatures, but then treat it as "no more DS records".
Changing the return value to something else (DNS_R_NOVALIDSIG seems the most appropriate here) fixes the issue.
Closes #4625March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8838Resolve "dns_db_setloop at wrong place in cache_create_db"2024-03-08T11:48:34ZMark AndrewsResolve "dns_db_setloop at wrong place in cache_create_db"Closes #4623Closes #4623March 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/8836[9.16.49] Move the task creation into cache_create_db()2024-03-08T11:46:07ZMichał Kępień[9.16.49] Move the task creation into cache_create_db()Cherry-pick of !8831
Closes #4621Cherry-pick of !8831
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/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/8834Move the dns_db_setloop into cache_create_db()2024-03-08T11:45:37ZOndřej SurýMove the dns_db_setloop into cache_create_db()The dns_cache_flush() drops the old database and creates a new one, but
it forgets to pass the loop that runs the node pruning and cleaning
the rbtdb when flushing it next time. This causes the cleaning to skip
cleaning the parent nodes...The dns_cache_flush() drops the old database and creates a new one, but
it forgets to pass the loop 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.
Closes #4621March 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/8831[9.16] Move the task creation into cache_create_db()2024-03-08T11:42:17ZOndřej Surý[9.16] Move the task creation into cache_create_db()Backport of !8823 and !8830
Closes #4621
See also #4596Backport of !8823 and !8830
Closes #4621
See also #4596May 2024 (9.18.27, 9.18.27-S1, 9.19.24)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/8815[9.16.49] Check the prunelink member of the correct node2024-03-02T05:39:34ZMichał Kępień[9.16.49] Check the prunelink member of the correct nodeCherry-pick of !8814
Closes #4596Cherry-pick of !8814
Closes #4596March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8814[9.16] Check the prunelink member of the correct node2024-03-07T22:13:52ZMichał Kępień[9.16] Check the prunelink member of the correct nodeCommit 4b6fc97af6f936616a12e733b14ffc450af6df87 checks the prunelink
member of the node that was just pruned, not its parent node that was
intended to be examined. Fix by checking the prunelink member of the
parent node, so that adding ...Commit 4b6fc97af6f936616a12e733b14ffc450af6df87 checks the prunelink
member of the node that was just pruned, not its parent node that was
intended to be examined. Fix by checking the prunelink member of the
parent node, so that adding the latter to its relevant prunenodes list
twice is properly guarded against.
Closes #4596May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8811[9.16.49] Do not re-add a node to the same prunenodes list2024-03-08T11:52:09ZMichał Kępień[9.16.49] Do not re-add a node to the same prunenodes listCherry-pick of !8810
Closes #4596Cherry-pick of !8810
Closes #4596March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8810[9.16] Do not re-add a node to the same prunenodes list2024-03-07T22:13:57ZMichał Kępień[9.16] Do not re-add a node to the same prunenodes listIf a node cleaned up by prune_tree() happens to belong to the same node
bucket as its parent, the latter is directly appended to the prunenodes
list currently processed by prune_tree(). However, the relevant code
branch does not account...If a node cleaned up by prune_tree() happens to belong to the same node
bucket as its parent, the latter is directly appended to the prunenodes
list currently processed by prune_tree(). However, the relevant code
branch does not account for the fact that the parent might already be on
the list it is trying to append it to. Fix by only calling
ISC_LIST_APPEND() for parent nodes not yet added to their relevant
prunenodes list.
Closes #4596May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8805[9.16.49] Gracefully handle resending a node to prune_tree()2024-03-01T17:22:06ZMichał Kępień[9.16.49] Gracefully handle resending a node to prune_tree()Cherry-pick of !8804
Closes #4596Cherry-pick of !8804
Closes #4596March 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/8804[9.16] Gracefully handle resending a node to prune_tree()2024-03-07T22:14:00ZMichał Kępień[9.16] Gracefully handle resending a node to prune_tree()Commit 2df147cb1264b30c7f26c1d75310a010615687bc made the prune_tree()
function use send_to_prune_tree() for triggering pruning of deleted leaf
nodes' parents. This enabled the following sequence of events to
happen:
1. Node A, which i...Commit 2df147cb1264b30c7f26c1d75310a010615687bc made the prune_tree()
function use send_to_prune_tree() for triggering pruning of deleted leaf
nodes' parents. This enabled the following sequence of events to
happen:
1. Node A, which is a leaf node, is passed to send_to_prune_tree() and
its pruning is queued.
2. Node B is added to the RBTDB as a child of node A before the latter
gets pruned.
3. Node B, which is now a leaf node itself (and is likely to belong to
a different node bucket than node A), is passed to
send_to_prune_tree() and its pruning gets queued.
4. Node B gets pruned. Its parent, node A, now becomes a leaf again
and therefore the prune_tree() call that handled node B calls
send_to_prune_tree() for node A.
5. Since node A was already queued for pruning in step 1 (but not yet
pruned), the INSIST(!ISC_LINK_LINKED(node, prunelink)); assertion
fails for node A in send_to_prune_tree().
The above sequence of events is not a sign of pathological behavior.
Replace the assertion check with a conditional early return from
send_to_prune_tree().
Closes #4596May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8802[9.16.49] Remove expired rdataset headers from the heap2024-03-10T06:46:32ZOndřej Surý[9.16.49] 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 abe080d16eac4f5dcca62cb08bd9ca2f82bdaa2b)
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ý