At 13:41 19/08/2004, Justin Mason wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jason Haar writes:
> On Tue, Aug 17, 2004 at 08:31:41AM -0400, Jeff Koch wrote:
> > I question your statement that these DNSRBL can handle the load. Our
> > mailservers are handling over 10K messages per hour - but to be
> > conservative assume there are a million SA boxes checking 1.0K messages per
> > hour. Is it reasonable to assume that each DNSRBL can handle a billion
> > queries an hour?
>
> We really need negative caching for DNS lookups. DNS TTLs are great for
> caching *successful* lookups - but failed lookups aren't cached.
>
> This is the problem with the RBL style. It has retro-fitted DNS to do a job
> it wasn't designed to do. Another example of a product with the same issues
> is the Squid proxy server. They designed negative DNS caching into Squid to
> reduce the amount of network DNS calls Squid makes.
>
> Has anyone looked into adding a DNS cache component into SA? You could cache
> both positive and negative lookups for (say) 5-10 minutes without really
> causing any bad side effects...
We were considering it, since it'd be doable now that we prefork and keep a spamd process running for a few hundred messages. However, the other devs were pretty sure that a local caching "named" process would probably do the trick nicely enough. (me, I'm not quite convinced ;)
So a local caching named won't cache negative lookups? That *could* be quite an improvement if that's the case...
Actually named *does* cache negative lookups, so the original poster that said failed lookups aren't cached was wrong...
There was a little bit of discussion on the SURBL list just the other day suggesting the possibility of making the negative TTL much shorter than the normal TTL - so entires that are listed in surbl will cache for a longer time (say a few hours) while entries that aren't currently listed wont be negatively cached for too long, to make newly added entries usable sooner...
Regards, Simon
