Maximizing BIND DNS Security

Use DNSSEC and TSIG to secure DNS transactions

No company can afford to ignore the security of its DNS service, the crucial service that provides host-name and IP address resolution on the Internet. Although Windows 2000 provides a built-in DNS service, BIND is the most widely used DNS software on the Internet, and many Win2K administrators use BIND to maintain their Internet DNS servers. In "Secure Your BIND DNS Service," December 2001, InstantDoc ID 22930, I discuss the vulnerabilities in older BIND versions and describe how to use newer BIND 8 (i.e., BIND 8.2.3 and later) and BIND 9 (i.e., BIND 9.1.0 and later) access-control settings to implement a basic layer of protection. However, those settings don't address two important security concerns: data authentication and data integrity. To be truly secure, a DNS client or server must communicate only with a trusted DNS server and must authenticate received data. Authentication involves confirming that no one has intercepted a query reply and changed its content during its transmission over the Internet.

To help companies guarantee data authentication and integrity, the Internet Engineering Task Force (IETF) launched development of the DNS Security (DNSSEC) Internet standard, which uses public key and digital signature technologies that developers can apply in their DNS software implementations. The IETF also developed the Transaction Signature (TSIG) DNS transaction-authentication protocol, which uses shared secret key technology to help secure DNS transactions. (IETF Request for Comments—RFC—2535 and RFC 3008 discuss DNSSEC; RFC 2845 deals with TSIG. For more information about DNSSEC, you can also visit NLnet Labs' DNSSEC resources Web site at http://www.nlnetlabs.nl/dnssec.)

The Internet Software Consortium (ISC), which develops and maintains BIND source codes, has incorporated DNSSEC and TSIG in BIND 8.2.3 and later and in BIND 9.1.0 and later. The newer BIND 9 versions have better support for DNSSEC and TSIG than do the BIND 8 versions. Both generations can generate public and private keys, but BIND 9.1.0 has extended zone-signing capabilities. Therefore, this article focuses on implementing DNSSEC and TSIG in BIND 9.1.3. (The ISC hasn't imported BIND 9.1.3 into Win2K or Windows NT yet, but you can run BIND 9.1.0 on most UNIX and Linux platforms. Also, BIND Release Candidate—RC—9.2.0 supports Win2K and NT.) This article assumes you have a basic knowledge of BIND, digital signature technology, and shared secret key technology. (For more information about these topics, see "Secure Your BIND DNS Service"; "Digital Signature Technology," February 1999, InstantDoc ID 4772; and Gary C. Kessler, "How DNS Works," June 2000, InstantDoc ID 8666.)

DNSSEC Basics
Implementing DNSSEC on your BIND DNS server involves signing the server's DNS domain zone file. (I explain that process later.) DNSSEC then uses digital signature technology to sign each record in the zone. When a DNS client queries a specific DNS record, the DNS server replies with the signed version of the requested record. The DNS client then uses digital signature technology to confirm the data integrity of the received record and to authenticate the DNS server. To support digital signature technology, DNSSEC introduces two new DNS resource records (RRs): SIG and KEY. The security protocol also introduces the NXT RR to help authenticate nonexistent DNS records.

The SIG RR. A SIG RR contains the digital signature for each original RR (e.g., Start of Authority—SOA—NS, A, PTR, MX, CNAME). In a signed zone, DNSSEC associates each original RR with a SIG RR to form a record set. Listing 1 shows the zone file for an unsigned, unsecured zone, us.example.com. Figure 1 shows the zone file for the corresponding secure, signed zone. As Figure 1 shows, a SIG RR follows each original RR in the signed zone. A SIG RR's syntax is

corresponding_RR_type signing_algorithm number_of_owner_labels original_TTL signature_expiration signature_inception key_tag signer signature

For example, callout D in Figure 1 shows the SIG RR for www.us.example.com's A record. This output shows that the SIG RR corresponds to an A RR and that DNSSEC used Digital Signature Algorithm (DSA) to sign the original RR. (RFC 2535 discusses the possible signing algorithms: 1 is RSA/Message Digest 5—MD5— 2 is Diffie-Hellman, and 3 is DSA.) The A RR's owner (i.e., www.us.example.com) has four labels (i.e., www, us, example, and com). The original Time to Live (TTL) value of the A RR is 86400 seconds (i.e., 1 day), the signature expires at 6:10:13 Greenwich Mean Time (GMT) on April 3, 2001 (i.e., 20010403061013), and the signature became valid at 6:10:13 GMT on March 4, 2001 (i.e., 20010304061013). The key tag (i.e., a number that identifies the zone's public and private key pair) is 51297. The signer is us.example.com, and the final strange string is the signature.

The KEY RR. You use a zone's private key (from its public and private key pair) to sign the zone during DNSSEC implementation. You keep the private key secret, and the KEY RR stores the public key, which a DNS client uses to verify the signatures of received DNS records. DNSSEC provides a corresponding SIG RR for each KEY RR, but the parent zone signs the KEY RR. For example, the parent zone example.com would sign a KEY RR in the signed zone us.example.com. The KEY RR's syntax is

flags protocol algorithm public_key

Flags indicate the type of the included key and how to use it. For example, callout A in Figure 1 shows us.example.com's KEY RR. This output shows that the key is a zone key and is used only for authentication. The protocol is DNSSEC (represented by the number 3), the signing algorithm is DSA (represented by the number 3), and the final string is the zone's public key. (RFC 2535 discusses the meanings of the KEY RR's options.) The KEY RR's corresponding SIG RR, which callout B in Figure 1 shows, defines the signer of the KEY RR (i.e., us.example.com's parent zone, example.com).

The NXT RR. The SIG and KEY RRs are strong enough to authenticate existing DNS records, but DNSSEC wouldn't be truly secure without a mechanism to authenticate nonexistent records. For example, consider the unsecured www.us.example.com zone file that Listing 1 shows. If a client queries a nonexistent record, product.us.example.com, the DNS server running the unsecured zone will return the SOA RR and an NXDOMAIN error, which indicates that the queried record doesn't exist.

If DNSSEC used the same method to reply to such a query—even if DNSSEC provided a corresponding SIG RR for the signed SOA RR—an intruder could easily wreak havoc. The intruder could query the zone or listen to the wire to determine us.example.com's SOA and corresponding SIG RRs. Then, when a client queried the DNS server for the existing record www.us.example.com, the intruder could send that client the SOA and SIG RRs and the NXDOMAIN error before the DNS server could respond. The client would verify the SOA RR's signature and determine that www.us.example.com didn't exist.

To prevent such problems, DNSSEC introduced the NXT RR, which indicates the record-owner names that don't exist within a specified name interval. (For example, if a client knows that within the name interval 1 through 4, the current record is 1 and the next record is 4, the client can infer that the records 2 and 3 are nonexistent.)

DNSSEC arranges a signed zone's record sets in canonical order (i.e., zone name, wildcard—*—record—if any, then the other records in alphabetical order) and inserts a NXT RR for each record. A NXT RR's syntax is

next_record_owner record_types_in_current_set

For example, ns1.us.example.com's NXT RR, which callout C in Figure 1 shows, states that the next record's owner name is www.us.example.com and that the current record (i.e., ns1.us.example.com) contains the RR types A, SIG, and NXT. From this NXT RR, the client can determine that no other records exist between ns1.us.example.com and www.us.example.com. A zone's final NXT RR always points back to the zone's first record (i.e., the zone name). DNSSEC signs each NXT RR with an associated SIG RR, and the NXT record's syntax prevents intruders from using the NXT RR to make a client believe an existing record doesn't exist.

Using DNSSEC in BIND
To use DNSSEC in BIND 9.1.3, you must set up a secure zone on a BIND 9.1.3 server. This process involves four steps: generating keys, creating a keyset, signing the child zone's keyset, and signing the zone.

Generating keys. A secure zone must have one or more public and private key pairs, called zone keys. You use the zone's private key to sign the zone. DNS clients use the corresponding public key to verify signatures. When the parent zone (e.g., example.com) delegates a secure child zone (e.g., us.example.com), you can use the parent zone's private key or keys to sign the child zone's key or keys. If the parent zone has multiple key pairs, you can use different keys to sign the parent and child zones' key or keys.

You use the dnssec-keygen command to generate keys on a BIND 9.1.3 server. (Enter the command without any parameters to see command-usage information.) For example, to generate a key pair for the child zone us.example.com in Listing 1, enter the following command on the BIND server:

dnssec-keygen -a DSA -b 1024 -n ZONE us.example.com.

The -a option defines which digital signature algorithm the generated keys will use. According to RFC 2535, DSA is the mandatory algorithm for DNSSEC interoperability, but BIND 9.1.3 also supports Diffie-Hellman, Hash Message Authentication Code (HMAC)—MD5, RSA, and RSA/MD5. The -b option specifies the key length (1024 bits in this example). The -n option defines the keys' name type, which can be zone, host, entity, or user. The final parameter in the sample command is the key name, which must be the same as the zone name if the specified name type is zone.

The dnssec-keygen command also lets you choose the protocol that the generated keys will support; DNSSEC is the default. The command automatically saves the generated keys in two output files in the current directory; the parameters you use in the command determine the filenames. The sample command would store the public key in the file Kus.example.com.+003+51297.key and store the private key in the file Kus.example.com.+003+51297.private. The first number set represents the digital algorithm (in this example, DSA, which DNSSEC represents by the number 3). The second number set (51297 in this example) is the key tag, which distinguishes the keys from other key pairs and appears in the signed zone's SIG records. You need to protect the private key file and keep it secret, but you need to include the public key filename in the child zone's unsecured zone file, as callout A in Listing 1 shows.

Creating a keyset. Before the parent zone can sign a child zone's public key, you need to create a keyset containing the child zone's public key that the parent zone can recognize and sign. You use the dnssec-makekeyset command to create this keyset. For example, the command

dnssec-makekeyset -t 7200 -e 20011231235959 Kus.example.com.+003+51297

creates a keyset for the child zone us.example.com. The -t option defines the SIG and KEY records' TTL value. The sample command specifies the TTL as 7200 seconds; 3600 seconds is the default. The -e option defines the end time of the parent zone's signature. The sample command specifies that the signature expires at 23:59:59 on December 31, 2001 (i.e., 20011231235959); the default signature end time is 30 days after the start time. (The sample command accepts the default signature start time, which is now, but you can use the -s option to specify a start time.) The command saves the keyset output file as keyset-zone. in the current directory. (The ending period is part of the filename.) For example, the output file keyset-us.example.com. would result from the sample command.

Signing the child zone's keyset. Next, you need to submit the child zone's keyset to the parent zone so that the parent zone can sign the keyset. The parent zone uses the dnssec-signkeyset command to sign a child zone's keyset. For example, to instruct the parent zone example.com to sign the child zone us.example.com's keyset, use the command

dnssec-signkeyset keyset-us.example.com. Kexample.com.+003+47063

By default, the command uses the signature start and end times you specified when you created the child zone's keyset, but you can use the -s and -e options to overwrite those times. The final parameter is the parent zone's key tag. The command saves the signed keyset output file as signedkey-zone. in the current directory. (The ending period is part of the filename.) For example, the output file signedkey-us.example.com. would result from the sample command. The parent zone then needs to securely ship this output file to the child zone; store the output file in the same directory as you store the child zone's keys.

Signing the zone. Now, you can sign the child zone. To do so, you use the dnssec-signzone command. For example, to sign the unsigned child zone us.example.com that Listing 1 shows, use the command

dnssec-signzone -o us.example.com /usr/local/etc/db.us.example

The -o option specifies the zone name (i.e., us.example.com). The second parameter is the full path of the zone file (i.e., /usr/local/etc/db.us.example). This sample command creates an output file named /usr/local/etc/db.us.example.signed. To instruct the BIND 9.1.3 DNS server to load the secure zone file, you need to include the signed zone filename in us.example.com's named.conf file. (For information about configuring named.conf, see "Secure Your BIND DNS Service.") If you update a zone file after you've signed the zone, you need to resign the zone.

DNSSEC provides reliable security for DNS transfers. The sidebar "A Secure Transaction" presents examples of such transactions for the DNSSEC-secured zone that Figure 1 shows.

Using TSIG in BIND
BIND's DNSSEC implementation is powerful, but to be effective, it requires DNSSEC-enabled clients and a public key infrastructure (PKI) on the Internet. But Windows client computers don't support DNSSEC, and the Internet doesn't have a PKI infrastructure in place. Until the Internet can more fully support DNSSEC, you can use TSIG to authenticate DNS transactions between two hosts.

In TSIG, two hosts (i.e., two DNS servers or a DNS server and a DNS client) share a secret key and use an MD algorithm to authenticate a DNS message transaction. TSIG doesn't use presigned zone files, as DNSSEC uses. When a TSIG-enabled host sends a message packet, the host generates a signature for the packet. The signature is good only for that transaction. TSIG's shared secret key technology means that multiple hosts share the same secret key. This type of key is easier to compromise than the public and private keys that DNSSEC uses, so TSIG isn't as secure as DNSSEC.

You can use TSIG to authenticate such DNS message transactions as query requests and responses, dynamic updates, and zone transfers. For example, you can use TSIG between your DNS servers and your ISP's or business partners' DNS servers to secure those communications. If your BIND server runs a dynamic DNS (DDNS) zone, you can use TSIG to authenticate dynamic updates from clients, DHCP servers, and other servers that support TSIG. This type of authentication for dynamic updates is more secure than IP address authentication. You can also use TSIG to authenticate zone transfers from the primary DNS server to secondary DNS servers. BIND 8.2.4 and 9.1.3 primarily support TSIG for server-to-server communication. These BIND versions' dynamic update tool, Nsupdate, also supports TSIG through use of a secret key option.

Suppose you want to use TSIG between two hosts, host1 and host2. You first need to generate a secret key for the hosts. To do so, you can use the dnssec-keygen command

dnssec-keygen -a HMAC-MD5 -b 128 -n HOST host1-host2.

As I explained earlier, this command's -a option defines the digital signature algorithm that the generated key will use. RFC 2845 specifies HMAC-MD5 as the mandatory algorithm for TSIG interoperability, and BIND supports only HMAC-MD5 for TSIG. You can use a key length as long as 512 bits for HMAC-MD5. (The example uses a key length of 128 bits.) The key name in this example is host1-host2. (the ending period is part of this name). The output private key file contains the generated secret key. For example, the sample command creates the private key file Khost1-host2.+157+59290.private. The Key: line in that file contains the secret key. You need to securely deliver this key to both hosts.

If host1 and host2 are both BIND servers, you need to add the key statement that Listing 2 shows to both servers' named.conf files. To protect the key statement, you must restrict read access to named.conf so that only the root account can read the file.

A better option is to maintain a separate file that contains only key statements, protect that file, then include that filename in named.conf. That way, you don't need to restrict named.conf.

To permit host1 (IP address 192.168.1.10) to use the key and TSIG when sending a message to host2 (IP address 192.168.2.10), add the server statement that Listing 3 shows to host1's named.conf file. Add the server statement that Listing 4 shows to host2's named.conf file.

If host2 dynamically updates a dynamic zone on host1, you can use the TSIG key to authenticate host2 and its request. To do so, use an allow-update statement, which Listing 5 shows, in host1's named.conf file.

Looking Forward
DNS is a fundamental Internet service. Any Web services that require host-name resolution depend on DNS. Without a secure DNS service, these Web services aren't secure. Although DNSSEC isn't yet widely deployed on Internet clients, BIND's rich set of security tools, including DNSSEC and TSIG, can help you secure your DNS service. Currently, Fault-Tolerant Mesh of Trust Applied to DNSSEC (FMESHD), a Defense Advanced Research Projects Agency (DARPA) project with the objective of deploying DNSSEC on the Internet, is building a DNSSEC testbed for organizations to use. (For more information about this testbed, visit http://fmeshd.nge.isi.edu.) You can also use DNSSEC within your intranet without needing to establish a trust relationship with other companies.

TSIG can help you secure transactions with hosts that don't yet support DNSSEC, and several other IETF protocols can enhance TSIG's capabilities. The Secret Key Establishment for DNS (TKEY) RR, which IETF RFC 2930 describes, automates TSIG secret key generation and exchange. The DNS Request and Transaction Signatures, or SIG(0), which IETF RFC 2931 describes, uses public keys to authenticate DNS requests and transactions. BIND 9.1.0 through 9.1.3 have some limited TKEY and SIG(0) functions but provide no documentation for these functions. I expect TKEY and SIG(0) to be fully implemented in a future BIND version.

At the time of this writing, Win2K's DNS service doesn't support DNSSEC but offers limited support for TSIG. Win2K DNS supports secure dynamic updates in an Active Directory (AD)—integrated dynamic DDNS zone. Microsoft bases Win2K DNS's implementation of secure dynamic updates on the company's proposed IETF draft "GSS Algorithm for TSIG (GSS-TSIG)"; at the time of this writing, you can view the most recent draft at http://search.ietf.org/internet-drafts/draft-ietf-dnsext-gss-tsig-03.txt. To extend TSIG, GSS for TSIG applies the Generic Security Service API (GSS-API—see IETF RFC 2078 for information about this API).