Securing DNS and BIND

In the SANS Institute's recent consensus document “How to Eliminate the Ten Most Critical Internet Security Threats” (www.sans.org/topten.htm), the number-one category of vulnerabilities reported by survey participants was BIND weaknesses. BIND, of course, is the open-source software package that powers the majority of Internet DNS servers. In fact, again according to SANS, over 50% of BIND installations are vulnerable to well-known (and in many cases, old) exploits.

The good news is that armed with the simple concepts and techniques I'm about to describe, you can quickly and easily enhance BIND's security on your Linux (or other UNIX) DNS server. Since our focus here will be security, if you're an absolute BIND beginner you may wish to first start reading the BIND online documentation (see Conclusions, at end) or the first chapter or two of Albitz and Liu's book DNS and BIND.

Having said that, let's begin with a brief look at how the Domain Name Service and BIND work. Suppose someone (myhost.someisp.com in Figure 1) is surfing the Web, and wishes to view the site http://www.wiremonkeys.org/. Suppose, also, that person's machine is configured to use the name server “ns.isp.com” for DNS lookups. Since the name www.wiremonkeys.org has no meaning to the routers through which the web query and its responses will pass, the user's web browser needs to learn www.wiremonkeys.org's IP address before attempting the query.

Figure 1. myhost.someisp.com

First, “myhost” asks “ns” whether it knows the IP address. Since ns.someisp.com isn't authoritative for wiremonkeys.org and hasn't recently communicated for any host that is, it begins a query of its own on the user's behalf. The process of making one or more queries in order to answer other queries is called recursion.

ns.someisp.com begins its recursive query by asking a “root name server” for the IP address of some host that's authoritative for the zone wiremonkeys.org. (All Internet DNS servers use a static “hints” file to identify the thirteen or so official root name servers. This list is maintained at ftp.rs.internic.net/domain and is called named.root.) In our example, ns asks E.ROOT-SERVERS.NET (an actual root server, with a current IP address of 192.203.230.10), who replies that DNS for wiremonkeys.org is handled by “ns-wiremonkeys.wiremonkeys.org”, with an IP address of 55.100.55.100.

ns then asks ns-wiremonkeys for the IP address of www.wiremonkeys.org. ns-wiremonkeys returns the answer (55.100.55.200), which ns forwards back to myhost.someisp.com. Finally, myhost contacts 55.100.55.200 directly via HTTP and performs the web query.

This is the most common type of name lookup. It and other single-host type lookups are simply called “queries”; DNS queries are handled on UDP port 53.

Not all DNS transactions involve single-host lookups, however. Sometimes it is necessary to transfer entire name-domain (zone) databases: this is called a zone transfer, and it happens when you issue an ls command from the nslookup utility, or run dig. The main purpose of zone transfers, however, is for name servers that are authoritative for the same domain to stay in sync with each other (e.g., for “master to slave” updates). Zone transfers are handled on TCP port 53.

The last general DNS concept we'll touch on here is caching. Name servers cache all local zone files (i.e., their hints file plus all zone information for which they are authoritative), plus the results of all recursive queries they've performed since their last startup. That is, almost all: each resource record (RRs) has (or inherits their zone-file's default) time-to-live settings. These settings determine how long each RR can be cached before being refreshed.

This, of course, is only a fraction of what one needs to learn in order to fully understand and use BIND. I haven't even mentioned forwarders or reverse lookups. Hopefully, it's enough for the purposes of discussing BIND security.

DNS security can be distilled into two maxims: always run the latest version of your chosen DNS software package, and never provide unnecessary information or services to strangers. Put another way, keep current and be stingy!

This translates into a number of specific techniques. The first is to limit or even disable recursion. Limiting it is easy to do using configuration-file parameters; disabling recursion altogether may or may not be possible, depending on the name server's role.

If, for example, the server is an “external” DNS server with the sole purpose of answering queries regarding its organization's public servers, there is no reason for it to perform lookups of nonlocal host names (which is the very definition of recursion). On the other hand, if a server provides DNS resolution to end users on a local area network (LAN), it definitely needs to recurse queries from local hosts, but can probably be configured to refuse recursion requests, if not all requests, from nonlocal addresses.

Another way to limit DNS activity is to use split DNS services (see Figure 2). Split DNS refers to the practice of maintaining both public and private databases of each local name domain (zone). The public zone database contains as little as possible: NS records listing publicly accessible name servers, MX records listing external SMTP (e-mail) gateways, public web servers and other hosts that one wishes the outside world to know about.

Figure 2. Split DNS

The private zone database may be a superset of the public one, or it may contain entirely different entries for certain categories or hosts. For example, many organizations use a Microsoft Exchange server for internal e-mail, but maintain a completely separate SMTP gateway system to receive mail from the outside world. This is sometimes actually the organization's firewall, or perhaps a dedicated mail server in a DMZ network connected to the firewall but separate from the internal network.

The value of such an architecture should be obvious: compromise of the SMTP gateway does not automatically result in the exposure of internal e-mail to outsiders. Other services commonly split this way are WWW (which separates public web data from intranet data), FTP, and virtually all other TCP/IP services for which it's desirable to differentiate between public and private data. DNS, however, is arguably the most important service to split, since most other TCP/IP services depend on it.

The other aspect to DNS stinginess is the content of zone files themselves. Even public zone databases may contain more information than they need to. Hosts may have needlessly descriptive names (e.g., you may be telling the wrong people which server does what), or too much or too granular contact information may be given. Some organizations even list individual systems' hardware and software names and versions! Such information is almost invariably more useful to prospective crackers than their intended audience.

Maintaining current software and keeping abreast of known DNS exposures is at least as important as carefully considering actual DNS data. Furthermore, it's easier: the latest version of BIND can always be downloaded for free from ftp.isc.org, and information on BIND vulnerabilities is disseminated via not only one, but several mailing lists and newsgroups (some of which are listed at the end of this article).

There's actually a third maxim for DNS security, but it's hardly unique to DNS: take the time to understand and use the security features of your software (and of your DNS-registration provider—Network Solutions and other top-level-domain registrars all offer several change request security options, including PGP. Make sure that your provider requires at least e-mail verification of all change requests for your zones!).