mirror of
https://github.com/isc-projects/bind9.git
synced 2026-02-27 03:51:16 -05:00
4827ad0ec4
Before this update, BIND would attempt to do a full recursive resolution process for each query received if the requested rrset had its ttl expired. If the resolution fails for any reason, only then BIND would check for stale rrset in cache (if 'stale-cache-enable' and 'stale-answer-enable' is on). The problem with this approach is that if an authoritative server is unreachable or is failing to respond, it is very unlikely that the problem will be fixed in the next seconds. A better approach to improve performance in those cases, is to mark the moment in which a resolution failed, and if new queries arrive for that same rrset, try to respond directly from the stale cache, and do that for a window of time configured via 'stale-refresh-time'. Only when this interval expires we then try to do a normal refresh of the rrset. The logic behind this commit is as following: - In query.c / query_gotanswer(), if the test of 'result' variable falls to the default case, an error is assumed to have happened, and a call to 'query_usestale()' is made to check if serving of stale rrset is enabled in configuration. - If serving of stale answers is enabled, a flag will be turned on in the query context to look for stale records: query.c:6839 qctx->client->query.dboptions |= DNS_DBFIND_STALEOK; - A call to query_lookup() will be made again, inside it a call to 'dns_db_findext()' is made, which in turn will invoke rbdb.c / cache_find(). - In rbtdb.c / cache_find() the important bits of this change is the call to 'check_stale_header()', which is a function that yields true if we should skip the stale entry, or false if we should consider it. - In check_stale_header() we now check if the DNS_DBFIND_STALEOK option is set, if that is the case we know that this new search for stale records was made due to a failure in a normal resolution, so we keep track of the time in which the failured occured in rbtdb.c:4559: header->last_refresh_fail_ts = search->now; - In check_stale_header(), if DNS_DBFIND_STALEOK is not set, then we know this is a normal lookup, if the record is stale and the query time is between last failure time + stale-refresh-time window, then we return false so cache_find() knows it can consider this stale rrset entry to return as a response. The last additions are two new methods to the database interface: - setservestale_refresh - getservestale_refresh Those were added so rbtdb can be aware of the value set in configuration option, since in that level we have no access to the view object. |
||
|---|---|---|
| .. | ||
| include | ||
| tests | ||
| win32 | ||
| api | ||
| client.c | ||
| hooks.c | ||
| interfacemgr.c | ||
| lib.c | ||
| listenlist.c | ||
| log.c | ||
| Makefile.am | ||
| notify.c | ||
| query.c | ||
| server.c | ||
| sortlist.c | ||
| stats.c | ||
| update.c | ||
| xfrout.c | ||