#200 Support BIND 9.16.9
Merged 2 months ago by abbra. Opened 2 months ago by pemensik.
pemensik/bind-dyndb-ldap bind-9.16.9-support  into  master

file modified
+4
@@ -959,6 +959,10 @@ 

  	setservestalettl,

  	getservestalettl,

  #endif

+ #if LIBDNS_VERSION_MAJOR >= 1609

+ 	NULL, /* setservestalerefresh */

+ 	NULL, /* getservestalerefresh */

+ #endif

  #if LIBDNS_VERSION_MAJOR >= 1600

  	NULL, /* setgluecachestats */

  #endif

Two new functions were added to database interface. They are more
related to caching server and not authoritative. Add just null pointers,
returning not supporter error if used.

Thanks. This comes from this bind9 commit:

commit 8cc5abff23b51b14143ba8661c17045adae935f4
Author: Diego Fronza <diego@isc.org>
Date:   Mon Oct 19 17:02:03 2020 -0300

    Add stale-refresh-time option

    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.

It is pretty bad that these two were added in the middle of the structure rather than at the end but your fix is correct, I only wanted to provide more details on it.

Pull-Request has been merged by abbra

2 months ago
Metadata