Chains of Trust

DNSSEC uses asymmetric key pairs – that is, pairs of private keys and public keys. The two-element system was devised by IETF (Internet Engineering Task Force) architects. A Zone Signing Key (ZSK) protects the individual RRs in a zone file and, in turn, is protected by the Key Signing Key (KSK) (see Figure 2).

Inside a zone, it is sufficient to know the public KSK to validate the ZSK and then the RRs. Between a parent and a child zone, DNSSEC uses a delegation signer RR (DS-RR). At the top of the chain of trust is a KSK, which specifies the SEP, or Trusted Anchor, and designates the zone hierarchy below it as a secure island. Adding these SEPs to the DNSSEC server configuration is the responsibility of an organization's admin.

To do so, the admin enters the KSKs for the secure islands to be supported to the trusted-keys section of the named.conf file (see Listing 1). The hierarchy should use the highest possible KSKs available and make sure that the keys were transferred in a trustworthy manner. The zone names are followed by three fields. The Flags field defines the key type; 256 stands for ZSK and 257 for KSK. The second value is the Protocol field, which must contain a 3, in line with RFC 4034. The third value specifies the algorithm used, with 5 standing for RSA/SHA-1.

01 trusted-keys {
02  "example.com." 257  3  5
03   "AwEAAcDKu5Kqbk92caGeQ2GjQDucJ2t6jfUb
04    gdye+zyw6qS9PorViM5ViTifFt1JYgB5RnGf
05    wFwqEDm2eeopakOYnJdnVAgDJFd/4sEp7dJW
06    A4zPEvy8LYXCAqkbL5FqZcv9fbYHF2rKYlZJ
07    y5MbmEOk/X4nrxcjwSIcbpIe4/mhjWmR1+jA
08    AVlyODwko2edeilKuW5y/LpPvdZ3qXsw6mTU
09    pa39NcGbzDbHVyFZrQhnxjCD2cy6rWe5ZYck
10    c9VyQQafFLXx5h56Aif0mi1i7f7uZjm6wAIc
11    iv+CkVUfKbcdqpoBThBWH67VqD8kljLRsEGt
12    wRWZbGfjhuGkm56MHZCfYTk=";
13
14 "tux.local." 257  3  5
15   "AwEAAa+z+JB9qd6Q9Kg7isg/DqJdqX9Kqxpu
16    One4zGlUWNJXAT5ivVva5N4l1YOPfq2M+dJH
17    Mxg9jmFZmrTLS8HYvuYzTVuBMh1u3hvS6UBr
18    SzEJdqWDpO/AJbWDUP+SIfryeW0ZV7weHDX7
19    Xjqrrh2+8+Dc/k8LFxoocBeio9gljYMLdIvM
20    ddOUOhFxx6o4WvVNhuWF+i1HDoqGDOOWgRCk
21    9KO0fZpx8h/dwwyqL4/9Zk0MLF6KQaxg0+tQ
22    khhI6sq+7BYmnNBauJQlwLY8qrlA/gaajahU
23    PaHbJ1vzg+G5mLFI1vEt5FTGVXWJp0GWD6yK
24    uLdrYlL0oOapQ8FG9AqMrvk=";
25 };

Client or Server?

The standard scenario uses a DNS server as the resolver on the local network that queries a forwarder on the provider's network. The DNS server validates the responses it receives from the provider-side DNS server. To be able to do so, the administrator first must enable DNSSEC. As of version 9.4.2, ISC recommends a BIND server. Enabling DNSSEC when building the program is imperative. Most distributions offer this option as part of their bind9 packages. The dnssec-tools are useful for testing and debugging but are not necessary to run the system [4].

The dnssec-enable yes; option in the named.conf configuration file generically enables DNSSEC functionality. If at least one trusted key is defined as a SEP, you just need to reload named; the resolver in this example would validate the example.com and tux.local zones, as well as any zones below them in the chain of trust (e.g., branch1.example.com).

Signing a Zone

Name server operators first must generate and set up key pairs for their domains and zones, starting with ZSKs and KSKs on the primary domain server to sign the individual zone records. Authoritative zone servers must be enabled by setting dnssec-enable yes; for DNSSEC. The following command issued on the primary name server creates a key pair for the example.com zone:

dnssec-keygen -a RSASHA1 -b 2048 -n ZONE example.com

The -a option specifies the algorithms RSA and SHA1. Although the developers typically recommend RSA with SHA-1, you can specify other algorithms, such as DSA or RSA/MD5.

The -b parameter specifies the key length, and -n is followed by the record owner, which is ZONE for a zone; however I will ignore other records (i.e., HOST, ENTITY, USER) for the purposes of this article.

The newly created key serves as the ZSK. To create a matching KSK, you need to add the -f KSK option to the command. This results in a file called Kexample.net.+005+18553, which is a concatenation of K for the KSK, the domain name, the encryption and hash algorithms, and a randomly generated key ID separated by plus characters. The algorithm designators are 1 for RSA/MD5, 3 for DSA, and 5 for RSA/SHA-1.

After generating the keys, listing the current directory should reveal the public key with its .key file extension and the private key with a suffix of .private. Now the public key (see Listing 2) can be added to the zone file with the $include directive, as shown in Listing 3.

01 cat Kexample.net.+005+18553.key
02   example.net. IN DNSKEY 256 3 5 (
03       ZUPI4+0M1V0+SQmFzHQtZMuzLH3UxWE0GmG5Gfj...
04       ijandHGG8lD3IO1azWN6DiVFEVzgr0otAdDonfY...
05       =oElkw== )

01 ; example.com zone
02 ;
03 $TTL 10
04 $ORIGIN example.com.
05
06 @             100 IN SOA ns1.example.com. (
07                   admin.example.com.
08                   2007112001
09                   100
10                   200
11                   604800
12                   100
13               )
14
15                   NS      ns.example.com.
16 ns1.example.com.  A       172.16.5.1
17 a                 A       192.168.0.1
18 b                 A       192.168.0.2
19
20 $include Kexample.com.+005+18553.key ; ZSK
21 $include Kexample.com.+005+42209.key ; KSK