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).
Previous
