[bind10-dev] About resolver Negative Cache Design

[wanghaidong]

Hi all:

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.

Then the logic will be:

a)       Look up the normal_cache, if found and not expired, return it, if
not found goto step b)

b)       Look up the negative_cache, if found and not expired, return it,
otherwise goto step c)

c)       Send request to authoritative servers.

 

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.

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

 

The advantages for this design are:

l  The NXDOMAIN info can be shared between different types for the same
domain name request, but if most requests is type A, this advantage may not
be so obvious.

l  The negative cache is independent of normal cache, avoid a lot of
NXDOMAIN requests flushing normal cache

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.

 

2.       Keep only one cache and make special process for NXDOMAIN and
NOERROR_NODATA.

This can keep current implementation almost intact except some special
processing for NXDOMAIN/NOERROR responses.

But this design cannot make NXDOMAIN info shared between different types for
the same domain name because the cache is keyed with (DOMAIN NAME, TYPE).

 

 

Any comments will be greatly appreciated. Thanks.

 

Ocean

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20110218/1469469e/attachment.html>