Using BIND: Don't get spoofed again Learn how to secure your Internet domain name servers By Matt Larson and Cricket Liu

November  1997

With the recent publicity over the DNS (Domain Name System) spoofing attack against the InterNIC, it's become painfully obvious just how vulnerable the Internet's DNS infrastructure is. What isn't so obvious, however, is how to protect your name servers against attack. Sure, you should run the latest version of BIND (Berkeley Internet Name Domain), but how should you configure it? Can your firewall help? This article will help you secure your servers that are exposed directly to the Internet, or to any hostile network. (1,700 words)

Mail this article to a friend

efore you begin configuring your DNS server, it is important to understand the differences between the two versions of BIND.

Only the latest versions of BIND, 4.9.6 and 8.1.1, are resistant to the most common attacks we've seen on the Internet. In particular, both versions check to ensure that resource records included in the additional data section of a DNS reply message relate to the records in earlier sections of the message, the answer and authority sections. For example, if you look up an MX record, the additional data section of the reply message you receive should contain address records corresponding to the mail exchangers listed for the destination you looked up. It shouldn't contain arbitrary address records, or any other kinds of records. The attack against the InterNIC exploited this weakness in BIND by injecting spurious records into otherwise legitimate replies.

Be aware, however, that BIND 4.9.6 is the end of the BIND 4 line. Paul Vixie of the Internet Software Consortium says that the organization will do no further BIND 4 development. So unless you simply can't run 8.1.1 or don't have the time to learn BIND 8's new configuration syntax, 8.1.1 is the better bet.

Today, this likely means running an unsupported version of BIND, since most major Unix vendors don't yet ship BIND 8.1.1. (Commercial Linux vendors are the exception.) Sources within sun say that it is on the roadmap for Solaris 2.7 which means that Sun is not likely to support it until the second half of 1998. Still, we strongly recommend you do run one of these two versions because the potential losses you could face from a successful attack on your name servers dwarf the inconvenience of running unsupported code. (And, in the interim, you can lobby your vendor to release a port of BIND 8.1.1 to its OS.)

If you'd like to get the source to BIND 4.9.6 or 8.1.1, go to ftp://ftp.isc.org/isc/bind/src/cur/. You'll find BIND 4.9.6 in the bind-4 subdirectory and 8.1.1 in the bind-8 subdirectory.

Configuring BIND
Now that you've got a nice, new copy of BIND, you'll want to configure it as prudently as possible. If you already have a BIND 4 named.boot file and Perl on the host your name server is on, you can convert it into a BIND 8 configuration file using named-bootconf.pl, in the src/bin/named subdirectory of the extracted tar package.

If you have to build a configuration file from scratch, start by adding an options statement, which configures most of BIND's global settings, and zone statements for each of the zones your name server will load, as master, slave, or as hints. There's some documentation of the new configuration file format in the tar file itself, as well as copies online (see Resources below).

A hints zone contains the names and addresses of the root name servers. The hints zone replaces the BIND 4 cache directive. Also note that slaves were called "secondary master" or "secondary" name survers up until BIND 8.

Next comes the task of securing your name server. Most name servers on the Internet serve two functions: They answer queries about some set of zones that they are authoritative for; these queries come from other name servers. They also answer queries from resolvers about arbitrary Internet domain names, possibly by querying other name servers on the Internet.

Your name server's configuration will be affected if it performs both of these functions. For example, if your name server answers queries from other name servers on the Internet, you probably can't configure it not to answer queries from certain IP addresses.

You should configure your server to respond to zone transfers requests only from authorized IP addresses. In most cases, you'll only authorize your known slave servers. With BIND 8, you can do that within a zone phrase:

     zone "acmebw.com" in {
	type master;
	file "db.acmebw";
	allow-transfer { 128.32.1.2; };
};

This is convenient, since you may have a different set of slaves for each zone.

If you use BIND 8's dynamic update functionality, you'll also want to restrict zone updates to authorized IP addresses. Again, you'd probably do this in the zone phrase:

zone "acmebw.com" in {
	type master;
	file "db.acmebw";
	allow-transfer { 128.32.1.2; };
	allow-update { 128.32.3.4; };
};

Note that if you don't specify an allow-update option, updates are not allowed for that zone, so you'll only need to do this if you actually use dynamic update.

If you use either these or other options mentioned later in this article that rely on IP addresses to make an authorization decision, be sure you have good IP spoofing detection in place -- either on your firewall or on your border router (the router that connects your network to the Internet). At the very least, your router should drop IP datagrams claiming to originate on your internal network if they are received on the router's external network interface (the interface to the Internet).

Splitting functionality
For those who want the best protection against DNS spoofing attacks, our advice is to split your name servers in two. Any one name server should either answer queries from other Internet name servers (known as iterative or non-recursive queries) or should answer queries from resolvers (known as recursive queries). This will help you avert a common variety of attack against your name server: A hacker sets up one or more name servers as authoritative for a zone and configures them to respond to all queries for data in that zone with spoofed data. He then targets one of your servers by pointing a query tool like nslookup at it and sending it a query for a name in his zone, thereby inducing your name server to query one of his. Presto! You've cached his garbage.

With the functionality split between two servers, you can protect yourself. You can configure the name server that will handle other Internet name servers to reject recursive queries. This will make it impossible for a hacker to cause your name server to query his name servers. This options clause turns off recursive queries:

options {
	recursion no;
};

You can protect the other set of name servers -- those answering queries from resolvers -- by configuring them to respond only to queries from authorized resolvers. Again, this will prevent a hacker from inducing your server to query his server. The following options clause implements an IP address-based access list on queries for your whole server, not just for a single zone. (This clause allows queries from any host on the class B network 128.32.0.0, as well as the IP address 127.0.0.1, the local host.):

options {
	allow-query { 128.32/16; 127.0.0.1; };
};

To prevent other kinds of spoofing attacks, you may want to make these name servers authoritative for your important zones. By configuring a name server as a slave for a zone, you indirectly make it more difficult for a hacker to spoof records in that zone, thanks to a relatively new BIND feature called credibility. Authoritative zone data is the most credible data in BIND's hierarchy. Data from direct responses to queries, as well as data in the additional data and authority sections of a reply packet, is less credible than authoritative zone data and therefore cannot replace it.

Firewall configuration
Most organizations connected to the Internet now employ a firewall of some kind. One variety of firewall, called an adaptive packet filtering firewall, can help protect your Internet name servers. CheckPoint's FireWall-1 and Cisco's PIX are examples of adaptive packet filtering firewalls.

The key mechanism incorporated by these firewall products that allows them to help secure name servers is state-based filtering of UDP packets. Normally, firewalls can only permit or deny UDP packets based on where they're coming from and where they're going to. Adaptive packet filtering firewalls can also decide based on whether they've forwarded an authorized UDP packet and are expecting a reply to it.

For example, FireWall-1 can note that it forwarded an authorized UDP packet from one of your name servers to a name server on the Internet. While FireWall-1 normally wouldn't permit an unsolicited UDP packet from that Internet name server to your name server, it will allow just the single reply packet.

This is useful in protecting name servers from flooding attacks. One form of flooding attack attempts to make your name server cache data by sending it replies that include spoofed records. Because your name server will only accept replies that contain a query ID that matches the query ID it sent in the query message, the attacker must send a lot of potential responses in an attempt to guess the correct query ID. If your firewall rejects all but one reply, this sort of attack will rarely succeed.

You can also use state-based UDP filtering to restrict the IP addresses from which older BIND name servers will receive queries. BIND 4 name servers have no mechanism for restricting which queries they respond to. Using a router to permit UDP packets only between authorized resolvers and the name server won't work because the name server also uses UDP to communicate with other name servers on the Internet. However, you can use state-based UDP filtering to restrict UDP packets from the Internet to replies to authorized queries.

An end to DNS spoofing?
The real solution to this DNS spoofing madness lies in DNSSEC, the DNS Security Extensions defined in RFC 2065 (see Resources below). The security extensions introduce two new resource record types, KEY and SIG, that allow resolvers and name servers to cryptographically authenticate the source and guarantee the integrity of DNS queries and responses with digital signatures.

RSA Data Security, Inc., has recently granted the Internet Software Consortium a free license to use DNSsafe, an implementation of the RSA public key cryptosystem, in BIND. This, as well as the eminent John Gilmore's volunteering his time, should clear the way for the rapid implementation of DNSSEC in BIND 8.

The final word
You need to protect your exposed name servers from attack. Run the latest version of BIND (4.9.6 or 8.1.1), even if you have to compile it yourself and lobby your vendor to port it. Tighten up your name servers' configuration: They should only respond to queries from and allow zone transfers to authorized hosts. If you have the hardware for it, make two kinds of name servers: one answering name server queries; the other answering resolver queries. Finally, take advantage of any protection your firewall can offer, such as state-based filtering of DNS UDP packets.

Resources

• The DNS Resources Directory http://www.dns.net/dnsrd/
• BIND configuration guide http://www.isc.org/bind8/config.html
• The Internet Software Consortium's BIND page http://www.isc.org/bind.html
• Acme Byte & Wire's "Ask Mr. DNS" column http://www.acmebw.com/askmr.htm
• DNS Security Extensions (RFC 2065) http://ds.internic.net/rfc/rfc2065.txt
• BIND FAQ ftp://ftp.njit.edu/pub/dns/cptd.faq

About the author
Matt Larson and Cricket Liu are the founders of Acme Byte & Wire, a consulting and training company that specializes, coincidentally, in the Domain Name System and Internet security. Cricket is the co-author of the O'Reilly & Associates Nutshell Handbook DNS and BIND." Matt and Cricket, together with Paul Albitz, are at work on the upcoming DNS on NT (don't hiss). You can reach Matt at matt.larson@sunworld.com and Cricket at cricket.liu@sunworld.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-11-1997/swol-11-bind.html
Last modified: