In our previous article, we covered how BIND 9.7.0 embeds timing metadata directly in DNSSEC keys as its method for DNSSEC key lifecycle management. In this article, we discuss the new BIND 9.7.0 Smart Signing feature and how it improves and simplifies the process of signing a single zone. 

With all the DNSSEC related changes in BIND 9.7.0, it should come as no surprise that many of the BIND-provided utilities have been updated, and a few new ones have been added to the distribution. First two (2) new utilities have been added:

• dnssec-settime - used to either get OR set DNSSEC key metadata timers of KSKs
• dnssec-revoke - used to set the REVOKED bit on a DNSSEC key

Major changes to existing tools include:

• rndc sign - this option is new to Bind 9.7.0 to support "Smart Signing" and one-touch signing of a zone. 
• dnssec-keygen -K - this option will inform dnssec-keygen where to write out DNSSEC keys 
• dnssec-keygen -C - Compatibility Mode for suppressing metadata in the DNSSEC keys 
• dnssec-keygen -P, -A, -R, -I, -D date/[+-]offset - These options are used to set DNSSEC key lifecycle metadata
• dnssec-signzone -S - this option is used for performing "Smart Signing"

One of the first improvements that was made to BIND 9.7.0 over its predecessors is the fact that it is now much easier to sign zones. There are fewer steps, and reduced risk of human mishap. The following is the list of steps now required to sign a zone:

1. generate Zone Signing Key(s) or ZSK(s)
2. generate Key Signing Key(s) or KSK(s)
3. sign the zone with the "active" KSK using smart sign

To sign our fictitious zone example.com, we first generate our ZSK as follows:

-bash-4.0$ dnssec-keygen -r /dev/urandom example.com
Generating key pair.................++++++ ............++++++
Kexample.com.+005+42423

In most cases you will need to pass the -r <random_device> for entropy. After running that command, two output files are produced with a base file name like Kexample.com.+005+42423.  Our private key ends with the .private extension and the public key has the .key extension.

Next, we generate our KSK as follows:

-bash-4.0$ dnssec-keygen -r /dev/urandom -f KEY example.com
Generating key pair........................................+++ ...................+++
Kexample.com.+005+50902

By passing the -f KEY argument, we've generated the KSK for signing the zone material. Two (2) additional key files are generated, a public key and a private key. 

Using "Smart Sign", we sign the zone as follows:

-bash-4.0$ dnssec-signzone -r /dev/urandom -S example.com
Fetching ZSK 42423/RSASHA1 from key repository.
Fetching KSK 50902/RSASHA1 from key repository.
Verifying the zone using the following algorithms: RSASHA1.
Zone signing complete:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
                    ZSKs: 1 active, 0 stand-by, 0 revoked
example.com.signed
 

In this example, we only signed using only one active ZSK and KSK. You should end up with the following set of files:

-bash-4.0$ ls -lt
total 60
-rw-r--r-- 1 named named 8847 2010-02-18 18:00 example.com.signed
-rw-r--r-- 1 named named  167 2010-02-18 18:00 dsset-example.com.
-rw-r--r-- 1 named named  855 2010-02-18 18:00 example.com
-rw-r--r-- 1 named named  554 2010-02-18 17:56 Kexample.com.+005+50902.key
-rw------- 1 named named 1774 2010-02-18 17:56 Kexample.com.+005+50902.private
-rw-r--r-- 1 named named  380 2010-02-18 17:49 Kexample.com.+005+42423.key
-rw------- 1 named named 1010 2010-02-18 17:49 Kexample.com.+005+42423.private
 

Our signed zone file, example.com.signed, should contain RRSIG, NSEC, and DNSKEY records. Click the links below to see the unsigned zone example.com prior to signing, and compare this to the DNSSEC signed zone example.com.signed:

There should also be a file generated with the name dsset-example.com this file is called the SEP or Secure Entry Point file.  It contains the DS records that are populated in its parent zone as a key component to constructing the "Chain of trust".  The owner(s) of the .com zone would embed the contents of the dsset-example.com files or DS records in the .com zone and in turn sign the .com zone. When the roots and TLD zones are all signed, we will have the opportunity to achieve a single "Chain of trust" from the top of the DNS hiearchy to any DNSSEC signed zone(s).  The dsset-example.com file contains the following data:

-bash-4.0$ more dsset-example.com.
example.com.            IN DS 50902 5 1 A8F9DA087506D0B60439FC244196CC17234C6A5B
example.com.            IN DS 50902 5 2 D76CF328705DD7AF5D5B22E3EEE74CDF6CE088BD
BA0862E311BCBF81 CE88DB78