8cc5abff23
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.
To use the Dynamic DB sample driver, run named and check the log.
$ cd testing
$ named -gc named.conf
You should be able to see something like:
zone test/IN: loaded serial 0
zone arpa/IN: loaded serial 0
This means that the sample driver created empty zones "test." and
"arpa." as defined by "arg" parameters in named.conf.
$ dig @localhost test.
should work as usual and you should be able to see the dummy zone with
NS record pointing to the zone apex and A record with 127.0.0.1:
;; ANSWER SECTION:
test. 86400 IN A 127.0.0.1
test. 86400 IN NS test.
test. 86400 IN SOA test. test. 0 28800 7200 604800 86400
This driver creates two empty zones and allows query/transfer/update to
all IP addresses for demonstration purposes.
The driver wraps the RBT database implementation used natively by BIND,
and modifies the addrdataset() and substractrdataset() functions to do
additional work during dynamic updates.
A dynamic update modifies the target zone as usual. After that, the
driver detects whether the modified RR was of type A or AAAA, and if so,
attempts to appropriately generate or delete a matching PTR record in
one of the two zones managed by the driver.
E.g.:
$ nsupdate
> update add a.test. 300 IN A 192.0.2.1
> send
will add the A record
a.test. 300 IN A 192.0.2.1
and also automatically generate the PTR record
1.2.0.192.in-addr.arpa. 300 IN PTR a.test.
AXFR and RR deletion via dynamic updates should work as usual. Deletion
of a type A or AAAA record should delete the corresponding PTR record
too.
The zone is stored only in memory, and all changes will be lost on
reload/reconfig.
Hints for code readers:
- Driver initialization starts in driver.c: dyndb_init() function.
- New database implementation is registered by calling dns_db_register()
and passing a function pointer to it. This sample uses the function
create_db() to initialize the database.
- Zones are created later in instance.c: load_sample_instance_zones().
- Database entry points are in structure db.c: dns_dbmethods_t
sampledb_methods
- sampledb_methods points to an implementation of the database interface.
See the db.c: addrdataset() implementation and look at how the RBT
database instance is wrapped into an additional layer of logic.