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

dnl Point dnsbl to our local DNS blackhole list

FEATURE(`dnsbl', `dnsbl.wrotethebook.com')

Rebuild the sendmail.cf file, copy the new sendmail.cf file to /etc/mail, and restart sendmail.

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 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.

dnl Use the DSBL blacklist service

FEATURE(`dnsbl', `list.dsbl.org')

Rebuild the sendmail.cf file, copy the new sendmail.cf file to /etc/mail, and restart sendmail.

The dnsbl feature adds the sendmail.cf code needed to enable a DNS blacklist service. The dnsbl feature uses a K command to define the dnsbl database as a host type database, which means lookups in dnsbl are really passed to DNS for resolution.The dnsbl feature also adds a few rules to the Basic_check_relay ruleset, which is called from the check_relay ruleset. The added rules lookup the connection address in the dnsbl database. If the connection address is found in the database, mail from that address is rejected with an error message. If the connection address is not found in the dnsbl database, the mail is passed on for further processing. A sendmail -bt test shows the impact of the added rewrite rules:

# sendmail -bt

ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)

Enter <ruleset> <address>

> .D{client_addr}192.168.111.68

> Basic_check_relay <>

Basic_check_rela   input: < >

Basic_check_rela returns: $# error $@ 5 . 7 . 1 $: "550 Rejected:

" 192 . 168 . 111 .  68 " listed at list.dsbl.org"

> /quit

Because there is no active connection—this is just a test—the first step is to statically define a connection address for the test. Next, the Basic_check_relay ruleset is called and passed to an empty workspace. The workspace passed to the ruleset in this test is unimportant because the first rule added to the ruleset by the dnsbl feature unconditionally replaces the workspace with the value found in ${client_addr}. Therefore, the value looked up in the dnsbl database is the connection address stored in the ${client_addr} macro. In this test, the address 192.168.111.68 is found in the blackhole list maintained at list.dsbl.org, so mail from that address is rejected. The mail is rejected with the error message:

550 Rejected: 192.168.111.68 listed at list.dsbl.org

The error message displays the address that was rejected and the service that recommended the rejection. This information is important. The administrators at 192.168.111.68 might need to contact the blackhole service to find out why their system is blacklisted and what they can do to get it removed from the blackhole list. Often, a system is blacklisted because of a configuration error that creates an open relay. As soon as the error is fixed, the administrator wants to get the system removed from the blackhole list. Knowing which services have blacklisted the system tells the administrator which services must be contacted to get full mail service restored.

This configuration uses the blackhole server at list.dsbl.org because that is the service specified with the dnsbl feature command, which is just an example; it is not a recommendation for the list.dsbl.org service. There are many blackhole services available. Go to each service’s web site and evaluate their policy for listing hosts in the database. Select the service whose policy most closely matches the policy you want to enforce on your server.

When no service is specified on the dnsbl feature command line, sendmail defaults to using blackholes.mail-abuse.org, which is the same service that was used by the deprecated sendmail rbl feature.

The enhdnsbl feature could be used as an alternative to dnsbl. However, the enhdnsbl feature provides no real advantage in this particular case.

The following command displays the contents of the local DNS cache:

> ipconfig /displaydns

And this clears that cache:

> ipconfig /flushdns

The following command causes the local host to reregister its DNS records via dynamic DNS:

> ipconfig /registerdns

Using VBScript

' This code flushes the local DNS cache.  There are no scripting

' interfaces designed to do this so I have to shell out and run

' the ipconfig /flushdns command.

strCommand = "ipconfig /flushdns"

set objWshShell = WScript.CreateObject("WScript.Shell")

intRC = objWshShell.Run(strCommand, 0, TRUE)

if intRC <> 0 then

   WScript.Echo "Error returned from running the command: " & intRC

else

   WScript.Echo "Command executed successfully"

end if' This code registers DNS records for the local host.  There are

' no scripting interfaces designed to do this so I have to shell

' out and run the ipconfig /registerhdns command.

strCommand = "ipconfig /registerdns"

set objWshShell = WScript.CreateObject("WScript.Shell")

intRC = objWshShell.Run(strCommand, 0, TRUE)

if intRC <> 0 then

   WScript.Echo "Error returned from running the command: " & intRC

else

   WScript.Echo "Command executed successfully"

end if

The Windows operating system maintains a name resolution cache of DNS records that the system has queried. This cache is maintained in memory and speeds up future requests for the same record. Each record has an associated time-to-live value. This setting informs clients of the maximum amount of time to cache that particular record. After the time-to-live period expires, Windows removes the record from its cache.

The Windows name resolution cache is maintained by the DNS Cache (DnsCache) service. You can prevent records from being cached by stopping this service (and disabling it if you never want records to be cached again). If you are getting strange results when querying DNS, you may want to view the local DNS cache to see if you are accessing locally cached records instead of what is current on the DNS Server.

The /registerdns option of ipconfig attempts to dynamically reregister DNS records for all IP addresses configured on the system. The DHCP Client (Dhcp) service does the DNS reregistration, so if that service is disabled, the /registerdns option won’t work (even if all addresses are statically configured).

1. From the Control Panel, open the Network Connections applet.
2. Double-click the connection you want to configure.
3. Click the Properties button.
4. Double-click Internet Protocol (TCP/IP).
5. To enable DHCP, select Obtain an IP address automatically. To use a static address, select Use the following IP address. Then configure the IP address, subnet mask, and default gateway.
6. Click OK until all windows are closed.

Using a command-line interface

The following command configures DHCP for a connection:

> netsh int ip set address name="<ConnectionName>" source=dhcp

Here is an example for configuring the connection named “Local Area Connection” to use DHCP:

> netsh int ip set address name="Local Area Connection" source=dhcp

This configures a connection with a static IP and default gateway:

> netsh int ip set address name="<ConnectionName>" source=static <IP> <Mask> <GateWayIP> <Metric>

This example configures a static IP address for “Local Area Connection”:

> netsh int ip set address name="Local Area Connection" source=static 10.3.53.3
255.255.255.0 10.3.53.1 1

Using VBScript

' This code enables DHCP for the specified connection.
' ------ SCRIPT CONFIGURATION ------
strComputer = "."
strConnection = "Local Area Connection"
' ------ END CONFIGURATION ---------
set objWMI = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
set colNA = objWMI.ExecQuery("select * " & _
                             " from Win32_NetworkAdapter " & _
                             " where NetConnectionID = '" & strConnection & "'" )
for each objNA in colNA
   set colNAConfig = objWMI.ExecQuery _
      ("ASSOCIATORS OF {Win32_NetworkAdapter.DeviceID='" & _
        objNA.DeviceID & "'} " & _
      " WHERE resultClass = win32_NetworkAdapterConfiguration ")
   for each objNAConfig in colNAConfig
      if objNAConfig.DHCPEnabled = True then
         WScript.Echo "DHCP already enabled for " & strConnection
      else
         intRC = objNAConfig.EnableDHCP( )
         if intRC = 0 then
            WScript.Echo "DHCP Enabled for " & strConnection
         elseif intRC = 1 then
            WScript.Echo "You must reboot to start using DHCP for " & _
                         strConnection
         else
            WScript.Echo "There was an error enabling DHCP for " & _
                         strconnection & ": " & intRC
         end if
      end if
   next
next

' This code configures an IP address, subnet mask, and default gateway
' for the specified connection.
' ------ SCRIPT CONFIGURATION ------
strComputer = "."
strConnection = "Local Area Connection"
strIP = Array("1.22.2.2")
strMask = Array("255.255.255.0")
strGatewayIP = Array("1.2.3.3")
' ------ END CONFIGURATION ---------
set objWMI = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
set colNA = objWMI.ExecQuery("select * " & _
                            " from Win32_NetworkAdapter " & _
                            " where NetConnectionID = '" & strConnection & "'" )
for each objNA in colNA
   set colNAConfig = objWMI.ExecQuery _
      ("ASSOCIATORS OF {Win32_NetworkAdapter.DeviceID='" & _
        objNA.DeviceID & "'} " & _
      " WHERE resultClass = win32_NetworkAdapterConfiguration ")
   for each objNAConfig in colNAConfig
      intRC = objNAConfig.EnableStatic(strIP,strMask)
      intRC2 = objNAConfig.SetGateways(strGatewayIP)
      if intRC = 0 and intRC2 = 0 then
         WScript.Echo "IP address configured for " & strConnection
      elseif intRC = 1 or intRC2 = 1 then
         WScript.Echo "You must reboot for the changes to take effect for " & _
                      strConnection
      else
         WScript.Echo "There was an error configuring IP for " & _
                      strconnection & ": " & intRC & " and " & intRC2
      end if
   next
next

If you use static IP addresses, any time you build a new server, you have to configure an IP address on that server. However, there is no reason why you can’t automate the process using either the netsh command shown in the command-line solution or WMI. You still have to find an available IP address, which may not be easy to automate depending on your environment, but at least you can provision the IP address in an automated fashion.

This leads to a discussion of using DHCP on servers. You’ll find some people dead set against it and others who wouldn’t do it any other way. Since network adapters are by default configured to use DHCP, you can remove the step of configuring network settings, such as IP address, DNS servers, etc., on your servers by using DHCP. After the server completes the build process and reboots, it will automatically request an IP address. But as you probably know, DHCP addresses aren’t set in stone. The next time the server reboots, it might obtain a different address. And since you more than likely want to add an A record (and possibly a PTR record) in DNS for this server, if it got a new address, those records would no longer be valid.

There are two ways to work around this. First, you can configure a reservation on the DHCP server for a specific IP address. You only need to retrieve the MAC address of the server’s network adapter order to configure a reservation (you can get this via the ipconfig /all command). With this configuration, the server will always receive the same IP address even though it is getting it from DHCP. The benefit of this is that you don’t have to manually configure the other settings such as DNS and WINS servers directly on the server. The potential drawback is that if you have to change network adapters for any reason, the reservation would also have to be updated.

The second option is to use dynamic DNS to have the server automatically update DNS based on its current IP address. In fact, you could have the sever itself send the dynamic updates or use DHCP to do that. That way, even if the server gets a new IP address after every reboot, DNS will be updated automatically. The benefit to this is that it is the most automated solution. There is very little configuration you have to do on a per-server basis (and it is therefore attractive for large environments). The downside is that DNS could have outdated information for a period of time until the server dynamically updates its new information.

Set up a caching name server. Then add zone blocks to named.confto define the new zones for your LAN hosts, and construct the zone files.

Table 1 lists the five hosts on windbag.net.

Add these zone blocks to named.conf:

zone "windbag.net" IN {

  type master;

  file "zone.net.windbag";

};

zone "12.11.10.in-addr.arpa" {

  type master;

  file "revp.10.11.12";

};

Here is the actual zone file for windbag.net:

// zone.net.windbag

// dns zone for for windbag.net

;

$ORIGIN windbag.net.

$TTL 1D

; any time you make a change to the domain, bump the

; "serial" setting below. the format is easy:

; YYYYMMDDI, with the I being an iterator in case you

; make more than one change during any one day

@     IN SOA   parsley hostmaster (

                        200405191 ; serial

                        8H        ; refresh

                        4H        ; retry

                        4W        ; expire

                        1D )      ; minimum

; parsley.windbag.net serves this domain as both the

; name server (NS) and mail exchange (MX)

                NS      parsley

                MX      10 parsley

; define domain functions with CNAMEs

ftp             CNAME   sage

www             CNAME   rosemary

; just in case someone asks for localhost.windbag.net

localhost       A       127.0.0.1

; our hostnames, in alphabetical order

rosemary            A       10.11.12.3

sage                A       10.11.12.2

parsley             A       10.11.12.1

thyme               A       10.11.12.4

cilantro            A       10.11.12.5

And finally, here are the reverse lookups for the domain in the revp.10.11.12 file:

; revp.10.11.12

; reverse pointers for 10.11.12.0 subnet

;

$ORIGIN 12.11.10.in-addr.arpa.

$TTL 1D

@     IN SOA  parsley.windbag.net. hostmaster.windbag.net. (

              200405190  ; serial

              28800      ; refresh (8 hours)

              14400      ; retry (4 hours)

              2419200    ; expire (4 weeks)

              86400      ; minimum (1 day)

              )

; define the authoritative name server

              NS      parsley.windbag.net.

; our hosts, in numeric order

1             PTR     parsley.windbag.net.

2             PTR     sage.windbag.net.

3             PTR     rosemary.windbag.net.

4             PTR     thyme.windbag.net.

5             PTR     cilantro.windbag.net.

Save your changes and restart BIND:

# /etc/init.d/named restart

And there you are—a shiny new fully functioning DNS server for your LAN.

There’s a whole lot happening in these three files. First of all, putting each zone into its own file is good organization. You may dump everything into a single zone file if you like, but you’ll find that it’s difficult to maintain.

In named.conf, the entries for windbag.net tell BIND that it is the authoritative server for windbag.net, and where to find the zone files.

The $origin directive is a nice timesaver. It lets you write:

$ORIGIN windbag.net.

www           CNAME   rosemary

instead of:

www.windbag.net    CNAME     rosemary.windbag.net

$TTL 1D sets a default time-to-live value. Values can be in this format:

w

For week

d

For day

h

For hour

m

For minute

s

For second

Individual entries may have their own TTL values:

rosemary      72h    A       10.11.12.3

The TTL tells visitors how often to refresh their own caches. If your site is fairly static, set this to a higher value. If you’re making frequent changes, use a lower value. The lower the TTL, the more hits there will be on your server.

@ IN SOA parsley hostmaster means:

@

This holds the same value as $ORIGIN.

IN

This defines the address class; IN = Internet.

SOA

Start of Authority; the beginning of a zone file. Only A records can be used as the MNAME—don’t use CNAMEs.

The SOA has 10 fields. These are the primary domain name, zone class, and SOA, plus the following:

MNAME

The master name server for the zone.

RNAME

The email address of the domain admin.

Serial number

BIND converts zone files into a binary file format. When you make changes to the zone file, you must also change the serial number, or BIND will not recognize the changes.

Refresh

This tells your slave, or secondary servers how often to check for updates.

Retry

If the master DNS server for the zone fails to answer a slave server’s request for an update, this tells the secondary server how often it should resend the request.

Expire

If the master DNS server fails for a longer period of time, this tells the the secondary server how to continue to use its existing data. After the expire time has passed, the data is considered stale and will not be used, at which time the domain will no longer resolve. Hopefully your master server will be back online before this happens.

Minimum, or Negative-caching TTL

Negative answers (such as when a requested record does not exist) should also be cached on nonauthoritative servers. Setting this value prevents your server from getting hammered by a bunch of repeated requests in a short time. A common use for this is when you are migrating to a new name server at a different IP address; setting a short value on the old server a few days before you take it offline assures that your change will propagate quickly.

The next section contains resource records (RRs).

NS parsley and MX 10 parsley define your name server and mail server. If you have more than one mail server for the domain, the number sets the priority. Lower numbers are higher priority. Because $ORIGIN windbag.net. defines the domain name for the whole record, these expand to ns.windbag.net and mx.windbag.net. Make note of the trailing dot—this is very important! That defines the qualified domain name. If you leave it off, BIND will think it needs to append the domain name, so you’ll have silliness like ns.windbag.net.windbag.net.

CNAME (canonical name) is an alias to an A record. Thus, a single A record can have several aliases. You can use a CNAME to add subdomains for virtual web or mail hosting—for example, programmers.only.domain.com or webmail.domain.com.

Instead of using CNAMES, you may assign subdomains their own A records. This means one less hit on your server per CNAME request, but it also means more work when you need to make changes. Endless debates rage over the use of CNAMEs; use what suits you.

"Canonical" is one of those weirdo geek words that defies a precise, logical definition. In this context, "canonical name" means "an alias assigned to the true (canonical) name of the server."

And finally, we come to the A (alias) records. An A record is the primary address for each of your hosts, the direct match of hostname to IP address.

Reverse pointers (RPTs) are technically not required, but in the real world so many servers require them that you had better use them.

If things are not working right, chances are it’s a syntax error or a typo—mind your dots and commas especially. There are two syntax checkers for BIND to help you.

The other common error is not starting from A records. Every host must first have an A record. Then you can assign name servers, mail servers, and CNAMEs.

Install BIND on a Linux machine with a static IP address. Be sure you get the latest version. Don’t mess with older versions, as they are buggy and exploitable. After installation, you’ll have four configuration files to edit or create:

• named.conf
• named.root
• zone.localhost
• revp.127.0.0

Al of these files are in /var/named, except for /etc/named.conf. named.confis the standard name for BIND’s configuration file; all the others you can name to suit yourself. Here is a sample named.conf:

//BIND configuration file

//named.conf for caching server

options {

// where all zone files are

  directory "/var/named";

// accept queries only from local subnet

  listen-on {

           127.0.0.1;

           10.11.12.1;

    };

  allow-recursion {

           127.0.0.0/8;

           10.11.12.0/24;

    };

};

zone "." IN {

     type hint;

     file "named.root";

};

// location of the zone file for localhost

zone "localhost" IN {

  type master;

  file "zone.localhost";

  allow-update { none; };

};

// reverse pointer file for localhost

zone "0.0.127.in-addr.arpa" IN {

  type master;

  file "revp.127.0.0";

  allow-update { none; };

};

Now add named.root.This is the master list of the root name servers; simply fetch the current version from ftp://ftp.internic.net/domain/named.root, and put it in /var/named.

Now create zone.localhost:

; zone.localhost

; loopback/localhost zone file

;

$TTL 1D

$ORIGIN localhost.

@              IN  SOA   @  root (

                         1   ; Serial

                         8H  ; Refresh

                         15M ; Retry

                         1W  ; Expire

                         1D) ; Minimum TTL

               IN   NS   @

               IN   A    127.0.0.1

Finally, create revp.127.0.0:

; revp.127.0.0

; reverse pointers for localhost

;

$TTL 1D

$ORIGIN 0.0.127.in-addr.arpa.

@    IN   SOA  localhost. root.localhost. (

               1    ; serial

               8H   ; refresh

               15M  ; retry

               1W   ; expire

               1D ) ; minimum

     IN   NS   localhost.

1    IN   PTR  localhost.

Then start up BIND:

# /etc/init.d/named start

You now have a local caching name server. See this to learn how to connect client PCs to your caching server.

named is short for "name daemon."

BIND configuration files can grow and multiply like weeds, so using a naming convention like the one shown here will save your sanity. Zone files each start with "zone," and reverse pointer files start with "revp." You may call them anything you want, as long as you use a consistent naming scheme.

You can use each one of these sample files exactly as they are shown. The only change you might need to make is the listen-on directive in named.conf—be sure to use your own network IP addresses. Leave localhost exactly as it is shown, unless you’re using some exotic networking voodoo, in which case you already know what to do. Do not allow traffic from outside your network! There is no reason for you to supply caching services to the world.

The named.root filedoes not change very often. Check it every few months just for kicks. You may call it anything you like, as long as you record the filename in named.conf.

zone.localhost tells named that the address of localhost is 127.0.0.1.

revp.127.0.0 does the opposite of zone.localhost—it tells named that the hostname associated with the IP address 127.0.0.1 is localhost.