BIND 9 security

BIND 9 offers Transaction Signatures (TSIG) and Signatures (SIG) as security measures for named.

The name server with BIND 9, by default, does not allow dynamic updates to authoritative zones, similarly to that of BIND 8.

BIND 9 primarily supports Transaction Signatures (TSIG) for server-to-server communication. This includes zone transfer, notify, and recursive query messages. TSIG is also useful for dynamic updates. A primary server for a dynamic zone should use access control to control updates, but IP-based access control is insufficient.

By using key base encryption rather than the current method of access control lists, TSIG can be used to restrict who can update to the dynamic zones. Unlike the Access Control List (ACL) method of dynamic updates, the TSIG key can be distributed to other updaters without having to modify the configuration files on the name server, which means there is no need for the name server to reread the configuration files.

1. Generate the key using the dnssec-keygen command:

   dnssec-keygen -a HMAC-MD5 -b 128 -n HOST keyname

   • HMAC-MD5 is the algorithm used for encryption
   • 128 is the length of the key to use (or number of bits)
   • HOST: HOST is the TSIG keyword used to generate a host key for shared key encryption.
   The command

   dnssec-keygen -a HMAC-MD5 -b 128 -n HOST venus-batman.abc.aus.century.com

   would produce two key files, as follows:

   Kvenus-batman.abc.aus.century.com.+157+35215.key
   Kvenus-batman.abc.aus.century.com.+157+35215.private

   • 157 is the algorithm used (HMAC-MD5)
   • 35215 is the finger print, which is useful in DNNSEC because multiple keys per zone are allowed
2. Add the entry to named.conf on the master name server:

   // TSIG Key
   key venus-batman.abc.aus.century.com. {
           algorithm hmac-md5;
           secret "+UWSvbpxHWFdNwEAdy1Ktw==";
   };

   Assuming HMAC-MD5 is being used, both keyfiles contain the shared key, which are stored as the last entry in the files. Find a secure way to copy the shared secret key to the client. You do not need to copy the keyfile, just the shared secret key.

   Following is the entry for file Kvenus-batman.abc.aus.century.com.+157+35215.private:

   Private-key-format: v1.2
   Algorithm: 157 (HMAC_MD5)
   Key: +UWSvbpxHWFdNwEAdy1Ktw==

   Below is an example of the named.conf file for the master name server. The zone abc.aus.century.com allows zone transfer and dynamic updates only to servers with the key venus-batman.abc.aus.century.com. Do the same to the reverse zone, which requires updaters to have the shared key.

   // TSIG Key
   key venus-batman.abc.aus.century.com. {
           algorithm hmac-md5;
           secret "+UWSvbpxHWFdNwEAdy1Ktw==";
   };
   
   options {
           directory "/usr/local/domain";
   };
   
   zone "abc.aus.century.com" in {
           type master;
           file "named.abc.data";
           allow-transfer { key venus-batman.abc.aus.century.com.;};
           allow-update{ key venus-batman.abc.aus.century.com.; };
   };

   Because zones transfers are now restricted to those that have a key, the slave name server's named.conf file must also be edited. All requests to 192.9.201.1 (venus.abc.aus.century.com) are signed by a key. Note the name of the key (venus-batman.abc.aus.century.com.) must match those on the servers who use them.

   Below is an example of the named.conf file on the slave name server:

   // TSIG Key
   key venus-batman.abc.aus.century.com. {
           algorithm hmac-md5;
           secret "+UWSvbpxHWFdNwEAdy1Ktw==";
   };
   
   server 192.9.201.1{
           keys { venus-batman.abc.aus.century.com.;};
   };
   
   options {
           directory "/usr/local/domain";
   };
   
   zone "abc.aus.century.com" IN {
       type slave;
       file "named.abc.data.bak";
       masters { 192.9.201.1; };
   };