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).
End of Article
