This document was written using a RHEL 6 system running BIND 9.7.3 in a chrooted environment.

Transaction signatures (TSIG) is a protocol that uses shared secret keys and one-way hashing to provide a secure means to identify each node of a connection as being authorized to make or respond to a DNS update or transfer.TSIG keys can be used to authenticate notifies, dynamic updates, recursive queries and zone transfers.

Configuring the Master Server

Let’s move to the directory where the configuration files for our BIND install are kept.

cd /var/named/chroot/etc

Now we will run the dnssec-keygen command to create the shared keys. We will be using HMAC-SHA1 as our encryption algorithm and a key size of 160 bits.

dnssec-keygen -a HMAC-SHA1 -b 160 -n HOST rndc-key

Sample output:

Krndc-key.+121+47878

This should generate two files:
Krndc-key.+121_47878.private
Krndc-key.+121_47878.key

Now we will view the private key file and record the shared key. We will need to use this key on both the master server and slave server.

cat Krndc-key.+121_47878.private

Private-key-format:v1.3
Algorithm:161(HMAC_SHA1)
Key:ODvOnAg9F2j2Y09jTQRC276h1vY=
Bits: AAA=Created: 20120517154534
Publish: 20120517154534
Activate: 20120517154534

The two lines in the above file that are important are lines 2 & 3. Copy them somewhere safe to be used in the rest of the configuration.

Now we need to create a tsig.key file.

vi tsig.key

The file should read like below, make sure to use the information copied in the last step in the lines highlighted below. Also you should use the IP address of your slave server in line six of this file. If you have multiple slaves you can duplicate slave entries by copying the slave section and changing the IP address (See example below of file with multiple slave servers).

key “TRANSFER” {
algorithmhmac-sha1;
secret“ODvOnAg9F2j2Y09jTQRC276h1vY=”;
};

# Slave server 1 IP
server 192.168.1.6 {
keys { TRANSFER; };
};  
# Slave server 2 IP

server 192.168.1.56 {
keys { TRANSFER; };
};

Now let’s tell named to include this file in it’s configuration and to only allow transfers from slaves that share our key.

vi /var/named/chroot/etc/named.conf

Add the following line:

include “/etc/tsig.key”;

Edit the allow-transfer statement to specific the key name ONLY:

allow-transfer { key TRANSFER; };

Save and close the file.

NOTE:If you leave any IP addresses in the allow-transfer statement it will still allow transfers without using the TSIG key. Having an allow-transfer statement without any hosts listed allows us to be sure no transfers will be permitted without the key.

Now we must reload the service in order for the new configuration to be read. 

service named restart

or

rndc reload

Slave Server Configuration

Let’s create a tsig.key file in our BIND configuration file directory.

cd /var/named/chroot/etc
vi tsig.key

Add the following to the file (using the information copied from the private key file earlier):

key “TRANSFER” {
algorithmhmac-sha1;
secret“ODvOnAg9F2j2Y09jTQRC276h1vY=“;
};

# Master server IP
server 192.168.1.2 {
keys { TRANSFER; };
};

NOTE: Make sure to change the server IP address to the MASTER server.

Now let’s tell named to include this file in it’s configuration.

vi /var/named/chroot/etc/named.conf

Add the following line then save and close the file:

include “/etc/tsig.key”;

Restart named to read new configuration.

service named restart

or

rndc reload

Verify TSIG Keys

In the console window of your master server start tailing the transfer log. We log transfers and queries in the same log, so we will use grep to filter out queries and make the transfer easily identified.

tail -f /var/named/chroot/var/named/data/ns1-bind.log | grep -v query

NOTE: In this case out query log and transfer log were the same file.  Depending on your BIND configuration, your logs may be in a separate file or even a different location.

In a console window of your slave server initiate a transfer:

rndc retransfer domain.com

Back at the console window for your master server you should be able to verify that the TSIG key was used in the transfer by examining the log entries.

17-May-201212:21:29.521xfer-out:info:client192.168.1.6#48945:transferof‘domain.com/IN’:AXFRstarted:TSIGtransfer
17-May-201212:21:29.521xfer-out:info:client 192.168.1.6#48945:transferof‘domain.com/IN’:AXFRended

You should also see similar messages in the slave transfer log:

17-May-2012 12:21:42.825 general: info: zone domain.com/IN: transferred serial 201008302: TSIG‘transfer’
17-May-2012 12:21:42.825 xfer-in: info: transfer of ‘domain.com/IN’ from 192.168.1.2#53: Transfer completed: 1 messages, 62 records, 1693 bytes, 0.001 secs (1693000 bytes/sec)

That's it, you have successfully configured and verified the TSIG keys.