Recipe 6.5 Building Your Own DNS Blackhole List

Problem

You need to create your own DNS blackhole list because no external blackhole service provides exactly the listing policy and content you need.

Solution

The domain administrator must create a DNS zone file, in the proper format, that lists all of the connection addresses that are to be blacklisted. The special DNS address records in the zone file are constructed by reversing the IP address of the blacklisted system to create the DNS name field of the record and by using an address such as 127.0.0.2 in the data field of the address record. This format means that hosts are blacklisted by IP address instead of by name, which makes sense because the dnsbl lookup is done using the connection IP address. The DNS server must be authoritative for the domain in which the blackhole list is to be located. This is normally done by creating a special subdomain for the blackhole list within the zone of authority of the DNS server.

On the sendmail system, create a configuration containing the dnsbl feature. ^[6] Identify the local DNS blackhole list on the dnsbl command line. Here is an example:

^[6] Alternatively, the enhdnsbl feature can be used.

 dnl Point dnsbl to our local DNS blackhole list FEATURE(`dnsbl', `dnsbl.wrotethebook.com')

Following Recipe 1.8, rebuild the sendmail.cf file, copy the new sendmail.cf file to /etc/mail , and restart sendmail.

Discussion

Using a blackhole list service is simple but inflexible because you can't choose which sites are listed. This means that mail from a friendly site might be blocked just because the administrator at that site misconfigured relaying. For this reason, some organizations decide to build their own DNS-based blackhole list. Creating your own blackhole server ensures that connectivity to all of the sites you want to reach is under your direct control, but it requires both sendmail and DNS expertise.

The DNS administrator uses a zone statement in the DNS server's named.conf file to load the blackhole database. Assuming that the blacklisted hosts are defined in a zone file named blacklisted.hosts , which provides the data for a domain named dnsbl.wrotethebook.com , the following zone statement would be used:

 zone "dnsbl.wrotethebook.com" IN {         type master;         file "blacklisted.hosts";         allow-update { none; }; };

Blackhole entries for addresses 10.0.187.215 and 192.168.0.3 defined in the blacklisted.hosts file would be the following:

 215.187.0.10                 IN A 127.0.0.2  3.0.168.192                  IN A 127.0.0.2

The newly created DNS domain is referenced as the source for blackhole list data on the dnsbl feature command line in the Solution section. Mail from any site listed in the dnsbl.wrotethebook.com domain is rejected, as this attempt to send mail from 192.168.0.3 shows:

 #  telnet chef smtp  Trying 192.168.0.8... Connected to 192.168.0.8. Escape character is '^]'. 220 chef.wrotethebook.com ESMTP Sendmail 8.12.9/8.12.9; Fri, 22 Aug 2003 12:01:37 - 0400  helo rodent.wrotethebook.com  250 chef.wrotethebook.com Hello rodent.wrotethebook.com [192.168.0.3], pleased to  meet you  MAIL From:<craig@rodent.wrotethebook.com>  550 5.7.1 Rejected: 192.168.0.3 listed at dnsbl.wrotethebook.com  QUIT  221 2.0.0 chef.wrotethebook.com closing connection Connection closed by foreign host.

The connection address 192.168.0.3 is found in the dnsbl.wrotethebook.com domain, so our server rejects the mail and returns the error message "550 5.7.1 Rejected: 192.168.0.3 listed at dnsbl.wrotethebook.com." This default error message can be changed with an additional argument on the dnsbl feature command line. For example, the command:

 FEATURE(`dnsbl', `dnsbl.wrotethebook.com', `"Mail rejected. "$&{client_addr}" is a  suspected spam relay."')

changes the error message to "Mail rejected. 192.168.0.3 is a suspected spam relay." However, the standard message works well and provides the remote site with more information.

The small number of systems used in the blackhole list in this recipe could much more easily have been handled by the access database. In most cases, using the access database to block unwanted mail connections is much easier than creating your own blackhole list. Creating and maintaining your own blackhole list is labor intensive . The systems that should be added to and removed from the list are constantly changing. Additionally, a great deal of information is needed to initially build a list. It is possible to use a mail filtering tool, such as procmail , to automatically collect suspected addresses directly from mail. However, it is difficult to create a system that collects the right information and keeps it up-to-date. Most administrators prefer to create their own blackhole list based on the blackhole list provided by a blackhole list service. The services already have large lists and they constantly maintain them. Most blackhole list services provide some way to download the entire list. For example, the DSBL list can be downloaded using rsync :

 # rsync rsync.dsbl.org::dsbl/bind-list.dsbl.org.

Periodically downloading a list and customizing it is one way to create your own blackhole list. But even if you start with a preexisting list, creating your own blackhole list is not a task that should be undertaken lightly. Creating your own blackhole list is one of the most difficult techniques for controlling unwanted junk email.

As usual, the choice between using a blackhole list service or building your own blackhole list is a choice between simplicity and flexibility. Most sites choose simplicity. If you don't have the available staff necessary to build and maintain your own blackhole list, stick with a standard blackhole list service, as described in Recipe 6.4, and use the technique described in Recipe 6.6 to make it comply with your needs.

Recipe 6.5 Building Your Own DNS Blackhole List

Problem

Solution

Discussion

See Also