| Downloads |
|---|
| 22930.zip |
You know the fundamentals of DNS security. You've properly distributed your DNS servers in different networks and in geographically diverse locations. You use BIND, the most widely used DNS software on the Internet, and use a version that doesn't have the recently discovered security vulnerabilities. (For information about these security holes, see the sidebar "Keep an Eye on BIND Bugs," page 42.) But using a distributed DNS service and a new BIND version doesn't mean that your DNS service is secure enough to resist attacks. To better protect your DNS service, you can use BIND's basic security functions: access-control settings that you can apply to a BIND DNS server's configuration file. These settings let you restrict recursion, enable forwarding, set up split DNS on one server, permit or reject queries, prevent communications with specific servers, restrict zone transfers and updates, and disguise which version of BIND you use. Before applying these settings, though, you need to be aware of the various versions of BIND.
BIND Versions
BIND has long been a popular method for Internet host name and IP address resolution. The Internet Software Consortium (ISC) develops and maintains BIND source codes, which you can download for free at ftp://ftp.isc.org. The three generations of BIND are BIND 4, BIND 8, and BIND 9; at the time of this writing, the most recent versions are BIND 4.9.8, BIND 8.2.4, and BIND 9.1.3, respectively. However, the ISC has announced that it will no longer actively maintain BIND 4, so if you use that version you might consider switching to BIND 8 or BIND 9.
BIND 8.2.3 and later offer many important features, such as dynamic DNS (DDNS), DNS Security (DNSSEC), Transaction Signature (TSIG), and incremental zone transfer (IXFR). BIND 8.2.3 and later also fix bugs—including the security holes that the CERT Coordination Center (CERT/CC) publicized—from earlier BIND versions. BIND 9.1.3 includes BIND 8.2.3 features plus support for IPv6, multiprocessors, and back-end third-party databases; better DNSSEC capabilities; new portability architecture; and a new View feature that lets you split DNS service on one DNS server. The newer BIND versions also provide better support for Windows 2000. (BIND runs mostly on UNIX and Linux platforms, but developers have ported BIND 8.2.3 and later to Win2K or Windows NT, so you can easily use BIND 8 on Win2K and NT systems, as the sidebar "BIND on Win2K or NT," explains. For information about BIND's support for Win2K, see "Integrating UNIX DNS and Windows 2000," February 2000.)
To tell a BIND DNS server how to behave, BIND uses a text-based configuration file, which is called named.conf in BIND 8 and BIND 9. (BIND 4's configuration file is called named.boot, but because BIND 4 is no longer supported, the examples in this article refer to named.conf.) BIND provides several basic but useful access-control settings that you can add to the file's various sections (e.g., options, zone) to secure your DNS service. Listing 1 shows a sample named.conf file.
Restrict or Prevent Recursion
By default, a BIND DNS server acts as a recursive resolver. (For the basics of how DNS works, see Michael D. Reilly, Getting Started with NT, "Domain Name Resolution with DNS," June 1999.) However, this functionality can lead to several problems. When a DNS client or another DNS server asks a BIND DNS server for a name lookup (e.g., the IP address of www.exampleco.com) and the BIND DNS server doesn't have that information in its local cache, the BIND DNS server tries to retrieve the information from other DNS servers. If the BIND DNS server receives bogus or poisoned information, it then spreads that bad information to the requesting client or server. Also, when your BIND DNS server is your Internet domain's authoritative server and provides domain information in response to external Internet queries, external Internet users can query other domains through your DNS server.
To minimize those problems, you can add a statement to the options section of the BIND DNS server's named.conf file to specify which clients can request a recursive query. For example, you can use the statement that Listing 2 shows to permit intranet hosts 192.168.10.0/24 and 192.168.11.0/24 to resolve Internet names through your Internet BIND DNS server.
Another option is to turn off the recursive functions of your BIND DNS server. To do so, you can add the statement that Listing 3 shows to the options section of the BIND DNS server's named.conf file. The code at callout A in Listing 3 prevents the server from using other DNS servers to resolve names. The code at callout B in Listing 3 stops the server from resolving other DNS servers' names in the Name Server (NS) records that it relays in response to external queries. When you disable your Internet BIND DNS server's recursive functionality, however, your internal DNS servers and users can no longer resolve Internet domain names through that server.
Split DNS
For security reasons, most companies don't want to reveal their internal network infrastructure. You especially want to hide internal host names and the corresponding IP addresses that your DNS servers provide. But you still need to provide DNS service to the Internet to resolve external host names and IP addresses (e.g., the addresses of your Internet Web servers and email servers). The solution is to split your DNS service into an internal and external service, a setup known as split DNS.
When you establish a split DNS service, the internal DNS service lets internal users resolve intranet and Internet host names and addresses. The external DNS service answers external Internet queries for your company's external host names and addresses. You can implement split DNS in one of two ways, depending on the BIND version you use.
Split DNS in BIND 8. The first method, which Figure 1 shows, is to place one or more internal DNS servers behind a firewall in your intranet, and place one or more external DNS servers in your demilitarized zone (DMZ) or on the Internet. Only internal DNS clients can access the internal DNS server, which holds internal domain host and address information. When an external DNS client queries a host name in the company's Internet domain, the external DNS server answers the query. No DNS queries from the Internet go into the intranet. When the internal DNS server receives a query for an Internet host name (e.g., www.win2000mag.com) that isn't in its cache, it forwards a recursive query to the external DNS server. Rather than disable recursion on the external DNS server, you use the method that Listing 2 shows to restrict recursion on that server to permit recursion only for queries coming from the intranet. The external server locates win2000mag.com's DNS server from the Internet root server, then resolves the name www.win2000mag.com from win2000mag.com's DNS server.
To enable forwarding on the internal DNS server, apply the statement that Listing 4 shows to named.conf's options section. The code at callout A in Listing 4 makes sure that the internal DNS server always forwards queries of domains that it doesn't serve to one of the external DNS servers that callout B specifies.
Consider placing your external BIND DNS server in your DMZ, behind an external firewall, as Figure 1 shows. A good firewall can detect and deny an attack such as Denial of Service (DoS). To use this setup, you need to open UDP port 53 on the external firewall to permit Internet queries to reach the external DNS server.
Split DNS in BIND 9. The second method of implementing split DNS uses BIND 9's new View feature. With this feature, you can use the same DNS hardware to provide internal and external services. For example, suppose your company, Exampleco, has an internal domain exampleco.com and an external domain exampleco.com. The internal domain has a zone file that contains internal host and address information, and the external domain has a separate zone file that contains external host name and address information. A traditional DNS server can load only one copy of a zone file for exampleco.com. BIND 9, however, lets you use one DNS server to load several zone files for the same domain name and to answer client queries from the proper zone file, according to the client address (i.e., internal or external).
To run internal and external zone files for exampleco.com on a BIND 9 server, you can apply the statements that Listing 5, page 45, shows to named.conf's view section. (A BIND DNS server resolves client requests according to the order of existing view statements. Therefore, when you add a new view statement, pay attention to its placement in relation to any existing view statements.) The first statement is for the internal domain; the second statement is for the external domain. The internal domain uses the zone file internal.exampleco; the external domain uses the zone file external.exampleco. When the DNS server receives a query, it first determines whether the DNS client address falls into the address range in the substatement that callout A in Listing 5 shows. If so, the DNS server knows the client is an internal client and therefore returns an answer from the internal domain. If not, the DNS server determines whether the client address falls into the address range in the substatement that callout B shows. In this example, the substatement in callout B specifies any, so the server returns an answer from the external domain to any client that doesn't match the internal client list.
To use the View feature, you must run BIND 9 on a machine that both intranet and Internet clients can access. That machine can be the firewall between the Internet and intranet or a server in the DMZ. (Note that a good DMZ has an internal firewall and an external firewall. The internal firewall opens outbound UDP 53 for intranet queries to the DNS server; the external firewall opens inbound UDP 53 for Internet queries to the DNS server.)
Restrict Access
You can use several other BIND statements to enhance the security of your DNS servers. To further protect an internal BIND DNS server, you can tell the server to accept queries only from specific addresses. In the example that Listing 6 shows, the server will accept queries only from clients on the networks 192.168.10.0/24 and 192.168.11.0/24.
This restriction, however, is difficult to use effectively on an external BIND DNS server because you typically don't know the clients that will request access to the server. But you can use similar statements in the named.conf file's options section to deny access to known bad users (provided that you know those users' IP addresses) or known bad servers. For example, if you know that a particular intruder often uses a source address in the range of 172.36.0.0/16 to attack your DNS server, you can include a blackhole statement, which Listing 7 shows, to deny the intruder's queries. When you know the address of a DNS server (e.g., 172.36.2.2) that you don't want your DNS server to communicate with, you can use the server statement that Listing 8 shows to prevent communication.
To permit only certain DNS servers (e.g., the secondary DNS servers 192.168 .10.10 and 198.168.11.10) to perform a zone transfer from a specific DNS server (e.g., the primary DNS server), you can add the statement that Listing 9 shows to the options section of the primary server's named.conf file. If you run a dynamic zone on your BIND DNS server, you can add a statement to named.conf's zone definition to restrict which clients (e.g., DHCP servers and Win2K computers) can dynamically update the zone. For example, the zone statement that Listing 10 shows permits systems on 192.168.10.0/24 to update the dynamic zone for exampleco.com.
Hide Your BIND
A server running a BIND version with known security vulnerabilities is a good target for an intruder. If you're too busy to upgrade your BIND server to BIND 8.2.3 or later or to BIND 9.x, you can add a statement to named.conf's options section to hide your BIND version or make it look like a new version. For example, the statement in Listing 11 can disguise an older version of BIND and make it appear to be BIND 8.2.4 to an intruder using the Dig command
dig @<yourdnsserver> chaos version.bind txt
(For information about the Dig utility in Win2K and NT, see the sidebar "Dig for DNS Information," page 44.)
Beyond the Basics
To raise the bar of Internet DNS service security, the ISC has incorporated the Internet Engineering Task Force (IETF) Internet DNS security protocol into BIND. In my next article, I'll discuss BIND's new DNSSEC and TSIG security functions and how they can help you further prevent DNS service security problems.
