[bind10-dev] recursor cache requirements - input required

[Likun Zhang]

> The compression technique involve pointers to absolute offsets in the
message.
> If an RRset is found in more than one message, (potentially) we will have
to have
> one compressed version of the RRset for each message it is in.  It may
well be
> simpler to cache the wire format of each message as-is and create
associated
> index structures mapping it to the constituent RRsets (and vice-versa).
Then if
> any of the RRsets is updated (other than a TTL update that we can
explicitly write
> back into the message), drop the message and re-query.

Bad point for caching the wire format of each message:

1. cache may be used up quickly, especially for the messages with dnssec.
2. cached wire format message with dnssec can't be answered to client, when
the client doesn't ask dnssec query, recursor has to generate the answer by
removing the rrsig(nsec, etc.) records from the message.

> > 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.
> 
> If we make the cache a single C++ class, we could always create other
instances
> of it for different DNS classes - although we want to be aware of a
malicious
> attack whereby an attacker could force the creation of 64k instances of
the cache
> (see below).  Should we go this way, it will have an impact on the NSAS.
At
> present the NSAS stores all classes in one store; if we explicitly take
DNS class out
> of the cache, we should do the same for the NSAS.

We have to search class IN's cache first,  seems we can't save 16-bits
processing time.

Likun
Thanks