Kris Deugau put forth on 9/29/2010 2:33 PM: > Hmm, no, less than 100M: > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 28776 rbldns 20 0 81740 65m 700 S 0 3.3 118:49.42 rbldnsd
I was going by information I received from another list. I don't use the data feed service. Does this include the CBL data set within Zen? I would make an educated guess that the size of the CBL data set would be over 100MB alone. 25 million 32bit IP addresses (4 bytes) would be 100MB, if my math is correct. 25 million bot infected hosts around the world seems like a very conservative estimate. > And this with a modest local blacklist loaded in as well. The on-disk > files for all of the lists total just over 100M. We just run the > Spamhaus data on a non-public zone on our general resolvers (running > dnscache) and we have yet to see any latency problems. With fast resolvers and local GigE, performance should be fine for many sites as you state. It's also easier to manage than running rbldnsd on each MX as you have a single update point. I know of one site, coincidentally also in Canada, running two MX hosts. Each receives, IIRC, on an average day, ~50 million connection attempts, 100 million total. This is nowhere near the numbers of a good sized ISP obviously and tiny compared to a gorilla such as Gmail. The OP runs rbldnsd on each MX, with the full Spamhaus zones minus the CBL. Also incorporated into the rbldnsd instances are extensive local block lists, the Enemies List, the CBL data, and some other mirrored dnsbl data. This may be the multi gigabyte setup I was thinking of, which isn't just Spamhaus zones. Interestingly, this site doesn't reject any spam due to any hits against any list. After DATA, a 55x is returned to the client, but the entire message is saved for further anti spam heuristics processing. It's one of the most elaborate setups I've heard of. Then again, some of the most elaborate setups _no one_ will probably hear about. ;) > The biggest sysadmin/network costs for the rsync service are in > configuration (may need extra scripting to distribute the data to > multiple rbldnsd instances, depending on how you want to arrange your > DNS services - otherwise, it's "set up once, let it run") and update > bandwidth - currently they provide a script intended to be called once a > minute to update the zone data source files. Yeah, running the Spamhaus zones on local rbldnsd instances on each MX would require some distribution magic, as you state. Never done this myself. I'd be more inclined to go the route you've taken, if I were ever in a position to manage such a thing. -- Stan
