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.
