I have written two patches which modify how the rbldns program works.
This patch exteds the rbldns program to allow the user to specify different IP addresses and TXT messages to be served in response to DNS queries. The format of the data file has been modified to allow a returned IP address and TXT comment to be specified for each IP block. The fields, as seems to be the standard with the djbdns programs, are separated with colons (the ":" character.)
For example, if you're operating an RBL which returns 127.0.0.2 for
known spammers, 127.0.0.3 for open relays, and 127.0.0.4 for dialup IP
data file might look something like
:127.0.0.2:Known spammer at $
172.16.0.0/12:127.0.0.3:Open relay on $
192.168.0.0/16:127.0.0.4:Dialup user on $
Lines with no IP address or TXT comment specified (like the "10" line
above) will cause rbldns to return the "default" values (from the ":"
line.) This is identical to how the stock
works, and should allow existing installations to work with no changes
to existing data files.
Lines with an IP address specified but no TXT comment (like the "210" and "211" lines above) will have an empty TXT record returned, overriding any default TXT value. In this case the colon after the returned IP is optional.
Normally, rbldns uses the value of the BASE environment variable to tell which domain the incoming queries are supposed to be within. If a query is received for a name which is not in this domain, the query is ignored.
This patch extends rbldns so it will respond to queries for more than one domain. For example, if you have a single set of IP addresses but you want it to be visible as both "rbl.delete.net" and "rbl.dont-spam.us", this patch makes it possible to run both blacklists under the same service, using the same IP address. The service will respond to queries under either domain name.
2008-01-18 I have sold the domain name "delete.net". If you are reading this, the "rbl.delete.net" zone no longer exists- if you wish to use the RBL, you will need to use the "rbl.dont-spam.us" name instead. In fact, it was the potential sale of this domain name which prompted me to write the patch to begin with.
Configuring the patch is easy- instead of setting BASE to a single domain name, set BASE to a list of domain names, separated by the ":" character. For example...
# cd /service/rbl.delete.net
# echo 'rbl.delete.net:rbl.dont-spam.us' > env/BASE
# svc -t .
This will change an existing rbldns service which answers queries for the "rbl.delete.net" domain, so that it ALSO answers queries for the "rbl.dont-spam.us" domain.
Note that there is only one list of IP blocks which belong to "the list"... the change is that "the list" can now be queried using multiple names.
After extracting the original djbdns source code package, cd to the directory with the source code and run the patch. The commands will look something like this (the line with the "patch" command is the only difference from the official installation instructions.)
# cd /usr/local/src
# tar xvzf /root/djbdns-1.05.tar.gz
# cd djbdns-1.05
# patch -p1 < /root/djbdns-1.05-rbldns-combined.patch
# make setup check
Obviously substitute your own work directory, and the location and filename of the patch you're using on your system.
This page originally only had the "specific data" patch on it, and there were two versions- the one you see here, and a modified version which allowed you to leave out the result IP on the data lines if the result was the same as the default IP.
After giving it some thought, I realized that this other version just created an extra step in the process, and that if I wanted to maintain the file without the custom IPs but with custom TXT messages, it made more sense to run that through a pre-processor and produce a file with the IP in every entry, rather than possibly forcing rbldns to do a second query to find the default IP if you happened to leave it out of that line.
This second version of the patch is no longer available.
2003-10-05: Somebody emailed me with a question, and it started me thinking about this stuff again. I thought of a potential problem...
When building your data file, watch out for blocks which overlap. If a given IP address appears in two or more blocks, there's officially no way to tell which block it will match first and therefore which IP address will be returned to the querent (the program/person making the query.) This is a side-effect of how CDB files work.
If you really need to keep things separated like this, you should probably be using tinydns and adding the addresses to multiple lists, so that the querents can search for specific record types (i.e. "known spammer", "spam-friendly ISP", "open relay", "dialup address", etc.) by querying for the address within a specific domain.
Of course, some querents might want to know if an address appears on "any list on the server" first, and then take action based on which addresses are returned.
Given that the easiest way to maintain a multi-list setup would be to start with separate block lists, I can see the need for a program to read the lists and spit out tinydns data lines, not only for the individual list but to automatically generate a "combined" list... this is a back-burner project on my list, and when it's done it'll be posted on this web site.