Hardening the BIND DNS Server

This paper presents the risks posed by an insecure DNS server and walks through compiling, installing, configuring and optionally, chroot'ing BIND 8. The test environment is Solaris 2.5, 2.6, 7 and 8. Many configuration and troubleshooting tips are provided, along with up-to-date references on BIND and alternatives for NT, Linux and Solaris.

 By Sean Boran
Page 1 of 5
Print Article

Editor's Note

Your Domain Name Service is the road sign to your systems on the Internet. No matter how secure and robust your Web, mail and other servers are, compromised and corrupted DNS systems can prevent customers and legitimate users from ever reaching you.

DNS, like many of the older protocols, was developed at a time when the Internet was a kinder, gentler place and was meant to provide a simple and unlimited way to provide information about what computers you have to anyone else. Obviously, the model of the Internet has changed, and changes to BIND (Berkeley Internet Name Domain software, the most common implementation of DNS), along with widely accepted configuration guidelines, have improved our ability to lock down DNS.


BIND (the Berkeley Internet Name Domain) 1 is the most frequently used DNS server, maintained by the ISC. It is also known as "named," since this is the name of the actual daemon itself. BIND has a long history, is a core tool for most Internet sites and is currently at V8.

As with many applications exposed to the increasingly hostile Internet environment, security weaknesses have been discovered in BIND.

Why bother? What risks does an insecure BIND pose?

So what, you say? Yet another program with security problems? There are so many problems in so many applications these days, it's just not possible to keep up with all these advisories and patches. Do we really have to worry about DNS too? Well, a compromised DNS server can pose some interesting risks:

  1. An attacker can gain much interesting information if zone tranfers are allowed: the entire list of hosts and routers with IP addresses, names and possible even comments indicating location, names etc.

  2. Denial of service: If all your Internet DNS servers go down,
    • Your Website is no longer visible (other Websites can't look up your IP address).
    • Emails can't be delivered (some other Internet sites that you frequently exchange data with may have cached DNS entries, but they won't last more than a few days).
    • An attacker could start up a fake DNS server that pretends to be yours and delivers false DNS information to the Internet about your domain. That is, integrity is lost - see next section.

  3. Loss of integrity: If an attacker can change the DNS data or spoof other sites into believing false data (this is known as DNS poisoning), it gets very dangerous:
    • Fake Websites can be set up to look like yours and capture user input destined for your site, which may be anything from user/passwords to PINs to account information.
    • All email can be diverted to a relay which can copy, change or delete email before passing it to your site.
    • If your firewall or any Internet-accessible host uses DNS hostnames for authentication or trust relationships, these can be completely compromised, especially if a weak packet filter protects the Internet servers and Intranet. Imagine a Web proxy configured to only allow proxy requests from *.mydomain.com. The attacker adds his host to the domain, then the Web proxy may allow requests from him, allowing the attacker HTTP access to the Intranet. Imagine a system administrator who uses SSH (great crypto stuff), but the firewall host has a ".shosts" trust to "admin.mydomain.com," where "admin" is the administrator's workstation. If the attacker can replace the entry for "admin.mydomain.com" in the DNS, he has password-free access to the firewall hosts.

So What Needs To Be Done?

BIND weakness may be addressed with several prevention measures, but detection and reaction shouldn't be forgotten either:

  1. Resource isolation: Use a dedicated, hardened server for Internet DNS, don't share with other services, and especially do not allow user logins. Minimal services/users means reducing the amount of software running and hence the amount exposed to network attacks. Separation prevents other services or users possibly using local weakness in the system to attack BIND.

  2. Redundancy: Install a secondary on a different Internet connection (foreign branch of your company, another ISP, etc.). If your site dies, at least other sites won't think you "cease to exist"; they just think you're "not available," so that emails, for example, won't get lost but will be queued (typically up to four days).

  3. Use the latest version (e.g. 8.2.2-P5 or later, which includes security fixes).

  4. Access control: Restrict zone transfers to minimize the amount of information on your networks available to attackers. Consider using transaction signatures. Consider restricting/not allowing recursive queries.

  5. Run BIND with minimum privileges: Run BIND as a non-root user.

  6. More resource isolation: Run BIND in a "chroot" jail, so it is much more difficult for a compromised bind daemon to damage the operating system or compromise other services.

  7. Detection: Monitor logs for unusual activity; monitor the system for unauthorized changes with an integrity checker; keep an eye on relevant advisories.

The procedure in this paper concentrates only on measures 4), 5) and 6), which should help to protect a server against possible future weakness in BIND. This procedure has been tested on several production systems: a secondary on Solaris 2.5 + 2.8, a primary on Solaris 2.6 + 2.7.

Install and Configure BIND

It is assumed that Solaris is up and running and appropriately hardened and that the BIND delivered with Solaris is disabled. If you have not yet hardened Solaris, check out the YASSP tool first 7. This section runs through:

  1. Compiling BIND on a master host, since you probably don't have (or shouldn't have) a compiler on the hardened DNS server.
  2. Copying and installing BIND on the DNS server.
  3. Setting up DNS data files.
  4. Running BIND.

1. Compiling BIND (on a host with a compiler).

Download the distribution 1, and extract it to a subdirectory and compile. This can be done as any user.

make clean;
make depend && make; 

Now change to the root account, install to a temporary directory, and create a tarball:

su - root
# allow group, but not world access
umask 027
make install DESTDIR=/tmp
cd /tmp/usr/local
tar cf - * | compress > bind_dist.tar.Z

2. Copy and install BIND on the DNS server

Create a user and group account for BIND:

echo "named:x:20000:20000:BIND DNS daemon:/tmp:/bin/false" >> /etc/passwd
echo "named:NP:6445::::::"  >> /etc/shadow
echo "named::20000:" >> /etc/group

Don't allow the BIND account to use ftp:

echo "named" >> /etc/ftpusers

Copy bind_dist.tar.Z to /usr/local on the DNS server and extract into /usr/local:

zcat bind_dist.tar.Z | tar xvf -

Set up file permissions:

cd /var; mkdir named
/usr/ucb/chown -R root.named named
chmod 770 named

touch /var/run/named.pid;
/usr/ucb/chown named.named /var/run/named.pid;

chmod 755 /usr/local /usr/local/bin /usr/local/sbin /usr/local/etc

/usr/ucb/chown root.named /usr/local/bin/{dig,dnsquery,nslookup,nsupdate,host};

chmod 755 /usr/local/bin/ /usr/local/bin/{dig,dnsquery,nslookup,nsupdate,host};

/usr/ucb/chown root.named /usr/local/sbin/{dnskeygen,irpd,named,named-bootconf,named-xfer,ndc};

chmod 755 /usr/local/sbin/{dnskeygen, irpd,named,named-bootconf,named-xfer,ndc};

Optionally, you can rename the default DNS binaries installed on the system, so that they are not used by accident, and leave a reminder.

cd /usr/sbin;
mv nslookup nslookup.old
mv nsupdate nsupdate.old
mv in.named in.named.old
mv named-bootconf named-bootconf.old
mv named-xfer named-xfer.old

Add /usr/local/sbin to the root PATH in /.cshrc or /.profile.

This article was originally published on Dec 5, 2000
Get the Latest Scoop with Networking Update Newsletter