[bind10-dev] recursor cache requirements - input required

[Likun Zhang]

Michal

> I'm not sure, but when do we want to lookup the whole message? The recursor
> will build the answer from the RR sets anyway as far as I understand it. So
> keeping the message (which would have to be split and rebuilt from RR sets
> already in the
> cache) seems unneeded and wasteful (and harder to implement).
> 
> How about an interface where we would put a dns message into the cache, it
> would split it and store only the RR sets and we could ask for individual RR sets
> then?

Only a rrset cache will not work, since you don't know how to generate one query result from these rrsets. You need to cache the messages(query results).

> And also the level of authoritativity (if it is authoritative or not, we want to cache
> the glue, but only if we do not have a better source already and we want to
> replace the glue once we have anything better).

Yes, agree.

> We should not update if we have authoritative data and what we got is not
> authoritative.
> 

Agree

> And there should be a mechanism the cache would be able to inform that data in
> some already existing RRset has changed (NSAS needs that, it does little bit of its
> own caching. If it times out, it is OK, it just asks the cache again, but it does not
> know when the cache gets different data than it had and needs to update).
> 

I am not sure here, whether we must update NSAS together rrset cache, since every address entry in NSAS has its expiration time, even it may be different with the entry in rrset cache. Every dns authoritative server operator should know the cache feature in recursor side when s/he want to update one zone.

> Also, the cache should be able to cache negative answers (returning NULL means
> it does not know anything about the entity, while there is need to be able to say
> „I know this does not exist“).

Agree.

> And, reading someones notes about how the recursor works (I think it was Evan),
> it seemed the recursor needs to ask the cache for nearest zone cut above the
> name (eg. the longest match for NS or SOA records).

I don't think we need provide the interface for query nearest zone cut about the name, just you said above, we already cache negative answer, extra code for query nearest zone cut should be written above the cache.


> The NSAS relies on cache in few places, and to the level that the cache will
> answer with the glue if there was some. However, there's a problem the cache
> might want to evict them (too small cache and too much data there) or TTL with 0.
> So something like a cache cookie is needed there ‒ a piece of data that would
> guarantee existence of the data in case the cookie is given to the cache with a
> request. The idea behind it would be that the cookie contains a smaller version of
> the cache, with only the RR sets from the given message (or, shared pointers to
> it). The cache would look into itself first and if found, it would work the usual way.
> If not, it would look into the smaller cache in cookie and provide the answer from
> there.

I agree with the feature, but I would like to search the small cookie cache first, the idea is same with unbound.
Unbound has two types of rrset cache, L1 and L2. L1 cache only includes the rrsets in "local zone", and the entry in it is fixed and never be removed. L2 cache include the rrsets that may be added or removed frequently. L1 cache is always searched first.

Likun