spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Cole" <>
Subject Re: DNSBLs and cache hit rate (was Re: Must-Have Plugins?)
Date Fri, 12 Jun 2015 03:25:48 GMT
On 10 Jun 2015, at 10:26, Kevin A. McGrail wrote:

> On 6/10/2015 10:18 AM, Dianne Skoll wrote:
>> I'm not disputing that running a caching DNS server is a good idea, 
>> but
>> you may be quite surprised at the low cache hit rate for IP-based 
>> DNSBLs.
> IMO, the primary goal of a caching-only nameserver is in fact, not the 
> caching, but rather the unique source IP so as to avoid running into 
> DNS limits placed on RBL queries from some BL providers that you can 
> run afoul of when sharing a DNS server.
> Caching is really just icing on the cake coupled with the simplest way 
> to get a local DNS server up and running, no?

Not at all scales and styles of mail system. The MTA does lookups at 
connect and at each command that mostly block progress, and them if the 
message makes it to SA, virtually all of those lookups and often closely 
related ones will be done again, often in another process running as a 
different user which might (OS-dependent) mean that a record in the 
meager cache kept by the OS won't be used for the second lookup.

I no longer have access to the data I gathered on this when I was 
handling a big-ish system with multiple then-hefty MX gateways doing 
spam filtering, but my memory is still sound enough that I can say the 
difference between (1) talking to The Official Enterprise DNS Server on 
the other side of a router that handled all recursive resolution and (2) 
using a machine-local caching forwarder on each MX forwarding to a 
shared caching recursive resolver on a common LAN was most of the median 
SMTP session life. My recollection is that (1) meant most sessions took 
~7 seconds or longer, (2) dropped it to near 3 seconds. A number of 
things have changed in the past decade that might substantially change 
that effect even in a similar site, but I think most of the effect 
(proliferation of DNS-based tactics like SPF & DKIM and many more usable 
DNSBLs and particularly URIBLs) can only make a cache more helpful, even 
if the help is marginal. On the other hand, even legitimate operations 
seem to think every DNS record should expire before today's close of 
business, and that makes caching less possible.

Also, a smaller site gets less benefit at all from a DNS cache. If 
you've got a few dozen users getting the same mail simultaneously in 
parallel, you win. If you don't HAVE a few dozen users and most of your 
users get no spam and little mail, you have a cache that's pretty 
sparse. You still avoid the problems of looking like part of an abusive 
behemoth when you forward to Google or of getting self-serving lies from 
the local ISP browser-aid resolver, so it remains worthwhile.

View raw message