We all have had problems with machines being overrun by malware: taking 20 minutes to startup,
constant popups, hijacking of the home and search pages, bookmarks being added, etc.
Malware can even turn a machine into a "zombie", and be an unwilling participant in
spam sending/relaying, address harvesting, or DDOS attacks against other computers.

One of the more popular techniques for fighting malware among home users is through the use
of a host file for DNS redirection.
A host can be used to maps hostnames associated with malware to a different IP address (such as
a loopback address, 127.0.0.1). This will prevent connections to those malicious sites from ever taking
place.
(There is an irony here, as some of the more "evil" malware hijacks your host file to prevent
their removal or to redirect search queries).

Unfortunately, there are several problems with using host files, especially in a corporate environment:

There needs to be an exact entry in the hosts file for each malware host/domain combination.
Even within the same domain, there must separate host entry.
For example, there must be individual entries
for www1.malwaresite.com, www2.malwaresite.com, www3.malwaresite.com,
www4.malwaresite.com, etc. A host not listed (such as www5.malwaresite.com) will continue to
be resolved to the actual malware-associated site.
(This is a major problem with pattern-matching spam filters, and will become
even more of a problem as "wildcard dns" continues to increase in popularity.). Major malware
players may have dozens of hosts per domain. This causes the host file to become quite
large.

While a small hosts file will speed up browsing (since anything listed in the file
are not downloaded to the desktop, some
issues have
been reported with very large host files.

Updating multiple host files on a corporate LAN can quickly become unwieldly.
Because there is no centralized administration point,
a single change must be pushed to every client. (If the host file is copied via a login script,
the network admin would have to ensure that user logs into the domain on a daily basis
to receive the latest file). Also, copying host files via a login script may be problematic if the
user does not have permissions to overwrite their local host file.

Many of the host files available on the internet include adservers, which may
not be appropriate to block in corporate
environments or for users who wish to see the ads.

Some of the "anti-adware" host files and utilities are not free for corporate environments.

As an alternative to host files, there are several desktop-based DNS software packages
available which are designed for use on a single desktop. These packages
were originally designed as a substitute for a large host file in order to speed up browsing by having
a local name server available to cache domain queries such as
DNSKong. These programs
can also be used to block domains associated with malware. However, they only work on the local
machine or perhaps a home network.

A standard format for DNS entries is called "Bind Format". In most instances of bind, there
are two files of interest: the
master config file (called named.conf on most machines) and the "zone" file associated with each
administered domain (usually called something like "domainname.zone.dns").

There is usually one zone file per domain, but
for the purposes of blocking malware,
a single zone file can be associated with multiple malware-associated domains.

While you could add domains directly into the named.conf, an include statement
lets you place all of the blocked domains in a single file, which will make the file
portable and easier to replace. It also keeps the named.conf file safe from accidental corruption.

Debian and other Linux distros already have a file called "named.conf.local" so we'll use that as an
example. Make sure the file is located in the same working directory as the named.conf file or add
the full path to the file (such as /etc/namedb/named.conf.local or /etc/bind/named.conf.local).

For example, the following entries in the named.conf.local will add the domains "coolwebsearch.com" and
"gator.com" to the local DNS server (The full list can be downloaded HERE):

(The directory /etc/namedb may need to be changed to /etc/bind, /etc/named, or
deleted altogeter depending upon your system. )

You may also wish to add your own domain information to the named.conf
file, in order to
keep all of the zones in the same place. There are some differences on
a W2K DNS server, which will be explained further in the next section.

Blockeddomains.zone.dns is the file containing information about the hosts in the
"coolwebsearch.com" and "gator.com" domains. Of course, in our case, the information in this file
will not contain the information placed there by the owners
of the domains. Rather, it contains the information we placed there.

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,
It will answer as if it is "authoritative" for the "coolwebsearch.com"
domain
and will not query to see if it can find a record on an upstream DNS
server with better credentials. It will look up the information about
the "coolwebsearch.com" domain in the local file
"blockeddomains.zone.dns":

The * in the line * IN A 127.0.0.1
is a wildcard, which means
that 127.0.0.1 will be returned for any hostname within that domain:
www1.coolwebsearch.com, www2.coolwebsearch.com,
ihatemalware.coolwebsearch.com, anythinghere.coolwebsearch.com will all
be resolved to 127.0.0.1.

This single file will be used for all malware-associated domains. Most of the actual content of this file is not important,
as it is not serving up information for a "production" domain. (You need to be much more careful with an
actual domain!) You should probably change the "ns0.example.net." and "ns1.example.net" to your own
information.
You may need to change the 127.0.0.1 to 0.0.0.0 or to an internal server, as discussed above.

Instead of querying an upstream DNS server for
the answer, your local DNS server believes it is a "master" for the "coolwebsearch.com" domain.
It will therefore "answer" any queries for a host within that domain with 127.0.0.1 or whatever IP
address you placed in the zone file.

In "production" domains, the values for TTL, refresh, retry, etc. may need to be
tweaked for your configuration. In addition, when a change is made (such as adding or modifying a host),
the serial number needs to be incremented. However, since this "dummy" file should never change,
the serial number is not important.

Several LiveCD distributions (such as Knoppix-STD a
and NST) contain the named program (which is
used to start up the BIND daemon)
and can be used for testing.
More information on testing the new zones is located later in this paper.

If you insist on keeping Microsoft's DNS server, I believe I have found the least painful way to
add many zones at once. (Another way, which involves importing entries into the registry,
is described here.

By default, Microsoft's W2K DNS uses the registry to load up the boot
information that instructs the DNS server on which zones to load at
startup (as well as other parameters). Adding additional domains must
be done via the GUI, which makes it cumbersome if many domains are to
be added. In addition, a "wildcard DNS" entry cannot be added via the
DNS GUI.

There is a simple workaround,
which is to
configure DNS to use a text file instead of the registry to load the
zones at startup. This has the added advantage of making Microsoft DNS
more compatible with Bind format, as well as making it easier to
migrate DNS to other machines. The boot file's default name in Windows
2000 is boot (without any extension), and is located in the
%SystemRoot%\System32\DNS
folder (usually c:\windows\system32\DNS, it may be different in Win2003
Server or for sites running Active Directory. If this is the case,
please let us know so we can update this document.)

After some experimentation, the easiest way I have found to create a blackhole
zone file which can be used for multiple zones is: 1) create a single
blackhole zone via the MS DNS console; 2) reconfigure the MS DNS server to load it's
zones via a boot file (instead of the registry), and 3) add additional malware zones
to the boot file.

1. Create a single blackhole zone fileFrom within the MS DNS
Console, select "Forward Lookup Zones" and select
action --> New Zone. Create a "Standard Primary" zone, and call the
zone something like "blockeddomains.com" and press Next twice. This
will create a file called "blockeddomains.com.dns". Double-click on the
new entry, which should be
listed under "Forward Lookup Zones". Add a single host called "www" to
the file with an IP address of 127.0.0.1 (or, as discussed earlier,
0.0.0.0 or an internal server). Then under "Actions", select "Update
Server Data File."

The Microsoft blockeddomains.com.dns zone file will look something like this:

The lines referring to the domain (blockeddomains.com) and
nameserver (nameserver.blockeddomains.com) will be specific to your
domain.

Open the file in Notepad or another text editor, and add these lines to the bottom
of the file:

Additional Lines:

; wildcard dns
* A 127.0.0.1
;

If you are using Notepad, then please remember to save files
without the ".txt" extension. The file should now be configured for
"Wildcard DNS".

2. Configure the DNS server to load it's zones via the boot file instead of
the registry
To create a boot file, all you need to do is reconfigure the MS DNS
server to load it's zones
from the boot file instead of the registry. That will automagically
create the boot file for all of the existing zones. (This is roughly
equivalent to the named.conf file.)
From the MS DNS console, right-click the local DNS server, select
"Properties", select the "Advanced" tab, and change the "Load zone data
on startup:" setting to "From File".
This will create (or update) the existing sample boot file.

According to this source,
If you are using Active Directory, you may need to check the properties
of each zone and change zones of type "Active Directory-integrated" to
"Standard...", and then repeat above.

You can still manage zones from Microsoft's DNS Manager even when you start from the boot file, and
the registry is still used for parameters which cannot be specified in the boot file.
The "boot" file should look something like this:

If you are using Notepad, then please remember to save files
without the ".txt" extension. The file should now be configured to be a
"master" for the "coolwebsearch.com" and "gator.com" domains. Any
queries for a host in that domain will be "answered" by your local DNS
server as "127.0.0.1" or whatever IP address you assigned.

Blockeddomains.zone.dns is the file containing information about the
hosts in the "coolwebsearch.com" and "gator.com" domains. Of course, in
our case, the information in this file will not contain the information
placed there by the owners
of the domains. Rather, it contains the information we placed there.

Instead of querying an upstream DNS server for
the answer, your local DNS server believes it is the "master" and
"authoritative" for the "coolwebsearch.com" and "gator.com" domains. It
will therefore "answer" any queries for a host within that domain with
127.0.0.1 or whatever IP address you placed in the zone file and will
not query to see if it can find a record on an upstream DNS server with
better credentials.

Another way to create a zone file is to convert one of the more popular host files.
One of the better programs to convert host files to BIND format is also located on
Peter Lowe's site. Sites with host files are listed at the end of this paper.

However, these host files include the domain names of adservers, such as doubleclick, which may
not be appropriate to block in corporate environments or for users who wish to see the ads. Also, with the
recent exception of MVPS, these
files are not designed with the prevention of malware in mind.

We have made available a "black hole" DNS zone files
in both "Bind" format and "Microsoft" format. We've made every attempt
to only include domains associated with malware.

The files containing these malware-associated domains can be downloaded
Here.