NOTE: The njabl.org web site and blacklist are gone, so the following is only useful as a general guide to blacklists, rbldnsd, rsync, etc. Please see other documents here for more relevant information.
The dnsbl.njabl.org zone data is currently available for rsync from rsync.njabl.org as either bind format or rbldnsd format. To have your IP added to the rsync ACL, send an email requesting access for your IP/subnet to help@njabl.org. Please mention rsync in the subject of your message. You probably won't get a response, but if your request looks reasonable (i.e. don't ask for rsync access for an entire /16) rsync access will generally be setup within 24 hours.
Note: For a while, 0/0 was in the rsync ACL. This has been removed, and if you are no longer able to connect to the rsync server, either you never bothered to ask for access or your request was lost. Also note, if you email asking about this from an address that's incapable of receiving email, you're not too bright.
Due to a problem with the way holes (exclusions from dial-up ranges for single IPs) are added and the way rbldnsd supports holes, it's likely that the bind format zone files will occasionally contain records with both CNAME and A records. Bind defaults to rejecting the zone when it encounters this. For this reason, I strongly recommend nobody use the bind format files. You'll find rbldnsd is a much more appropriate DNS server for dnsbls. Two of the biggest benefits of rbldnsd are speed and efficiency. When last loaded into bind, the dnsbl.njabl.org used about 90MB of memory. When we converted to using rbldnsd, the memory used by rbldnsd to load the same data (reformatted into rbldnsd compatible format) was about 8MB. rbldnsd on a Pentium Pro 180 answers queries about as fast as bind on a Pentium III 450.
Tips for running your own local rbldnsd based dnsbl.njabl.org zone:
- If you haven't already done so, subscribe to list@njabl.org by sending an email to list-subscribe@njabl.org. This is a moderated announcement list. It is imperative that you receive any announcements such as planned changes to the rsync directory structure, zone data file layout, etc.
- Choose a system to run rbldnsd on. This could be a dedicated system or one of your existing DNS servers (or even your mail server that runs a caching DNS server). You can run rbldnsd and bind together on the same system. Since I think this is the most likely scenario, I'll document it here.
- Create a user for rbldnsd to run as and a directory for the zone files rbldnsd will use. Here we'll use username dnsbl with a data directory of /var/dnsbl/njabl.
- Download/build/install the latest version of rbldnsd. Check the Makefile before running make to see if you need to change anything in order to properly build it on your OS.
-
Create a script that can be run from cron to periodically rsync the data files. i.e.
$ cat /usr/local/bin/njablrsync #!/bin/sh rsync -vaL rsync.njabl.org::njabl/rbldnsd/ /var/dnsbl/njabl/
You'll want to run this script anywhere from every 20 minutes to a couple times a day. I recommend at least once per hour. Since the files are updated every 20 minutes, rsyncing more frequently than every 20 minutes is only going to waste resources. -
Setup rbldnsd to run from bootup. If your system uses SysVinit style startup scripts, create an init script for rbldnsd, or use the one that comes with rbldnsd in the debian directory of the source. I prefer this simpler init script ripped off from Red Hat's gpm init script.
#!/bin/bash # # chkconfig: 2345 85 15 # description: rbldnsd is a DNS server designed for dnsbls. # processname: rbldnsd # pidfile: /var/run/rbldnsd.pid # source function library . /etc/init.d/functions [ -e /etc/sysconfig/rbldnsd ] && . /etc/sysconfig/rbldnsd RETVAL=0 start() { echo -n $"Starting rbldnsd service: " daemon /usr/local/sbin/rbldnsd $OPTIONS RETVAL=$? echo [ $RETVAL -eq 0 ] && touch /var/lock/subsys/rbldnsd } stop() { echo -n $"Shutting down rbldnsd service: " killproc rbldnsd RETVAL=$? echo [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/rbldnsd } case "$1" in start) start ;; stop) stop ;; restart|reload) stop start RETVAL=$? ;; condrestart) if [ -f /var/lock/subsys/rbldnsd ]; then stop start RETVAL=$? fi ;; status) status rbldnsd RETVAL=$? ;; *) echo $"Usage: $0 {start|stop|restart|condrestart|status}" exit 1 esac exit $RETVAL
If you use this script, setup /etc/sysconfig/rbldnsd with options such as:OPTIONS="-u dnsbl -r /var/dnsbl/njabl -t 21600 -c 60 -l querylog -p /var/run/rbldnsd.pid -b 127.0.0.1/530 dnsbl.njabl.org:ip4set:dnsbl.njabl.org.auto dnsbl.njabl.org:generic:dnsbl.njabl.org.generic dnsbl.njabl.org:ip4set:dnsbl.njabl.org.data"
If you use the rbldnsd.init script that comes with rbldnsd, you should have either /etc/default/rbldnsd or /etc/sysconfig/rbldnsd that looks kind of like:RBLDNSD="njabl -udnsbl -r/var/dnsbl/njabl -t21600 -c60 -lquerylog -b127.0.0.1/530 dnsbl.njabl.org:ip4set:dnsbl.njabl.org.auto dnsbl.njabl.org:generic:dnsbl.njabl.org.generic dnsbl.njabl.org:ip4set:dnsbl.njabl.org.data "
With this setup, /var/dnsbl/njabl/querylog will be a log of all queries handled by rbldnsd. If you have no need for this log, remove the option. For debugging purposes, while testing your setup, you may want to make it -l +querylog to turn off log write buffering. The -b 127.0.0.1/530 tells rbldnsd to listen on the IP address 127.0.0.1, UDP port 530. This is so you can run rbldnsd on the same system/IP as an existing DNS server (bind in this example). If you're setting up rbldnsd to answer queries for other systems on your network, replace 127.0.0.1/530 with your server's IP address and rbldnsd will run on port 53 as a DNS server normally would. The -b option has become mandatory in recent rbldnsd versions. In the past, rbldnsd would listen on all addresses and the port was set with the -P argument. -
Configure the DNS server(s) your mail server(s) use to forward dnsbl.njabl.org queries to your rbldnsd server(s). Add the following to named.conf:
zone "dnsbl.njabl.org" IN { type forward; forward first; forwarders { 127.0.0.1 port 530; }; };
If you're running rbldnsd on a dedicated system (not an existing DNS server), adjust the IP in the forwarders statement appropriately. With the setup above, if your local rbldnsd becomes unavailable, dnsbl.njabl.org queries will fall back to the root-servers. If your network generates a large volume of queries (thousands/sec), it may make sense to run multiple rbldnsd copies of dnsbl.njabl.org on several systems with the rsync update slightly staggered. rbldnsd will not answer queries while reloading the zone data into memory. Depending on the speed of your system and the size of the zone data, reloading could make the rbldnsd server unavailable for several seconds.
If you're running bind 8.x, the port option above is not supported. You'll need to dedicate an IP address to rbldnsd and make bind not listen on that IP by telling it which IPs to listen on. i.e. Setup an IP alias of 127.0.0.2 on your lo interface. Replace the bind config above with:options { listen-on { x.x.x.x; 127.0.0.1; }; }; zone "dnsbl.njabl.org" IN { type forward; forward first; forwarders { 127.0.0.2; }; };
replacing x.x.x.x with the IP address of your server. If your server has many IPs, you can list each one, or use CIDR notation such as x.x.x.0/24. - If you haven't done so already, run the rsync script to get a local copy of the dnsbl.njabl.org data. Start up rbldnsd and send it a few test queries. i.e. dig @localhost -p530 2.0.0.127.dnsbl.njabl.org. Assuming that worked properly, restart or issue a reconfig for your named process. Now send the same query to bind. i.e. dig @localhost 2.0.0.127.dnsbl.njabl.org. You should get an answer, and you should see a log entry in querylog showing that bind forwarded the query to your local rbldnsd.
- At this point, you should be done and have a working setup that handles dnsbl.njabl.org queries locally using rbldnsd.
Last modified: Tuesday, 16-Dec-2003 09:12:15 EST
Data Feed Request
Our Data Feeds offer higher performance for professional users through faster updates and resulting fresher data. Freshness matters since the threat behavior is often highly dynamic, so Data Feed users can expect higher detection rates and lower false negatives.
The main data set is available in different formats:
Rsync and DNS are typically used for mail filtering and RPZ for web filtering. High-volume systems and non-filter uses such as security research should use rsync.
For more information, please contact your reseller or see the references in Links.
Sign up for Data Feed Access.
Sign up for data feed access
Direct data feed access offers better filtering performance with fresher data than is available on the public mirrors. Sign up for Data Feed Access.
Supported Applications
Learn more ...