[bind10-dev] About resolver Negative Cache Design

[Jerry Scharf]

Depending on the situation, I have seen 10-40% negative answers on 
recursive servers. One survey respondent said he had 40% NXDOMs alone. 
Others may have different numbers. So negative answers are very common 
in the real world. This is also a reason why people want to add negative 
entries that last more than 10 minutes (like forever.)

Hope that helps,
jerry

On 02/18/2011 03:37 AM, Shane Kerr wrote:
> 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
>
>
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev