spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Warren Togami Jr." <>
Subject Re: Why run your own DNS server?
Date Mon, 04 Jul 2011 12:11:36 GMT
On 7/4/2011 1:52 AM, Axb wrote:
> On 2011-07-04 12:46, Warren Togami Jr. wrote:
>> Hey folks,
>> I wrote this article about why it can be important to run your own DNS
>> server if you have a busy Spamassassin deployment.
>> Anyone have any better tips of an alternate DNS resolver, or
>> configuration options to improve this suggested configuration?
> Warren
> Sadly, your post has unleashed a sequel of pretty useless hints & rants.
> "There is a drawback to running pdns-recursor. The above pdns-recursor
> instance is using ~400MB of memory. If you cannot afford this kind of
> memory use, you can reduce the limits in options max-cache-entries and
> max-packetcache-entries in /etc/pdns-recursor/recursor.conf as
> documented upstream. You will need to find a balance between memory use
> and effective cache hit performance."
> A small site will never use 400MB of DNS cacheing... don't scare ppl
> unnecessarily :)
> Larger sites already do local recursion and have the iron to to it.
> (other recursors will also use a lot of memory under high-ish load)

I am not 100% certain about this, but it appears that pdns-recursor is 
tuned to "normal" patterns of DNS lookups (like web browsing or maybe a 
squid proxy server).  It is caching a large amount of useless data, 
evidenced by the piss terrible cache hit ratio.  My in-brain logic 
without testing suggested that timing out most of that nearly-useless 
cache may shrink memory usage considerably without making that poor 
cache hit ratio much worse, since more recent data is often more 
relevant.  That is my theory anyway.  I'm testing that now.

> Be careful when endorsing:
> "For example, DNS results of DNSBL and URIBL's are very transient in
> nature with tiny TTL's, so perhaps we could substantially reduce memory
> usage by forcing max-cache-ttl and max-negative-ttl to a much smaller
> duration. It also appears that the packetcache is far more effective
> than the cache at achieving hits, so we may be better off favoring the
> packetcache rather than the memory hogging and less effective cache."
> Reducing negative TTL time should ONLY be done the user runs *local*
> copies of most of the queried BLs, otherwsise he may hit BL abuse
> threshold way earlier.
> BLs generally adjust their negative TTL to get a practical balance
> between query load and positive hits.
> Gaming these settings can become a costly process.
> Axb

Good point, I'll remove that paragraph for now and actually test that 
theory myself to see how it effects the actual hit/miss ratio.


View raw message