[bind10-dev] recursor cache requirements - input required

[Shane Kerr]

Likun,

It's good to see this. My comments are below.

On Tue, 2010-12-07 at 16:55 +0800, Likun Zhang wrote:
> 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.

It is very unlikely that the cache will ever be used for any class other
than IN. I suggest that we restrict the cache to a single class, in the
interest of saving 16-bits per entry plus associated processing time.


> ==== dumping/loading to/from one document/database ====
> The content of rrset cache should can be dumped to one document/database, so
> that the rrset cache can be reused when the recursor is restarted.
> Extra rrset expire time should be added when dumping, so that expired rrsets
> can be ignored when loading rrset cache from the document/database.

Because the cache can be quite large, we need to define the behavior
when the cache is being dumped. I suggest that the cache should not
block add/remove operations when this is going on.

Actually, it might be possible to act in two ways: allow add/remove
operations for when dumping or loading during runtime, and disallow for
faster, lock-free operation when starting up or shutting down.

We may also want a way to completely empty the cache. If nothing else
this can be useful in debugging. :)

> === Message Cache ===
> The key for one message in the cache should be "Query_name + Query_type +
> Query_Class", and expiration time for the message should be "now + TTL(The
> lowerest TTL of rrsets in the message)". 

Consider my comments about class apply here too.

Regarding the expiration time... we may need to be careful about this.
For example, if we have the following messages:

-[ message 1 ]------------------
FOO.EXAMPLE CNAME BAR.EXAMPLE
BAR.EXAMPLE A 1.2.3.4
--------------------------------

-[ message 2 ]------------------
BAR.EXAMPLE A 1.2.3.4
--------------------------------

Then an update to the RRSET message 2 might effectively change the TTL
of message 1, if the TTL is made longer.

I guess we need links from the rrset cache to the message cache for
other reasons though, like when a message is removed before expiration,
so I guess it does not affect the requirements really...

> the value for one message should include message header, index information
> for each rrset in different message sections. For the structure, see the
> following sketch. The security status(dnssec validation result) of the
> message should also be noted.

It might be nice to include versions of this data with name compression
too, right? To avoid having to perform this processing again.

> == Miscellaneous ==
>  * The rrset/message cache must be thread-safe.

See my note above about improving loading / saving performance by not
requiring locking under some circumstances.

We should also note that this is intended to be used by a single
process. (It will be good to share cache across multiple processes, but
for now I do not think that is necessary.)

>  * The rrset/message cache size should be configurable.
> 
>  * LRU(Leatest Recently Used) entry in rrset/message cache should be removed
> when cache size get close to the configured value.

The cache should also be able to be resized at run time - made either
bigger or smaller. Note that the behavior when a cache is made smaller
should use LRU, although this is not necessarily true (we might simply
dump the cache, for example).

Looks good. :)

--
Shane