Front page | perl.qpsmtpd |
Postings from July 2011
On 7/26/2011 10:41 PM, Jared Johnson wrote: > We discussed doing this once at my organization and someone astutely > pointed out that considering that this is DNS, the better solution would > really be to run a local caching DNS server, e.g. bind9 and point > resolv.conf to 127.0.0.1 with forwarders to your ISP's nameservers. Well, > what they actually pointed out was that since we already do this > everywhere, we're already getting in-memory caching that's designed > expressly for DNS results, for free :) > running a local caching DNS server is basically a good idea anyway, and > obsoletes the need for caching DNS results in any particular software. Agreed. Because one of the things that many people will want to do is customize where the DNS cache gets its answers, and that makes developing a cache more complicated. In our case, we run split-horizon DNS (where some of our DNS queries for our _own_ space has to be split between internal and external resolvers), AND we run our own rbldnsd instances for most of our DNSBLs that can't be published externally thru the normal chain of DNS queries. For a while, we had one rbldnsd and used corporate DNS caching (which knew how to route DNSBL queries) for our (at one point 11) qpsmtpd instances. The loading (at 30+ million emails/day) caused the DNS guys to yell at me for overloading our bind9 caches. Now each of our qpsmtpd instances has their own rbldnsd (serving ~700Mb zone consisting of almost all the DNSBLs we use as one merged zone) plus the "Unbound" DNS server package. This is probably overkill even at 30+ million emails/day, but it works extremely well. The unbounds are configured to route DNSBL queries to the co-resident rbldnsds (they can failover to other server rbldnsds), DNS queries of our infrastructure to the corporate bind9 instances, and external queries through normal recursive resolution (involving the root servers if necessary), and unbound caches all of it. [Note if you are running qpsmtpd-async, as we do, it's not really possible to route DNS queries differently for DNSBLs versus other DNS queries qpsmtpd does. ParaDNS doesn't handle paralleled DNS queries to different servers well.] Unbound is easy to install and configure. I chose not to use Bind9 partially because of previous experiences with much older versions. I did run DJB's dnscache for a while instead, but unbound works so much better. Avoid using dnscache for this. I can explain why if people are interested. Before qpsmtpd, we were using Lyris Mailshield which had its own internal cache for some reason. It was quite awkward because it's capabilities of routing queries via configuration were highly limited.Thread Previous | Thread Next