[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