rblcheck: A command-line interface to RBL-style listings | ||
---|---|---|
<<< Previous | Future | Next >>> |
These are the features that you'll never see in the version of rblcheck that I produce (rblcheck is GPL; you're free to produce your own version if this doesn't suit you well), and the rationale behind why not. I'm hoping that the explainations will make sense, but I'm always open to criticism if you feel my logic is flawed.
This is a futile method of checking whether a particular system is blackholed; if the originating system has control of reverse DNS for their IP space, they can make their IP address resolve to anything they want, such as system.network.com. If rblcheck were to do a lookup on that, "system.network.com" might resolve to anything (such as "127.0.0.1, which will always pass with every currently known RBL-based blacklist). A compromise that I've considered would be similar to TCP Wrapper's system of multiple lookups: take the IP address, look up the reverse, then resolve the reverse to an IP address. If both lookups match, then proceed, otherwise exit with a failure. I'd consider integrating code from someone who implemented this behavior.
(A note for the confused: some people might mistake this for my saying that a tool for looking up hosts in DNSBL listings (a means of looking up originating domains in a blacklist, much like the RBL) isn't a good idea. On the contrary, I'd like to see a complimentary dnsblcheck to go along with rblcheck. The problem I have is specifically with resolving the name to an IP address for use by an RBL lookup tool.)
This took a while to convince me it was wrong. Here are the questions I went over when deciding against this:
What do you do with your scripts when the blacklist order changes, or new blacklists appear (assuming a dynamic assignment of identifiers)?
If you hard-code a number for each and every blacklist, who becomes responsible for being a registry for those numerical identifiers? What happens to already-assigned values when blacklists shutdown or change incompatibly?
How do you scale beyond 256 RBL services? With the advent of software such as rbldns (a part of the djbdns package which allows anyone to host an RBL-style service), and with nearly a dozen OsiruSoft domains alone, does this limitation seem reasonable?
How do you report multiple matches with a return code, when the return code can only hold one number?
Some of these can be solved, but not cleanly; you'll need no end of special cases to accomodate them.
This is a question of UNIX philosophy: design one tool for one task, and do it well. There are plenty of far more powerful text parsing tools available which are more appropriate for the job (email parsing is easily handled by tools such as formail, general text parsing is better suited by tools such as sed, awk, perl, python, etc), and they can do a much better job than something that I could integrate into rblcheck while still maintaining a small footprint.
<<< Previous | Home | Next >>> |
Future | Up | Notes on origip |