Securing DNS Transactions With Transactional Signatures (TSIG)

Transactional Signatures (TSIG) is a mechanism for authenticating DNS messages as specified in RFC 2845. TSIG allows DNS messages such as zone transfers to be cryptographically signed using a shared secret. It can be used in any DNS transaction as a way to restrict access to certain server functions (e.g. zone transfers, recursive queries, record updates) and can be combined with IP restrictions as well.

This article describes one way of using TSIG to authenticate DNS messages in ISC Bind9.

Creating A TSIG Key File

Here, we generate a shared secret to be distributed to hosts involved in DNS transactions. Let’s have, for example, two hosts:


The following command generates a 512-bit HMAC-SHA512 key:

dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST -r /dev/urandom host1-host2

From the file with a filename similar to host1-host2.private, we extract the key (the string following the label “Key”:


We shall use this string as the shared secret.

On each server, let us create the following file: /etc/named/named.conf.tsigkeys, assuming /etc/named is a valid directory that can be used by Bind. We put the text into this file:

key "tsig-key" {
    algorithm HMAC-SHA512;
    secret "VApI7Kkz9lKCG3oQgxdYi+PRuFliK9ZaVDz2xOdqgQ2DwNHmbrTGEbpG6cjwOYhSmVuqJjHTpUZft1zrFGARzw==";

Copy this file in a secure way to all the servers that will be exchanging DNS transactions. For example, use scp to distribute the file.

Make sure the file is only readable by root and the user under which Bind (i.e. the named daemon) runs.

Add this statement in named.conf, the main Bind configuration file:

include "/etc/named/named.conf.tsigkeys";

In host1, add the following reference to host2 in host1’s named.conf:

server {
    keys { tsig-keys. ;};

Similarly, in host2, add the following reference to host1 in host2’s named.conf:

server {
    keys { tsig-keys. ;};

These entries make sure that DNS transactions between the two hosts are signed.

Access Control

TSIG keys may be specified in ACL definitions and directives such as allow-query, allow-transfer, and allow-update. The key would be denoted in an ACL as key tsig-key.

For example:

acl dns-servers {;;
allow-transfer { ! { !dns-servers; any; }; key tsig-key. ;};

enables transfers to succeed only if the transfer requestes comes from an address in the dns-servers ACL and if it’s signed using the tsig-key key.

To test, use dig:

dig @ axfr

from the server host2 ( With the above command lacking the shared key, you should get a ‘Transfer failed.‘ message and not be able to transfer the zone.

On the other hand, using this:

dig @ axfr -k /etc/named/named.conf.tsigkeys

you should be able to transfer the zone with no errors.

Continue reading

Disk Encryption With LUKS

Originally meant for Linux, the Linux Unified Key Setup (LUKS) is “a disk encryption specification created by Clemens Fruhwirth in 2004”.1 LUKS is what I used to encrypt a partition of my external hard drive. As an experiment, I did the following:

  • Create a disk partition or partitions using fdisk. In my case, I created one partition that became /dev/sdc1 on my host computer.
  • Encrypt the partition using cryptsetup:
    • cryptsetup -vv luksFormat /dev/sdc1 where -v is for verbosity
  • You will be prompted for a password that will be used to lock the disk partition.
  • Unlock the partition:
    • cryptsetup -vv open /dev/sdc1 whatever_name
  • Format the partition to whatever filesystem you want (e.g. ext4):
    • mke2fs -vv -t ext4 /dev/mapper/whatever_name
  • Mount the partition and test it:
    • mount -t ext4 /dev/mapper/whatever_name /mnt/t01

To remove the external drive, you must first unmount the decrypted partition:

    umount /mnt/t01

Then, wipe the existing mapping and wipe the encryption key from kernel memory:

    cryptsetup close /dev/mapper/whatever_name

All the above commands were done as root. The host was running Ubuntu 20.04.1 LTS and the external hard drive was connected via USB 3.

I will continue with my experiments with encrypted disks. I am particularly interested in how to auto mount the encrypted disk at boot time. Luckily, there are a number of web articles on this matter. In a future article, I will try some of the procedures used in those web articles and discuss my own experience with auto mounting.