UNIX System Administration Handbook - Evi Nemeth [277]
Secure server-to-server communication with TSIG and TKEY
While DNSSEC (covered in the next section) was being specified, the IETF developed a simpler mechanism called TSIG (RFC2845) to allow secure communication among servers through the use of transaction signatures. Access control based on transaction signatures is more secure than access control based on IP source addresses.
Transaction signatures use a symmetric encryption scheme. That is, the encryption key is the same as the decryption key. This single key is called a shared-secret key. You must use a different key for each pair of servers that want to communicate securely. TSIG is much less expensive computationally than public key cryptography, but it is only appropriate for a local network on which the number of pairs of communicating servers is small. It does not scale to the global Internet.
TSIG signatures sign DNS queries and responses to queries. They are used only between servers, not between servers and resolvers. TSIG signatures are checked at the time a packet is received and are then discarded; they are not cached and do not become part of the DNS data. Although the TSIG specification allows multiple encryption methods, BIND implements only one, the HMAC-MD5 algorithm.
BIND’s dnssec-keygen12
utility generates a key for a pair of servers. For example, to generate a shared-secret key for two servers, serv1 and serv2, use
# dnssec-keygen -H 128 -h -n serv1-serv2
to create a 128-bit key and store it in the file Kserv1-serv2+157+00000.private. The file contains the string “Key:” followed by a base-64 encoding of the actual key.
The generated key is really just a long random number. You could generate the key manually by writing down an ASCII string of the right length and pretending that it’s a base-64 encoding of something or by using mmencode to encode a random string. The way you create the key is not important; it just has to exist on both machines.
Copy the key to both serv1 and serv2 with scp, or cut and paste it. Do not use telnet or ftp to copy the key; even internal networks may not be secure. The key must be included in both machines’ named.conf files. Since named.conf is usually world-readable and keys should not be, put the key in a separate file that is included into named.conf. For example, you could put the snippet
key serv1-serv2 {
algorithm hmac-md5 ;
secret "shared-key-you-generated" ;
} ;
scp is part of the SSH suite. See page 672 for details.
in the file serv1-serv2.key. The file should have mode 600 and its owner should be named’s UID. In the named.conf file, you’d add the line
include "serv1-serv2.key"
near the top.
This part of the configuration simply defines the keys. To make them actually be used to sign and verify updates, each server needs to identify the other with a keys clause. For example, you might add the lines
server serv2's-IP-address {
keys { serv1-serv2 ; } ;
} ;
to serv1’s named.conf file and
server serv1's-IP-address {
keys { serv1-serv2 ; } ;
} ;
to serv2’s named.conf file. Any allow-query, allow-transfer, and allow-update clauses in the zone statement for the zone should also refer to the key. For example:
allow-transfer { key serv1-serv2 ;} ;
When you first start using transaction signatures, run named at debug level 1 (see page 473 for information about running named in debug mode) for a while to see any error messages that are generated. Older versions of BIND do not understand signed messages and complain about them, sometimes to the point of refusing to load the zone.
TKEY is a BIND 9 mechanism that allows two hosts to generate a shared secret key automatically without phone calls or secure copies to distribute the key. It uses an algorithm called the Diffie-Hellman key exchange in which each side makes up a random number, does some math on it, and sends the result to the other side. Each side then mathematically combines its own number with the transmission it received to arrive at the same key. An eavesdropper