DNS is the Domain Name System. It's a UDP- and TCP-based protocol that listens on port 53. TCP connections are commonly used for zone transfers.

The DNS matches IP addresses to hostnames (and hostnames to IP addresses). A DNS server is responsible, or authoritative, for a given part of the domain name system (for example, mybitofthenet.com).

Clients make requests of the DNS servers when they want to communicate with systems for which they have only the fully qualified hostname (for example, myserver.mybitofthenet.com).

The DNS is a critical part of the network infrastructure. Its failure—whether through administrative incompetence or denial of service—can have major consequences.

DNS Risks

The DNS protocol has security problems. A detailed description of DNS and its protocol weaknesses can be found at http://www.geocities.com/compsec101/papers/dnssec/dnssec.html. DNS is defined in a number of RFCs—see http://www.dns.net/dnsrd/rfc/ for full details.

As far as UNIX host security goes, the most widely used DNS server software is BIND (Berkeley Internet Name Daemon), developed by the Internet Software Consortium (ISC). By default, the BIND daemon "named" runs with root privileges and—this is important—it doesn't permanently throw them away after binding to port 53. Therefore, vulnerabilities in BIND can result in a complete system compromise.

Let's look at the track record of BIND.

Release 8.2.3 was released in January 2001 to fix four security vulnerabilities discovered by COVERT Labs (PGP security) and Claudio Musmarra. Two buffer overflows allow remote attackers to run any code of their choosing. An input validation error enables attackers to run any code, and an information leakage allows data in the stack to be viewed by an attacker. This last one might not seem so bad. After all, it's not a direct root compromise in-waiting, but it actually assists the development of exploits against a particular site. The stack holds local variables, environment variables, and important process addresses. By gaining access to these, a buffer overflow can be written without trial and error. This is significant because buffer overflows are often a one-shot attack—if you get it even slightly wrong, you are likely to crash a service by scribbling all over stack data subsequently relied upon by the program.

BIND has had 12 security advisories from CERT in just four years—hardly an endorsement of BIND security!

A major factor is the complexity of the BIND code. Experienced C programmers comment that the BIND code is incredibly difficult to understand. When accomplished programmers struggle to comprehend what's going on, you can be sure of security problems. Complex code is hard to audit—modular designs work best, in which small, discrete programs (that are easier to audit) perform privileged operations. Of course, the ISC developers didn't set out to write something that even they would find hard to maintain—the difficulty is a result of feature bloat. Perhaps that's one of the reason's ISC recently rewrote major parts of BIND.

In January 2001, ISC announced the release of a major new version of BIND—version 9.1.0. This version includes support for DNSSEC—a protocol extension that overcomes some of the security design weakness in the stock DNS protocol (DNSSEC is defined in RFC 2535.) Notably, the code was not modularized, so now we have new code that is still hard to audit. Many sites are likely to continue running BIND 8, at least in the short term.

It turns out attackers like breaking into BIND servers, so much so that SANS rates unpatched BIND servers as the number one security problem on the Internet. Exploits for BIND abound. DNS servers are tasty targets because so much of the Internet relies upon then. With control of a BIND server, you can do truly nasty things, for example:

· Deprive a site of traffic by changing the IP/name mappings to a nonexistent address. Worse still, you can redirect traffic to a pornographic or competitor site. Lost revenue and bad press don't help a company's stock price.

· Clone an e-business site, modify the site's DNS server to map your imposter site, and collect credit card details, user account, and password details.

· Exploit trust relationships between systems by mapping an IP from one side of the trust relationship to your machine.

· Compromise one of the root nameservers.

That last one is particularly worrying. The root nameservers are the starting point for addressing on the Internet. There are only 13 root nameservers in total (because of protocol limitations). Take over the root nameservers, and you can have the Internet in your hand. As an aside, the choice of platform and operating systems for these machines follows the principle of security through diversity. To quote from a Y2K statement on ICANN's (The Internet Corporation for Assigned Names and Numbers) site:

The root servers themselves all use some variant of the UNIX operating system, however both the hardware base and the vendors'UNIX variants are relatively diverse: of the 13 root servers, there are 7 different hardware platforms running 8 different operating system versions from 5 different vendors.

This is a sound idea—used in nature by Mother Nature herself. Of course, it breaks down if you don't have sufficiently diverse administrators on hand to securely manage eight different operating systems.

Aside from security flaws, misconfiguration is common. When sizing up your site, attackers will request zone transfers from your DNS server. This is basically a dump of all the information pertaining to a particular DNS zone. This is as good as a network map! You don't want this.

Another configuration is version numbers (again). To discover the version of BIND you are running, a client can query your DNS server, and your server will tell them. This isn't so good.

The other major risk facing the DNS protocol and the BIND implementation are denial of ser vice attacks. Numerous DoS vulnerabilities have been found in BIND. Disabling DNS servers prevents DNS queries from being resolved, thereby stopping clients relying on the DNS resolution services (that is, almost everyone) in their tracks.

Securing DNS

The obvious countermeasure is to find an alternative to running BIND. Here your choices are limited—we live in a BIND monoculture. You could switch to Microsoft's DNS implementation (that's not a recommendation), or look for a DNS server where security of implementation was a primary goal.

The only viable alternative I am aware of is the djbdns package by Daniel Bernstein. This has had sufficient production usage to be a serious contender to BIND. It was designed and written with security in mind by a programmer experienced in writing secure code. You can find out more here: http://cr.yp.to/djbdns.html.

If you stick with BIND, there are some things you can do. A useful summary of the issues and countermeasures is available from http://www.acmebw.com/papers/securing.pdf. You should at least give serious thought to the following

· Don't run BIND as root. Instead, create a new user and group. Specify these as command-line options when you execute BIND.

· Use the chroot command to run BIND so that it has restricted access to the filesystem. The chroot program enables you to specify the directory that a process will treat as its root directory (enforced by the kernel). To do this though, you need to create a mini duplicate of your operating system because BIND will no longer be able to see important system libraries and configuration files. Full instructions can be found here: http://www.etherboy.com/dns/chrootdns.html.

· The version number is hard-coded in the BIND code, so if you have source code, you can simply remove it or replace it with a fake version or silly message (have fun). Otherwise, you'll have to binary patch the executable—good luck! Recent versions of BIND can be configured to enable version requests from specific addresses only.

· Configure BIND to disallow zone transfer except to authorized servers (such as DNS slaves).