[bind10-dev] a different idea on the cache for DB backed zones
Jerry Scharf
scharf at isc.org
Fri Jan 21 23:33:55 UTC 2011
At last week's F2F, I was really disappointed to hear how slow the
hostspot cache had been for the DB backed zones. It got me thinking
(which is always a dangerous idea.)
This led me to a potentially good or bad possibility for caching in
front of the DB. Why not use a slightly tweaked recursive server as the
fronting cache for the authoritative server when it's not running out of
memory?
There are a few benefits I see for this. I expect the recursive server
to be a whole bunch faster than current hotspot numbers. I expect the
recursive server to get a good amount of work on scaling across multiple
cores. The cache eviction method for hotspot wasn't very smart, I expect
the recursive server to be better with better invalidation control. This
also gives a path for a combined auth/recursive server.
I know this invalidates much of the premise that the auth and recursive
modules are separate, but it seems like something that should be discussed.
I was thinking of how much modification it would take to take the BIND
10 recursive server and change it to be a cache for DB backed
authoritative zones. Here's what I have so far:
The fill (upstream) side would need to be replaced with something that
hit the DB and skipped all the normal upstream processing. It would also
want to know the sections of the namespace that are active so it can
bounce queries for anything else without hitting the DB (this may
actually want to happen even before the cache is searched.)
The cache search side would need to know how to capture and handle
downward delegations off the server.
The cache would need to keep the TTL separate from the expire time since
TTLs are not decremented like they are on a recursive server. This may
also impact the cache recovery when size limits are hit.
The cache would need the ability to deal with changes in the DNS data.
One way would simply be to invalidate the entire namespace below an apex
in the cache. Another would be to invalidate things based on an
difference method like that needed for IXFR (only need the deletes and
changes.)
There may be implementation specific issues as well.
jerry
More information about the bind10-dev
mailing list