[rbldnsd] how to make public (DNS)RBL?

[Chris.]

Hello Jon, and thank you for your reply

On Fri, 15 May 2009 09:32:01 -0400 (EDT), Jon Lewis wrote...

> On Fri, 15 May 2009, Chris. wrote:
> 
>> I answered that (to some degree) in your last posting.
> 
> Not really.  You've managed to avoid revealing any of the details as
> to why your RBL could be the FUSSP other than that it lists around 1B
> IPs that are sources of spam and adds them very quickly.

Fair enough. I don't mean to be terse. I simply have alot on my plate right
now. Adding this to my list creates some somewhat /unforeseen/ elements
to my already overflowing schedule. I currently manage ~200 domains, and
all the hosts, and services that typically go along with them. As well as
the "embedded" system project, of which this anti-spam system will become
a part of. Plus, I have a great many other "open source" projects that I
either lead, or am a co-developer of. Given that I handle all of this /solo/.
I'm finding I have less time to communicate as /freely/ as I normally would.
Which, I guess, to some degree, sort of "short circuits" what I would hope
to accomplish on this list. ;)
I also manage all the equipment that all of the domains/projects "live"
on. :/ I'm testing a new provider. So I'm RP for a /29 out of one of their
segments. So I'm testing both them, and this anti-spam system on it. This
is another reason I'm trying to be "thrifty" with IP's. But /not/ at the
sake of /jeopardizing/ the project. If need be, I can always move it to
a block in one of the other segments I'm RP for.

> 
>> Now, I'd like to simply use one internet routable IP, and let the
>> .COM use/manage it. So now, as I haven't utilized my anti-spam system
>> in quite this environment. I was hoping to get some suggestions for
>> what might be the most resilient use of IP space under this
>> environment. Does this make any sense? I hope my question is
>> understandable. I'm just a bit leary "going live" with an environment
>> I haven't already tested. So was hoping to get some suggestions
>> before doing so. :)
> 
> It sounds like you're saying you run one public DNS server
> (authoratative DNS, I assume) and want that process to handle both
> regular DNS requests and RBL DNS requests using communications with a
> private rbldnsd to answer the RBL DNS queries.  While that certainly
> can be done, I'd strongly recommend against it if you go public.
> 
> For your own private use, such a setup may work, but if you make the
> RBL public and its half as good as you say, you'll likely see
> thousands of RBL queries per second.  When word gets out about how
> well your list works (taking for granted that it's as good as you
> say), you're going to be seeing tens of thousands of queries per
> second.  Can your single server answer 50k queries per second?  Do you
> have the bandwidth (tens of megabits/s) to receive and respond to
> those queries?
> 
> Any public DNSBL of any size uses a bunch of distinct DNS servers,
> both to spread the load and for redundancy.  What happens when your
> server goes offline (network outage, power failure, kernel upgrade)? 
> If there are a dozen different DNS servers for the RBL, nobody notices
> one going down. If there's just one, mail slows down as DNS queries
> timeout, and you'll likely generate a "DDoS" against yourself as
> queries that go unanswered get retried, multiplying your normal DNS
> query traffic.

Sure, understood. I can /likely/ handle the traffic I anticipate running
across the lines - /good/ traffic. ;) But I am hoping to make this as
/efficient/ as possible. Thinking that if I can use only /one/ internet
routable IP for the system, I could more easily replicate the whole
system - on different equipment, out of a different segment, etc...
So, I was thinking the sinereo I suggested would be more /portable/ -
maybe not. This is why I solicited suggestions from those that either
/ran/, or took part in a public RBL. I figure I only need the SO bit
set on the .COM for public availability on the internet, and set the SO
bit on the .NET so rbldnsd can handle the /private/ IP segment (loopback).
Then, the .COM "relays" all the info to, and from the internet, and
rbldnsd. Since I've only used rbldnsd on a /private/ segment, I'm not
exactly sure what the /best/ approach would/might be. I just figured
that if I kept rbldnsd on the /private/ segment that there would be
less traffic across the wire, and the whole system would be more
portable, and easier to replicate. But maybe I'm mistaken. Would
you, or anyone else care to define a better layout? I don't proclaim to
be an expert on this sinereo. I just found I seem to have found a good
solution for finding "naughty" IP's. :)

Thank you for all your time and consideration.

--Chris

P.S. I guess the best way for me to explain how I do it (trap naughty
IP's), is to start letting ppl use it. No? :)

Thanks again Jon, for your thoughtful response.

> 
> ----------------------------------------------------------------------
> Jon Lewis                   |  I route
> Senior Network Engineer     |  therefore you are
> Atlantic Net                |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
> _______________________________________________
> rbldnsd mailing list
> rbldnsd at corpit.ru
> http://www.corpit.ru/mailman/listinfo/rbldnsd
_________________________________________________________________
    http://fastmail.ca/ - Fast Secure Web Email for Canadians