TSIG keys are a cryptographic mechanism BIND uses to authenticate DNS zone transfers, ensuring that only authorized servers can request and receive zone data.
Here’s a live example of a BIND zone transfer using TSIG.
First, on the primary (master) DNS server, you’ll need to generate a TSIG key.
dnssec-keygen -a hmac-sha256 -b 256 -n HOST tsig-key-name
This command generates two files: Ktsig-key-name.+157+12345.key and Ktsig-key-name.+157+12345.private. The .key file contains the public part of the key, and the .private file contains the secret. You’ll need the key name and the secret itself.
Next, configure your named.conf on the primary server to include this key and assign it to specific zones.
key "tsig-key-name" {
algorithm hmac-sha256;
secret "your_base64_encoded_secret_here";
};
zone "example.com" {
type master;
file "db.example.com";
allow-transfer { key "tsig-key-name"; };
};
The secret value is the Base64 encoded string found in the .private file, often looking something like AbCdEfGhIjKlMnO pQrStUvWxYz0123456789+/=. The allow-transfer directive now restricts zone transfers to servers presenting this specific TSIG key.
On the secondary (slave) DNS server, you’ll need to configure it to use the same key and request the zone transfer.
key "tsig-key-name" {
algorithm hmac-sha256;
secret "your_base64_encoded_secret_here";
};
zone "example.com" {
type slave;
file "db.example.com.slave";
masters { primary-server-ip-address; };
request-xfr key "tsig-key-name";
};
The request-xfr directive tells the secondary server to use the specified key when requesting zone transfers for this zone.
When the secondary server initiates a zone transfer (AXFR or IXFR), it will include the TSIG record in its request. The primary server will use the shared secret to generate a cryptographic signature for the request. If the signature matches what the primary server generates using its copy of the secret, the transfer is allowed. If it doesn’t match, the transfer is denied.
The surprising truth about TSIG is that it doesn’t encrypt the zone data itself; it only provides authentication. The zone transfer traffic is still sent in plain text. This means that while you’re sure who is requesting the transfer, you’re not necessarily protecting the confidentiality of the zone data during transit.
One common pitfall is ensuring the clock skew between the primary and secondary servers is minimal. TSIG keys have a built-in timestamp that is used in the signature calculation. If the server clocks are too far apart (typically more than 5 minutes), the signature will be considered invalid, and the zone transfer will fail, even with the correct key.
The next step after securing zone transfers is often to look into DNSSEC, which provides data integrity and origin authentication for DNS queries themselves.