Does anyone use nscd?

Stefan Esser se at freebsd.org
Tue Oct 11 10:31:13 UTC 2011


Am 11.10.2011 10:32, schrieb Michael Bushkov:
> On Tue, Oct 11, 2011 at 1:42 PM,  <perryh at pluto.rain.com> wrote:
>> Doug Barton <dougb at freebsd.org> wrote:
>>
>>> On 10/10/2011 11:55, David Brodbeck wrote:
>>>> Is there any reason to cache negative hits?
>>>
>>> It's very important for DNS since there are a fairly large number
>>> of misbehaving applications that don't stop querying until they
>>> get some kind of answer.
>>
>> Would this need be sufficiently covered if negative cache timeout
>> were set to, say, 1/4 of a second?  That should be short enough
>> to cover virtually any instance in which a missing entry is added
>> manually and the new entry then needs to be found.
> 
> You can actually change negative caching timeout as well as turn it
> off completely. There's negative-time-to-live option in nscd.conf (see
> http://www.freebsd.org/cgi/man.cgi?query=nscd.conf). Unfortunately it
> accepts only integer number of seconds, so 1/4 of a second is
> impossible. But you can turn negative caching off completely by
> setting negative-time-to-live to 0.

Just an idea, which would slightly complicate the internal logic,
but not by too much, IMHO:

How about counting negative hits and requiring a *threshold* to be
crossed, *before cached negative results are returned*?

E.g. if there is a negative response, then put it into the cache with
a timeout of e.g. 60 seconds, but do not rely on the cached value but
repeat the actual lookup if another query is issued. Only after e.g. 5
queries that were not answered from the cache within the (relatively
short) negative cache timeout period, the cached reply is returned as
is currently done for the second query already.

This would introduce a 3rd state besides known-to-exist and
not-to-not-exist. The 3rd state would be "expected-to-not-exist" and that
state would migrate to known-to-not-exist for a (possibly longer time)
after it has been confirmed a number of times by repeating the lookup.

The code changes should be simple, only needing a counter for the
number of retries for a cached negative result. The threshold should
be configurable as well as the timeout for the 3rd state.

This should cover install scripts (which check just once or twice for
the existance of a UID/GID before deciding to create it), but also
negative DNS lookups (which would quickly migrate to state
known-to-not-exist).

Think of this proposal as a rate-limiting of queries for probably not
existing entries. There will be the specified number of retries after
negative replies within the specified time window. Any other query will
be answered from the cached negative entry.

But if there is a positive reply, before the retries are used up, the
newly defined value will be cached instead of the negative reply without
any delay (not even 1/4 of a second).

Regards, STefan


More information about the freebsd-hackers mailing list