[bind10-dev] recursor cache requirements - input required

[Michal 'vorner' Vaner]

Good morning

On Wed, Dec 08, 2010 at 03:53:13PM +0800, Likun Zhang wrote:
> > 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).

What information are we missing if we have only the rrset cache? We do not need
the flags, we don't need any additional sections (we can find them in the rrset
cache). Authority of the data?

> > 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.

Regarding the functionality, we probably could get away without it.

The expiration in NSAS might be only sooner, in which case it will just update
its data from cache when needed.

But there are two things. First, it seems a waste not to use newer data if we
have them. Second, what happens if there's misconfigured glue somewhere. The
NSAS stores the (wrong) glue, but if it is not wrong too much, we reach some of
the nameservers eventually. It returns answer with authority, so we fix the glue
in cache, but NSAS still has the wrong glue.

> > 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.

I don't see why. If the cache is a hash table, then we need to compute the hash
and then look into a given position in an array. It takes the same amount of
time if the array is small or large.

And, local zone seems to be some kind of zone served by this server. I need to
put there remote data as well.

Why I'd like to search the large one first is, the cache might have never
(better/authoritative) data than the small one. I want to use the better data
from large cache.

What is the advantage of searching the small one first?

Thanks

With regards

-- 
BOFH Excuse #430:

Mouse has out-of-cheese-error

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20101208/af461b60/attachment.bin>