DNS Security: Access Control Lists, TSIG, and DNSSEC

DNS security currently allows you to control specific access by hosts to the DNS server, as well as providing encrypted communications between servers and authentication of DNS servers. With access control lists, you can determine who will have access to your DNS server. The DNS Security Extensions (DNSSEC), included with BIND 9.x, provide private/public key-encrypted authentication and transmissions. TSIG (transmission signatures) use shared private keys to provide authentication of servers to secure actions such as dynamic updates between a DNS server and a DHCP server.

Access Control Lists

To control access by other hosts, you use access control lists, implemented with the acl statement. allow and deny options with access control host lists enable you to deny or allow access by specified hosts to the name server. With allow-query, you can restrict queries to specified hosts or networks. Normally this will result in a response saying that access is denied. You can further eliminate this response by using the blackhole option in the options statement.

You define an ACL with the acl statement followed by the label you want to give the list and then the list of addresses. Addresses can be IP addresses, network addresses, or a range of addresses based on CNDR notation. You can also use an ACL defined earlier. The following example defines an ACL called mynet:

acl mynet { 192.168.0.1; 192.168.0.2; };

If you are specifying a range, such as a network, you also add exceptions to the list by preceding such addresses with an exclamation point (!). In the following example, the mynetx ACL lists all those hosts in the 192.168.0.0 network, except for 192.168.0.3:

acl myexceptions {192.168.0.0; !192.168.0.3; };

Four default ACLs are already defined for you. You can use them wherever an option uses a list of addresses as an argument. These are any for all hosts, none for no hosts, localhost for all local IP addresses, and localnet for all hosts on local networks served by the DNS server.

Once a list is defined, you can then use it with the allow-query, allow-transfer, allow-recursion, and blackhole options in a zone statement to control access to a zone. allow-query specifies hosts that can query the DNS server. allow-transfer is used for master/slave zones, designating whether update transfers are allowed. allow-recursion specifies those hosts that can perform recursive queries on the server. The blackhole option will deny contact from any hosts in its list, without sending a denial response. In the next example, an ACL of mynet is created. Then in the mytrek.com zone, only these hosts are allowed to query the server. As the server has no slave DNS servers, zone transfers are disabled entirely. The blackhole option denies access from the myrejects list, without sending any rejection notice.

acl mynet { 192.168.0.0; };
acl myrejects { 10.0.0.44; 10.0.0.93; };
   
zone "mytrek.com" {
         type master;
         file "mytrek.com";
         allow-query { mynet; };
         allow-recursion { mynet; };
         allow-transfer { none; };
         blackhole {myrejects};
         };

Secret Keys

Different security measures will use encryption keys generated with the dnssec-keygen command. You can use dnssec-keygen to create different types of keys, including zone (ZONE), host (HOST), and user (USER) keys. You specify the type of key with the -n option. A zone key will require the name ZONE and the name of the zone's domain name. A zone key is used in DNSSEC operations. The following example creates a zone key for the mytrek.com zone:

dnssec-keygen -n ZONE mytrek.com.

To create a host key, you would use the HOST type. HOST keys are often used in TSIG operations.

dnssec-keygen -n HOST turtle.mytrek.com.

You can further designate an encryption algorithm (-a) and key size (-b). Use the -h option to obtain a listing of the dnssec-keygen options. Currently you can choose from RSA, DSA, HMAC-MD5, and DH algorithms. The bit range will vary according to the algorithm. RSA ranges from 512 to 4096, and HMAC-MD5 ranges from 1 to 512. The following example creates a zone key using a 768-bit key and the DSA encryption algorithm:

dnssec-keygen -a DSA -b 768 -n ZONE mytrek.com.

The dnssec-keygen command will create public and private keys, each in corresponding files with the suffixes .private and .key. The .key file is a KEY resource record holding the public key. For DNSSEC, the private key is used to generate signatures for the zone, and the public key is used to verify the signatures. For TSIG, a shared private key generated by the HMAC-MD5 algorithm is used instead of a public/private key pair.

DNSSEC

DNSSEC provides encrypted authentication to DNS. With DNSSEC, you can create a signed zone that is securely identified with an encrypted signature. This form of security is used primarily to secure the connections between master and slave DNS servers, so that a master server transfers update records only to authorized slave servers and does so with a secure encrypted communication. Two servers that establish such a secure connection do so using a pair of public and private keys. In effect, you have a parent zone that can securely authenticate child zones, using encrypted transmissions. This involves creating zone keys for each child and having those keys used by the parent zone to authenticate the child zones.

Zone Keys

You generate a zone key using the dnssec-keygen command and specifying the zone type, ZONE, with the -n option. For the key name, you use the zone's domain name. The following example creates a zone key for the mytrek.com zone.

dnssec-keygen -n ZONE mytrek.com.

You can further designate an encryption algorithm (-a) and key size (-b). Use the -h option to obtain a listing of the dnssec-keygen options. Since you are setting up a public/private key pair, you should choose either the RSA or DSA algorithm. The bit range will vary according to the algorithm. RSA ranges from 512 to 4096, and DSA ranges from 512 to 1024. The following example creates a zone key using a 768-bit key and the DSA encryption algorithm:

dnssec-keygen -a DSA -b 768 -n ZONE mytrek.com.

The dnssec-keygen command will create public and private keys, each in corresponding files with the suffixes .private and .key. The private key is used to generate signatures for the zone, and the public key is used to verify the signatures. The .key file is a KEY resource record holding the public key. This is used to decrypt signatures generated by the corresponding private key. You add the public key to the DNS configuration file, named.conf, using the $INCLUDE statement to include the .key file.

DNSSEC Resource Records

In the zone file, you then use three DNSSEC DNS resource records to implement secure communications for a given zone: KEY, SIG, and NXT. In these records, you use the signed keys for the zones you have already generated. The KEY record holds public keys associated with zones, hosts, or users. The SIG record stores digital signatures and expiration dates for a set of resource records. The NXT record is used to determine that a resource record for a domain does not exist. In addition, several utilities let you manage DNS encryption. With the dnskeygen utility, you generated the public and private keys used for encryption. dnssigner signs a zone using the zone's private key, setting up authentication.

To secure a DNS zone with DNSSEC, you first use dnskeygen to create public and private keys for the DNS zone. Then use dnssigner to create an authentication key. In the DNS zone file, you enter a KEY resource record in which you include the public key. The public key will appear as a lengthy string of random characters. For the KEY record, you enter in the domain name followed by the KEY and then the public key.

mytrek.com. KEY 0x4101 3 3 (
AvqyXgKk/uguxkJF/hbRpYzxZFG3x8EfNX389l7GX6w7rlLy
BJ14TqvrDvXr84XsShg+OFcUJafNr84U4ER2dg6NrlRAmZA1
jFfV0UpWDWcHBR2jJnvgV9zJB2ULMGJheDHeyztM1KGd2oGk
Aensm74NlfUqKzy/3KZ9KnQmEpj/EEBr48vAsgAT9kMjN+V3
NgAwfoqgS0dwj5OiRJoIR4+cdRt+s32OUKsclAODFZTdtxRn
vXF3qYV0S8oewMbEwh3trXi1c7nDMQC3RmoY8RVGt5U6LMAQ
KITDyHU3VmRJ36vn77QqSzbeUPz8zEnbpik8kHPykJZFkcyj
jZoHT1xkJ1tk )

For authentication, you can sign particular resource records for a given domain or host. Enter the domain or host followed by the term SIG and then the resource record's signature.

mytrek.com. SIG KEY 3 86400 19990321010705 19990218010705 4932 com. (
Am3tWJzEDzfU1xwg7hzkiJ0+8UQaPtlJhUpQx1snKpDUqZxm
igMZEVk= )

The NXT record lets you negatively answer queries.

mytrek.com. NXT ftp.mytrek.com. A NS SOA MX SIG KEY NXT

Signing Keys

To set up secure communications between a parent (master) and child (slave) DNS server, the public key then needs to be sent to the parent zone. There, the key can be signed by the parent. As you may have more than one zone key, you create a keyset using the dnssec-makekeyset command. This generates a file with the extension .keyset, that is then sent to the parent. The parent zone then uses the dnssec-signkey command to sign a child's keyset. This generates a file with the prefix signedkey-. This is sent back to the child and now contains both the child's keyset and the parent's signatures. Once the child has the signedkey- files, the dnssec-signedzone command can be used to sign the zone. The dnssec-signedzone command will generate a file with the extension .signed. This file is then included in the named.conf file with the INCLUDE operation. The trusted-keys statement needs to list the public key for the parent zone.

TSIG Keys

TSIG (transmission signatures) also provide secure DNS communications, but they share the private key instead of a private/public key pair. They are usually used for communications between two local DNS servers, and to provide authentication for dynamic updates such as those between a DNS server and a DHCP server.

Note

For BIND 8.0, you use dnskeygen instead of dnssec-keygen.

Generating TSIG Keys

To create TSIG keys for your DNS server, you use the dnssec-keygen command as described earlier. Instead of using the same keys you use for DNSSEC, you create a new set to use for transmission signatures. For TSIG, a shared private key is used instead of a public/private key pair. For a TSIG key you would use a HMAC-MD5 algorithm that generates the same key in both the .key and .private files. Use the -a option to specify the HMAC-MD5 algorithm to use and the -b option for the bit size (HMAC-MD5 ranges from 1 to 512.). The -n options to specify the key type, in this case HOST for the host name. The bit range will vary according to the algorithm. The following example creates a host key using a 128-bit key and the HMAC-MD5 encryption algorithm:

dnssec-keygen -a HMAC-MD5 -b 128 -n HOST turtle.mytrek.com

This creates a private and public key, located in the .key and .private files. In a TSIG scheme, both hosts would use the same private key for authentication. For example, to enable DHCP server to update a DNS server, both would need the private (secret) key for a TSIG authentication. The HMAC-MD5 key is used as a shared private key, generating both the same private and public keys in the .key and .private files.

Key Statement

You then specify key in the named.conf file with the key statement. For the algorithm option, you list the HMAC-MD5 algorithm, and for the secret option you list the private key. This key will be listed in both the .private and .key files. The preceding example would generate a key and private file called Kturtle.mytrek.com.+157.43080.key and Kturtle.mytrek.com.+157.43080.private. The contents of the .key file consist of a resource record shown here:

turtle.mytrek.com. IN KEY 512 3 157 ONQAfbBLnvWU9H8hRqq/WA==

The contents of the private file show the same key along with the algorithm.

Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: ONQAfbBLnvWU9H8hRqq/WA==

Within the named.conf file, you then name the key using a key statement.

key myserver {
algorithm HMAC-MD5;
secret "ONQAfbBLnvWU9H8hRqq/WA==";
};

The key's name can then be used to reference the key in other named statements, such as allow-update statements.

allow-update myserver;

The DNS server or DHCP server with which you are setting up communication will also have to have the same key. See the earlier section "Dynamic Update: DHCP and Journal Files" and Chapter 35 for more information on DHCP and TSIG. For communication between two DNS servers, each would have to have a server statement specifying the shared key. In the following example, the named.conf file for the DNS server on 192.168.0.1 would have to have the following server statement to communicate with the DNS server on 10.0.0.1, using the shared myserver key. The named.conf file on the 10.0.0.1 DNS server would have to have a corresponding server statement for the 192.168.0.1 server.

server 10.0.0.1 {  keys (myserver;}; };