]> git.ipfire.org Git - thirdparty/bind9.git/commit
Fix a clients-per-query miscalculation bug
authorAram Sargsyan <aram@isc.org>
Sat, 27 May 2023 11:01:28 +0000 (11:01 +0000)
committerAram Sargsyan <aram@isc.org>
Thu, 1 Jun 2023 08:13:09 +0000 (08:13 +0000)
commit2ae5c4a674ef2d43c145c8486becc92aa26fff58
treefc4ebc085f4a7fee45951126eddff024a569a3a5
parent3bb2babcd075df1da244e8c6f178e1cb99d3e123
Fix a clients-per-query miscalculation bug

The number of clients per query is calculated using the pending
fetch responses in the list. The dns_resolver_createfetch() function
includes every item in the list when deciding whether the limit is
reached (i.e. fctx->spilled is true). Then, when the limit is reached,
there is another calculation in fctx_sendevents(), when deciding
whether it is needed to increase the limit, but this time the TRYSTALE
responses are not included in the calculation (because of early break
from the loop), and because of that the limit is never increased.

A single client can have more than one associated response/event in the
list (currently max. two), and calculating them as separate "clients"
is unexpected. E.g. if 'stale-answer-enable' is enabled and
'stale-answer-client-timeout' is enabled and is larger than 0, then
each client will have two events, which will effectively halve the
clients-per-query limit.

Fix the dns_resolver_createfetch() function to calculate only the
regular FETCHDONE responses/events.

Change the fctx_sendevents() function to also calculate only FETCHDONE
responses/events. Currently, this second change doesn't have any impact,
because the TRYSTALE events were already skipped, but having the same
condition in both places will help prevent similar bugs in the future
if a new type of response/event is ever added.
lib/dns/resolver.c