[bind10-dev] recursor cache requirements - input required

[Jerry Scharf]

Likun,

I like Shane's idea of one class per cache. Since the cache in not a 
once per server entity (each view requires its own cache), if someone 
wants hesiod queries (the only other class I know of) build a separate 
cache for that. It will decrease the size and increase the speed of each 
class in this case.


I do not think you should keep any message in the cache. I have been 
involved in more than one recursive server and have never seen the 
response message from the upstream cache fill or the answer created for 
the client kept. You always have to regenerate the answer from the 
validated data in the cache to prevent cache poisoning attacks, so 
keeping the upstream message is a bad idea. You also have situations 
where the answer from before is no longer correct. (a classic example of 
this is that the first answer used the glue NS rrset for the authority 
data and that rrset was later replaced by the authoritative zone NS 
rrset or a new query within the zone included a new NS rrset in its 
authority section.) You need to build everything you need from the 
current cache information.

Getting the answer rrset or an error from cache is simple. You just walk 
down the logical namespace hierarchy until you find the cache entry.

Building the authority section is not too hard either. You want to flag 
any node that is a zone cut (apex) in the cache. As you walk down, you 
remember the last zone cut you saw. When you get to the answer, you go 
back to the nearest zone cut and get the NS rrset. There are some 
differences on whether to put an optimization for finding/keeping the 
associated A/AAAA records for the NS RRs for the additional section. 
I've seen fast servers that did not have that and others that did.

jerry