[bind10-dev] 答复: About resolver Negative Cache Design

[wanghaidong]

Hi Shane:
Since we decide to make a "quick and dirty" implementation for the negative cache, so I suggest to adopt the 2nd design first for Y2 delivery. If later we need to separate it to another cache, it should not a big trouble.

Best Regards
Ocean

> -----邮件原件-----
> 发件人: Shane Kerr [mailto:shane at isc.org]
> 发送时间: 2011年2月18日 19:37
> 收件人: wanghaidong
> 抄送: bind10-dev at lists.isc.org
> 主题: Re: [bind10-dev] About resolver Negative Cache Design
> 
> Ocean,
> 
> Thanks for presenting this design proposal - this is the kind of
> discussion we need to have for all of our features. :)
> 
> On Fri, 2011-02-18 at 18:11 +0800, wanghaidong wrote:
> 
> > For negative cache implementation, we may have 2 different designs:
> >
> >
> >
> > 1.       Implement a standalone negative_cache for negative answers ,
> > then put all the NXDOMAIN answers there, the normal responses and
> > NOERROR_NODATA responses can be put into the normal_cache.
> 
> ..
> 
> > For NOERROR_NODATA response, if cached and make response, the TTL need
> > to be recalculated because the SOA record is shared between normal SOA
> > record response and negative cache respond.
> 
> Tricky... to avoid a 3rd lookup we need to link the SOA record in the
> normal cache and the negative cache. Not a huge problem though!
> 
> > For NXDOMAIN, this can be shared between different types, that means
> > if the request for “A” record of xxx.example.com returns NXDOMAIN, all
> > the other types request for xxx.example.com should also return
> > NXDOMAIN, this can avoid unnecessary requests to authoritative
> > servers( CNAME may need special process ).
> 
> True. We could possibly do some tricks in a unified cache to achieve a
> similar result, depending on the data structure used (a tree would work
> for this, a hash would not).
> 
> > The disadvantages for this design are:
> >
> > l  The design may be more complicated
> >
> > l  It need lookup twice if not found in the normal_cache.
> 
> I think you have listed the main issues.
> 
> The lookup speed is a serious issue, although I guess it depends on:
> 
>       * How much time we spend on cache lookups vs. rest of processing
>       * Positive cache hit rate (assuming we try positive hits first!)
>       * Negative cache hit rate
> 
> Basically, we probably need real data to decide if it matters or if we
> care.
> 
> The complicated design is a bigger issue. It would be nice to have the
> negative cache in the Y2 deliverable, which means we basically have 2.5
> weeks to implement it. Will a more complicated design be feasible in
> this time?
> 
> --
> Shane