SURBL

Using BIND and rsync to mirror list zones

Systems processing more than a a few hundred thousand messages per day should set up a local name server for the lists they are using, including SURBLs. This is widely considered a good practice since it offloads the public name servers, reduces external network traffic, and significantly speeds up mail processing. A local name server improves performance by providing lower-latency access to list data.

While many administrators prefer to use rbldnsd for serving list zone files since it's much faster and more memory efficient than BIND, here are some instructions if you choose to use BIND.

1. Install rsync and BIND if not already present. Be sure to keep your versions current in order to run the latest security updates.
2. If desired, create a separate directory to store the rsynced zone files into, such as "r" under /etc/namedb:

   		mkdir /etc/namedb/r
   

3. Set up BIND as a master for the zones you expect to use:

   		zone "multi.surbl.org" {
             type master;
             file "r/multi.surbl.org.bind";
     };
   

   (At this point, the only zone that should be used is multi.surbl.org . Since multi includes all the other zones, the other zones are obsolete.)

   Your server is not really a master for these zones, but because we used the keyword "master" above, it will behave as if it were, which is what we want.

4. Create up a shell script to rsync the zone files and reload named:

   		#!/bin/sh
     
     /usr/local/bin/rsync -t some_rsync_server::surbl/multi.surbl.org.bind /etc/namedb/r/
     /usr/sbin/named.reload
   

   Where some_rsync_server is replaced by the real server name when access is granted. (The -t argument causes rsync to preserve timestamps. Strictly speaking it's not needed in this use.) Remember to make the script executable.
5. Request rsync access to the SURBL zone files. Please let us know your rbldnsd server's IP address and the approximate number of incoming messages per day that are processed.
6. Confirm that the zone files come across correctly by manually rsyncing.
7. Enable the script above by adding it to your crontab:

   		7,37 * * * *  (root) (path to script above)
   

   Where the who field of root is needed for /etc/crontab in FreeBSD but not for user-style crontabs. (You can also enter the rsync and named.reload directly in a crontab entry.) Please use minutes different from 7 and 37 so that the load is spread out over time. 20-minute intervals should be considered the minimum, by the way.
8. Confirm that everything above is working correctly.
9. Then configure your mail or SpamAssassin servers using lists to do the lookups on your new local list name server.
   1. Many people run the local DNS for their lists directly on the mail server(s), which can work well since it keeps everything on the same box. In the default installation, BIND will do the right thing and try to resolve locally for domains it thinks it's a primary for. It will do this as long as 127.0.0.1 (localhost) is listed in your resolv.conf and forwarding is not set, which is typical but worth confirming.
   2. If your mail server is separate from your list name server, then set up DNS on the mail server to resolve using the new list name server, i.e., make it forwarding for the list domains.
   3. If the list zones are now served directly on a mail server where BIND was previously set up as forwarding, then you'll want remove the forwarding and set it up to resolve locally.

Notes:

• Since the local server is not delegated to, it will not receive NOTIFY packets when the zone files are updated, so reloading BIND manually is required. A fancier script to only reload BIND when one of the zone files has actually changed would be an improvement.
• One of the shortcomings of using BIND for this kind of slaving is highlighted above: the need to reload the name server frequently. BIND is particularly inefficient at this, causing DNS queries to be unanswered during reloads.
  • In contrast, rbldnsd reloads much faster and can be set to keep serving queries during a reload, at the cost of double memory usage during the reload. However, rbldnsd memory usage has been reported to be 10 times less than BIND.
  • And rbldnsd is about three times faster than BIND.
  • Also rbldnsd by default looks for and loads changed zone files every 60 seconds, so it never needs manual reloads like BIND does.
• Other list zone files can also be served locally this way, but several lists only offer their zone files in rbldnsd format.
• For these and other reasons, we strongly recommend rbldnsd over BIND.

Version 1.06 on 4/11/09