From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 11 10:31:13 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B7661065673 for ; Tue, 11 Oct 2011 10:31:13 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm31-vm5.bullet.mail.bf1.yahoo.com (nm31-vm5.bullet.mail.bf1.yahoo.com [72.30.239.13]) by mx1.freebsd.org (Postfix) with SMTP id 3A6568FC1A for ; Tue, 11 Oct 2011 10:31:13 +0000 (UTC) Received: from [98.139.212.149] by nm31.bullet.mail.bf1.yahoo.com with NNFMP; 11 Oct 2011 10:18:08 -0000 Received: from [98.139.211.206] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 11 Oct 2011 10:18:08 -0000 Received: from [127.0.0.1] by smtp215.mail.bf1.yahoo.com with NNFMP; 11 Oct 2011 10:18:08 -0000 X-Yahoo-Newman-Id: 233908.15601.bm@smtp215.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 7IFPsAgVM1nYjaI4wM2Z5xjBOKhNLDnDWbJ6Ufq0gsgMl2V b3DozZ6621wK_WQ7UgI_Yq1GQCcI5nmslDKIy8x1RZ.iG4WCdNVm7nqWKDuX WIw57AHzHHXgfbDbEgVQf4NFH2VWya4jJCZahOtdheJ2cgumq1ePA_V1ZC1a CLvCdXRSm9dC5AzXLu8WTjcaQd6jkaApjy7F09HV3ytBS4vyBP_O3FRQtiKc yjiOUEhjMalra2u7qe_kWPerjI7CmsZFEx_H8K25Gac_J3apujSfX37Uoa.t wFDoGG5LTHSwOd1TgQ1Knw2_UsDOIqhWg9DfFkeQXNg1bE7wFlL692x3S7W5 9jOymJpKovQJc9SbQbHYl2IpuXa3d.jef.EQ1NhtuQjga2fT3IvvONe.WK4X 9EKnLheY- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.155.124 with plain) by smtp215.mail.bf1.yahoo.com with SMTP; 11 Oct 2011 03:18:07 -0700 PDT Message-ID: <4E9417E0.9050804@freebsd.org> Date: Tue, 11 Oct 2011 12:18:08 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Michael Bushkov References: <20111004160043.GA16034@lpthe.jussieu.fr> <051853CE-03EC-4EEC-A5AC-C380131B28E4@gsoft.com.au> <4e8f073c.3g2aD/Zz9KdsWOKN%perryh@pluto.rain.com> <4E935105.1090602@FreeBSD.org> <4e942bc2.diL95Gr/XYELJ+gj%perryh@pluto.rain.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, dougb@freebsd.org, perryh@pluto.rain.com Subject: Re: Does anyone use nscd? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 10:31:13 -0000 Am 11.10.2011 10:32, schrieb Michael Bushkov: > On Tue, Oct 11, 2011 at 1:42 PM, wrote: >> Doug Barton 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