[bind10-dev] recursor cache requirements - input required

[Michal 'vorner' Vaner]

Hello

(Sorry, Likun, for the duplicity, but I forgot again to reply to the list)

On Tue, Dec 07, 2010 at 04:55:20PM +0800, Likun Zhang wrote:
> Since dns messages in cache may share common rrsets, to decrease the memory
> usage of dns message cache, it's better to add one rrset cache. messages in
> cache just includes the rrset index information, different messages in
> message cache will share the same rrset cache. See the below sketch. 

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?

> The key for one rrset in cache should be "Domain_name + Type + Class". In
> the value part, besides of the rdata of each rr in the rrset, there should
> be rrset's signature(rrsig record), if it has, and the security
> status(dnssec validation result) of rrset.

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

> ==== Updating one rrset ====
> The interface for updating one rrset should be provided. Note: some rrsets
> in the cache may be updated before they expire.

We could use it to update both the data and the expiration time.

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

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

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

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


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 hope the feedback is of some use.

Thanks

Have a nice day

-- 
The cost of living is going up, and the chance of living is going down.

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/20101207/d94734bd/attachment.bin>