11.1 TSIG

BIND 8.2 introduced a new mechanism for securing DNS messages called transaction signatures, or TSIG for short. TSIG uses shared secrets and a one-way hash function to authenticate DNS messages, particularly responses and updates.

TSIG, now codified in RFC 2845, is relatively simple to configure, lightweight for resolvers and name servers to use, and flexible enough to secure DNS messages (including zone transfers) and dynamic updates. (Contrast this with the DNS Security Extensions, which we'll discuss at the end of this chapter.)

With TSIG configured, a name server or updater adds a TSIG record to the additional data section of a DNS message. The TSIG record "signs" the DNS message, proving that the message's sender had a cryptographic key shared with the receiver and that the message wasn't modified after it left the sender.^[1]

^[1] Cryptography wonks may argue that TSIG "signatures" aren't really signatures in a cryptographic sense because they don't provide nonrepudiation. Since either holder of the shared key can create a signed message, the recipient of a signed message can't claim that only the sender could have sent it (the recipient could have forged it himself).

11.1.1 One-Way Hash Functions

TSIG provides authentication and data integrity through the use of a special type of mathematical formula called a one-way hash function. A one-way hash function, also known as a cryptographic checksum or message digest, computes a fixed-size hash value based on arbitrarily large input. The magic of a one-way hash function is that each bit of the hash value depends on each and every bit of the input. Change a single bit of the input and the hash value changes dramatically and unpredictably—so unpredictably that it's "computationally infeasible" to reverse the function and find an input that produces a given hash value.

TSIG uses a one-way hash function called MD5. In particular, it uses a variant of MD5 called HMAC-MD5. HMAC-MD5 works in a keyed mode in which the 128-bit hash value depends not only on the input, but also on a key.

11.1.2 The TSIG Record

We won't cover the TSIG record's syntax in detail because you don't need to know it: TSIG is a "meta-record" that never appears in zone data and is never cached by a resolver or name server. A signer adds the TSIG record to a DNS message, and the recipient removes and verifies the record before doing anything further, such as caching the data in the message.

You should know, however, that the TSIG record includes a hash value computed over the entire DNS message as well as some additional fields. (When we say "computed over," we mean that the raw, binary DNS message and the additional fields are fed through the HMAC-MD5 algorithm to produce the hash value.) The hash value is keyed with a secret shared between the signer and the verifier. Verifying the hash value proves both that the DNS message was signed by a holder of the shared secret and that it wasn't modified after it was signed.

The additional fields in the TSIG record include the time the DNS message was signed. This helps combat replay attacks, in which a hacker captures a signed, authorized transaction (say a dynamic update deleting an important resource record) and replays it later. The recipient of a signed DNS message checks the time signed to make sure it's within the allowable "fudge" (another field in the TSIG record).

11.1.3 Configuring TSIG

Before using TSIG for authentication, we need to configure one or more TSIG keys on either end of the transaction. For example, if we want to use TSIG to secure zone transfers between the master and slave name servers for movie.edu, we need to configure both name servers with a common key:

key terminator-wormhole.movie.edu. {
	algorithm hmac-md5;
	secret "skrKc4Twy/cIgIykQu7JZA==";
};

The argument to the key statement in this example, terminator-wormhole.movie.edu, is actually the name of the key, though it looks like a domain name. (It's encoded in the DNS message in the same format as a domain name.) The TSIG RFC suggests you name the key after the two hosts that use it. The RFC also suggests that you use different keys for each pair of hosts.

It's important that the name of the key—not just the binary data the key points to—be identical on both ends of the transaction. If it's not, the recipient tries to verify the TSIG record and finds it doesn't know the key that the TSIG record says was used to compute the hash value. That causes errors like the following:

Nov 21 19:43:00 wormhole named-xfer[30326]: SOA TSIG verification from server 
[192.249.249.1], zone movie.edu: message had BADKEY set (17)

The algorithm, for now, is always hmac-md5. The secret is the base 64 encoding of the binary key. You can create a base 64-encoded key using the dnssec-keygen program included in BIND 9 or the dnskeygen program included in BIND 8. Here's how you'd create a key using dnssec-keygen, the easier of the two to use:

# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST terminator-wormhole.movie.edu.
Kterminator-wormhole.movie.edu.+157+28446

The -a option takes as an argument the name of the algorithm the key will be used with. (That's necessary because dnssec-keygen can generate other kinds of keys, as we'll see in the DNSSEC section.) -b takes the length of the key as its argument; the RFC recommends using keys 128 bits long. -n takes as an argument HOST, the type of key to generate. (DNSSEC uses ZONE keys.) The final argument is the name of the key.

dnssec-keygen and dnskeygen both create files in their working directories that contain the keys generated. dnssec-keygen prints the base name of the files to its standard output. In this case, dnssec-keygen created the files Kterminator-wormhole.movie.edu.+157+28446.key and Kterminator-wormhole.movie.edu.+157+28446.private. You can extract the key from either file. The funny numbers (157 and 28446), in case you're wondering, are the key's DNSSEC algorithm number (157 is HMAC-MD5) and the key's fingerprint (28446), a hash value computed over the key to identify it. The fingerprint isn't particularly useful in TSIG, but DNSSEC supports multiple keys per zone, so identifying which key you mean by its fingerprint is important.

Kterminator-wormhole.movie.edu.+157+28446.key contains:

terminator-wormhole.movie.edu. IN KEY 512 3 157 skrKc4Twy/cIgIykQu7JZA==

and Kterminator-wormhole.movie.edu.+157+28446.private contains:

Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: skrKc4Twy/cIgIykQu7JZA==

You can also choose your own key and encode it in base 64 using mmencode :

% mmencode  
foobarbaz
Zm9vYmFyYmF6

Since the actual binary key is, as the substatement implies, a secret, we should take care in transferring it to our name servers (e.g., by using ssh) and make sure that not just anyone can read it. We can do that by making sure our named.conf file isn't world-readable or by using the include statement to read the key statement from another file, which isn't world-readable:

include "/etc/dns.keys.conf";

There's one last problem that we see cropping up frequently with TSIG: time synchronization. The timestamp in the TSIG record is useful for preventing replay attacks, but it tripped us up initially because the clocks on our name servers weren't synchronized. That produced error messages like the following:

Nov 21 19:56:36 wormhole named-xfer[30420]: SOA TSIG verification from server 
[192.249.249.1], zone movie.edu: BADTIME (-18)

We quickly remedied the problem using NTP, the network time protocol. ^[2]

^[2] See the Time Synchronization Server web site at http://www.eecis.udel.edu/~ntp for information on NTP.

11.1.4 Using TSIG

Now that we've gone to the trouble of configuring our name servers with TSIG keys, we should probably configure them to use those keys for something. In BIND 8.2 and later name servers, we can secure queries, responses, zone transfers, and dynamic updates with TSIG.

The key to configuring this is the server statement's keys substatement, which tells a name server to sign queries and zone transfer requests sent to a particular remote name server. This server substatement, for example, tells the local name server, wormhole.movie.edu, to sign all such requests sent to 192.249.249.1 (terminator.movie.edu) with the key terminator-wormhole.movie.edu:

server 192.249.249.1 {
	keys { terminator-wormhole.movie.edu.; };
};

Now, on terminator.movie.edu, we can restrict zone transfers to those signed with the terminator-wormhole.movie.edu key:

zone "movie.edu" {
	type master;
	file "db.movie.edu";
	allow-transfer { key terminator-wormhole.movie.edu.; };
};

terminator.movie.edu also signs the zone transfer, which allows wormhole.movie.edu to verify it.

You can also restrict dynamic updates with TSIG by using the allow-update and update-policy substatements, as we showed you in the last chapter.

The nsupdate programs shipped with BIND 8.2 and later support sending TSIG-signed dynamic updates. If you have the key files created by dnssec-keygen lying around, you can specify either of those as an argument to nsupdate's -k option. Here's how you'd do that with BIND 9's version of nsupdate :

% nsupdate -k Kterminator-wormhole.movie.edu.+157+28446.key

or:

% nsupdate -k Kterminator-wormhole.movie.edu.+157+28446.private

With the BIND 8.2 or later nsupdate, the syntax is a little different: -k takes a directory and a key name as an argument, separated by a colon:

% nsupdate -k /var/named:terminator-wormhole.movie.edu.

If you don't have the files around (maybe you're running nsupdate from another host), you can still specify the key name and the secret on the command line with the BIND 9 nsupdate :

% nsupdate -y terminator-wormhole.movie.edu.:skrKc4Twy/cIgIykQu7JZA==

The name of the key is the first argument to the -y option, followed by a colon and the base 64-encoded secret. You don't need to quote the secret since base 64 values can't contain shell metacharacters, but you can if you like.

Michael Fuhr's Net::DNS Perl module also lets you send TSIG-signed dynamic updates and zone transfer requests. For more information on Net::DNS, see Chapter 15.

Now that we've got a handy mechanism for securing DNS transactions, let's talk about securing our whole name server.