Bind Security: Transaction Signatures (TSIG) Configuration

by on January 27, 2009 · 13 comments· LAST UPDATED January 27, 2009

in , ,

Q. How do I configure BIND9 name serves with TSIG (Transaction SIGnature) mechanism to secure server-to-server communication? How do I use secret key transaction authentication for DNS (bind nameservers)?

A. Transaction signatures (TSIG) is a mechanism used to secure DNS messages and to provide secure server-to-server communication (usually between master and slave server, but can be extended for dynamic updates as well). TSIG can protect the following type of transactions between two DNS servers:

  • Zone transfer
  • Notify
  • Dynamic updates
  • Recursive query messages etc

TSIG is available for BIND v8.2 and above. TSIG uses shared secrets and a one-way hash function to authenticate DNS messages. TSIG is easy and lightweight for resolvers and named.

How it works?

  1. Each name server adds a TSIG record the data section of a dns server-to-server queries and message.
  2. 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.
  3. TSIG uses a one-way hash function to provide authentication and data integrity.

Our sample setup:

  • Master nameserver: ns1.theos.in - 202.54.1.2
  • Slave nameserver: ns2.theos.in - 75.55.2.100
  • BIND configuration is stored in /etc/bind/ directory.
  • Zone data is stored in /etc/bind/named.conf file.

How do I configure TSIG?

Type the following command on master nameserver (ns1.theos.in) to create the shared keys, using the dnssec-keygen program, which creates two files, both containing the key generated.
# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST rndc-key
Sample output:

Krndc-key.+157+64252

List all files, enter:
# ls -l
Output:

total 52
-rw-r--r-- 1 root root  237 2009-01-06 12:16 db.0
-rw-r--r-- 1 root root  271 2009-01-06 12:16 db.127
-rw-r--r-- 1 root root  237 2009-01-06 12:16 db.255
-rw-r--r-- 1 root root  353 2009-01-06 12:16 db.empty
-rw-r--r-- 1 root root  256 2009-01-06 12:16 db.local
-rw-r--r-- 1 root root 1506 2009-01-06 12:16 db.root
-rw------- 1 root root   52 2009-01-25 14:13 Krndc-key.+157+64252.key
-rw------- 1 root root   81 2009-01-25 14:13 Krndc-key.+157+64252.private
-rw-r--r-- 1 root bind 1302 2009-01-25 14:13 named.conf
-rw-r--r-- 1 root bind  165 2009-01-06 12:16 named.conf.local
-rw-r--r-- 1 root bind  358 2009-01-25 14:02 named.conf.options
-rw-r----- 1 bind bind   77 2009-01-24 20:37 rndc.key
-rw-r--r-- 1 root root 1317 2009-01-06 12:16 zones.rfc1918

Where,

  • -a Specify the encryption algorithm.
  • -b Specify the key size.
  • -n Specify the nametype. A nametype can be a ZONE, HOST, ENTITY, or USER. Usually, you need to use HOST or ZONE such as theos.in

The above dnssec-keygen program created two files as follows. Both .key and .private files are generated for symmetric encryption algorithms such as HMAC-MD5, even though the public and private key are equivalent:

  • Krndc-key.+157+64252.key - Contains the public key. The .key file contains a DNS KEY record that can be inserted into a zone file.
  • Krndc-key.+157+64252.private - Contains the private key. The .private file contains algorithm-specific fields.

Using TSIG - master server configuration

Run the following command and note down the Key:
# cat Krndc-key.+157+64252.private
Sample output:

Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: 0jnu3SdsMvzzlmTDPYRceA==
Bits: AAA=

Open /etc/bind/tsig.key file, enter:
# vi /etc/bind/tsig.key
Now you need to create tsig.key file on master server as follows:

key "TRANSFER" {
          algorithm hmac-md5;
          secret "0jnu3SdsMvzzlmTDPYRceA==";
};
# Slave server IP # 1
server 75.55.2.100 {
        keys {
                TRANSFER;
    };
};
################################
# If you have 3rd slave server with IP 64.1.2.3
#server 64.1.2.3 {
#        keys {
#                TRANSFER;
#    };
#};
################################
 

First block is nothing but keys. TSIG keys are configured using the keys substatements. The keys substatements inform a name server to sign queries and zone transfer requests sent to a particular remote name server. In our case the above substatement informs the master server, to sign all requests to the host slave server 75.55.2.100 with the key called TRANSFER. The server statement's keys clause to tell the slave name server to sign all zone transfer requests and queries sent to its master server and vice verse. Save and close the file. Open named.conf file, enter:
# vi /etc/bind/named.conf
Append the following line:

include "/etc/bind/tsig.key";

Save and close the file. Restart named:
# rndc reload
OR
# service named restart

Using TSIG - slave server configuration

Create /etc/bind/tsig.key on slave server, enter:
# vi /etc/bind/tsig.key
Append following config:

key "TRANSFER" {
	algorithm hmac-md5;
	secret "0jnu3SdsMvzzlmTDPYRceA==";
};
# Master server IP
server 202.54.1.2 {
	keys { TRANSFER; };
};

Save and close the file. Append following to named.conf:

include "/etc/bind/tsig.key";

Restrict zone transfers only to those signed with a specific key

On the master name server, you can restrict zone transfers only to those signed with a specific key such as TRANSFER. open named.conf
# vi /etc/bind/named.conf
You must restrict zone transfers to those signed with the TRANSFER key as follows:

zone "theos.in" {
        type master;
        file "/etc/bind/zones/master.theos.in";
        allow-transfer {  key TRANSFER; };
};

Save and close the file. Restart / reload the bind server:
# rndc reload
OR
# service named restart

Verify TSGI

Watch your master BIND dns server log file or system log file, enter:
# tail -f /var/log/messages
OR
# tail -f /var/log/syslog
OR
# grep 'theos.in/IN' /var/log/syslog
Sample output:

....
....
Jan 26 13:43:11 rose named[9170]: client 75.126.168.152#52204: transfer of 'theos.in/IN': AXFR-style IXFR started: TSIG transfer
Jan 26 13:43:11 rose named[9170]: client 75.126.168.152#52204: transfer of 'theos.in/IN': AXFR-style IXFR ended
....
..

You should able to see similar message on slave server:

Jan 26 19:18:33 txvip1 named[17899]: client 208.43.138.52#32806: received notify for zone 'theos.in': TSIG 'transfer'
Jan 26 19:18:33 txvip1 named[17899]: zone theos.in/IN: Transfer started.
Jan 26 19:18:33 txvip1 named[17899]: transfer of 'theos.in/IN' from 208.43.138.52#53: connected using 75.126.168.152#45942
Jan 26 19:18:34 txvip1 named[17899]: zone theos.in/IN: transferred serial 2008071011: TSIG 'transfer'
Jan 26 19:18:34 txvip1 named[17899]: transfer of 'theos.in/IN' from 208.43.138.52#53: end of transfer

Suggested readings:

  • man dnssec-keygen
  • BIND 9 Administrator Reference Manual
TwitterFacebookGoogle+PDF versionFound an error/typo on this page? Help us!

{ 13 comments… read them below or add one }

1 Jere January 27, 2009 at 2:13 pm

Cool, thats pretty easy!
Thank you!

Reply

2 mostafa January 27, 2009 at 4:54 pm

very small and very effective it’s the first time for me to understand this

thanx very much

Reply

3 Tapas Mallick January 28, 2009 at 10:05 am

Nice and lucid document to understand and implement. I would like to request you to post same kind of document for “Dynamic DNS with DHCP” and “Secure NTP”.

Regards,
Tapas

Reply

4 Danny February 14, 2009 at 6:39 pm

I’m trying to impliment this, but when I restart named, it says it can’t find the tsig.key file, I’ve quadruple checked for any typo’s

Any clues (I’m tearing my hair out!!)

Reply

5 nixCraft February 14, 2009 at 7:23 pm

Do you run bind in chrooted jail?

Reply

6 Danny February 14, 2009 at 7:29 pm

Not sure I fully understand the question, but it’s on a VPS so I guess the answer’s probably yes

Reply

7 Alejandro March 14, 2009 at 8:16 pm

It Works. OpenBSD 4.4 (master chrooted) and Debian Lenny (slave chrooted).

Your website is very useful !

Thank You Very Much.

Reply

8 ashok reddy January 31, 2010 at 7:27 am

Wonderful document !

Super simple steps.. Thanks much

Have a gr8 day.

Ashok reddy

Reply

9 Babu Satasiya March 3, 2010 at 7:34 pm

nice to have secure zone transfer and you made it simpler for all. Thank you.

Reply

10 GUIgao Pang November 2, 2011 at 9:18 am

Looking at a very simple configuration, but in two server configuration, respectively, after the completion of the test found that always tip NotAuth is this why?

04:28:42.285594 IP 192.168.2.119.60885 > 192.168.2.127.domain: 1993+ A? http://www.test.qq. (29)
04:28:42.286449 IP 192.168.2.127.34074 > 192.168.2.126.domain: 41773 [2au] A? http://www.test.qq. (117)
04:28:42.286589 IP 192.168.2.127.36183 > 192.168.2.126.domain: 52125 [2au] NS? . (105)
04:28:42.288131 IP 192.168.2.126.domain > 192.168.2.127.34074: 41773 NotAuth- 0/0/2 (123)
04:28:42.288382 IP 192.168.2.127.domain > 192.168.2.119.60885: 1993 ServFail 0/0/0 (29)
04:28:42.289374 IP 192.168.2.126.domain > 192.168.2.127.36183: 52125 NotAuth- 0/0/2 (111)

Reply

11 hamida June 13, 2012 at 9:38 pm

it was useful thank you.

Reply

12 Rocky June 14, 2012 at 9:59 am

Hi Vivek,

Which OS and bind version are you using at production environment?

Thanks,
Rocky

Reply

13 VJ May 2, 2013 at 8:15 pm

neatly explained.. came in handy ..!

Reply

Leave a Comment

Tagged as: , , , , , , , , , ,

Previous Faq:

Next Faq: