]> git.ipfire.org Git - thirdparty/bind9.git/commit
Stale answer lookups could loop when over recursion quota
authorEvan Hunt <each@isc.org>
Fri, 26 May 2023 06:53:50 +0000 (23:53 -0700)
committerMichal Nowak <mnowak@isc.org>
Fri, 9 Jun 2023 12:54:48 +0000 (14:54 +0200)
commit240caa32b9cab90a38ab863fd64e6becf5d1393c
tree022a53e463f459316f10dca8aa547da1ba6fd3dc
parente9af3d15d81d9b18e8785e7cdb2e605e278f1c1d
Stale answer lookups could loop when over recursion quota

When a query was aborted because of the recursion quota being exceeded,
but triggered a stale answer response and a stale data refresh query,
it could cause named to loop back where we are iterating and following
a delegation. Having no good answer in cache, we would fall back to
using serve-stale again, use the stale data, try to refresh the RRset,
and loop back again, without ever terminating until crashing due to
stack overflow.

This happens because in the functions 'query_notfound()' and
'query_delegation_recurse()', we check whether we can fall back to
serving stale data. We shouldn't do so if we are already refreshing
an RRset due to having prioritized stale data in cache.

In other words, we need to add an extra check to 'query_usestale()' to
disallow serving stale data if we are currently refreshing a stale
RRset.

As an additional mitigation to prevent looping, we now use the result
code ISC_R_ALREADYRUNNING rather than ISC_R_FAILURE when a recursion
loop is encountered, and we check for that condition in
'query_usestale()' as well.
lib/ns/query.c