One of the most glaring new features to Bind 9.7.0 is in the area of DNSSEC key lifecycle management, which includes the generation, publication, revocation, and eventual deletion of DNSSEC keys as it pertains to signing zones and performing DNSSEC key rollover. Presently, there are a number of different DNSSEC tools frameworks such as DNSSEC-TOOLS and OpenDNSSEC which have their own suite of scripts, services, and CLIs for handling DNSSEC Key generation, zone signing, and key rollover operations.  Now, some of these operations are available in BIND 9.7.0.

A different approach has been taken by the BIND development team to implement DNSSEC key lifecycle management through the storage of metadata directly in DNSSEC keys, represented by all those K* files that get generated with the dnssec-keygen utility.

Which BIND-provided tools now support and implement the DNSSEC key metadata?

The following utilities now implement and handle the metadata of DNSSEC keys:

• dnssec-keygen - utility used for generating new DNSSEC keys
• dnssec-settime - utility for setting or printing DNSSEC key metadata
• dnssec-keyfromlabel - used for retrieving and generating DNSSEC keys from HSM devices

What metadata is stored in the keys?

The tools named above all support a new set of arguments for controlling the metadata that is supplied to DNSSEC keys.  The following metadata is now supported:

• Publication date - This is the date OR offset (secs) for the Key Signing Key or KSK to be published in the zone.
• Activation date - This represents the date OR offset (secs)  the KSK is to be activated in the zone and used in signing the zone itself.
• Revocation date - This is the date or offset (secs) the KSK should have its revoked bit set in the zone.  NOTE: The key will still exist in the zone and is still used in signing the zone. 
• Inactivation date - This is a date or offset (secs) when the KSK should be marked inactive, and no longer used in signing the zone.  However, the KSK remains present in the zone. 
• Deletion date - This date or offset (secs) specifies when the KSK is removed from the zone.

How is the metadata stored?

When DNSSEC keys are generated to files, a key pair is built, consisting of a private key and a public key.  In particular, when KSKs are built, they can be built with the aforementioned publish, activate, revoke, inactivate, and delete "timers" to set that DNSSEC key's lifecycle.  A human-readable description of the metadata is also provided commented out in the public key for informational purposes.

Example: Kexample.com.+005+63982.key 

; This is a key-signing key, keyid 63982, for example.com.
; Created: Tue Jan 12 16:57:25 2010
; Publish: Tue Jan 12 16:57:25 2010
; Activate: Tue Jan 12 16:57:25 2010
; Revoke: Tue Jan 19 16:57:25 2010
; Inactive: Tue Jan 19 16:59:05 2010
; Delete: Tue Jan 19 17:00:45 2010
example.com. IN DNSKEY 257 3 5 AwEAAbop12N73aBYNiU7gvgty/QqQbYwcKhtVfBn4YOzYY0tuBOeUqWu 
CKyx6mhndrarWm4sKsXaMJB8ftocSfiaWyLrUd3Ul98FuYK5B2Iv3eCn 8QVtrj5/StsGhtI9+i/qnix/y3SmjP
wCGAA/5Nb+C48mf/2HWtA07DW+ EA83Id+HGvWJnQibdCRguk3VempIAD/905ZtoMXiKDoyZ8sRcMv0vgeF cLb
mjbUfwueSPTYksPgvXttX/K5UATle19NShRUgc9p91/PlURwV4JMi /R8oq1dBELuINL4Z/Nxk2RYBPT00frh0x
i06eVZPu7mtiS0WOnkopuvY NVZFfNFFF3k=

Example: Kexample.com.+005+63982.private 

Private-key-format: v1.3
Algorithm: 5 (RSASHA1)
Modulus: uinXY3vdoFg2JTuC+C3L9CpBtjBwqG1V8Gfhg7NhjS24E55Spa4IrLHqaGd2tqtabiwqxdowkHx+2h
xJ+JpbIutR3dSX3wW5grkHYi/d4KfxBW2uPn9K2waG0j36L+qeLH/LdKaM/AIYAD/k1v4LjyZ//Yda0DTsNb4QD
zch34ca9YmdCJt0JGC6TdV6akgAP/3Tlm2gxeIoOjJnyxFwy/S+B4VwtuaNtR/C55I9NiSw+C9e21f8rlQBOV7X
01KFFSBz2n3X8+VRHBXgkyL9HyirV0EQu4g0vhn83GTZFgE9PTR+uHTGLTp5Vk+7ua2JLRY6eSim69g1VkV80UU
XeQ==
PublicExponent: AQAB
PrivateExponent: dxsSDTpQn6gQbF3Y+4QBe2QVysTPL1NUqo0sAaEhBrx7i0G+SvY/4o2qFcYsc87J+rcTXq
asb6TXXCDBSucm6/520GCWEkCNYg+To8RQRs3sLLbxxlaWw+83DwhMK6AGNx5EQ4vTo+CLDo3SkaLULnBJbyHMf
m19uxyxFasGZwXnI7/5zxKPLSKE50xlWpk6MAHpPZVKjsTK9uGIUT2ACa/2VaHb5YKKonFVhBmjgIEznTSHdfXf
VC8HsKRdH4vezEW2dPINxbKruFdE+GmNgdukAQ5zLLDUJPWxq0Un9NDEdSCRzn6MF1BNcRHlV+wcEhtGaKKWOFl
AmpElPw/fAQ==
Prime1: 8BSYpgbyOSKr3znb8mGj98uAzqqs/222OVENpwe4IMyVqtKF0ZzIo/vTVt1MJnMKhb5e3d+BhNfkrSl
dzjRE9doTzZrdl7JEINPdrlLwi8xOiRNtWv+vLTvdUapQGSZPcwhBs+82H9132sNDiWw9sOwSCCzUWNbqsXbRbP
qWnEk=
Prime2: xoH+ykvW7yFlOo4720sWqdmnirrxSh9CyyWui3uGoZuC4IW5HnodnnmFhSYoAP1FMvcLd0LMiGhKgFQ
qIOIreVLVPpMYmLaOXpmZOD5S+arWuHedDpaF7nbuR9O12S7GVVpJV8qx3C9QReWh8qmajusCxoZoHNFmSUtwMj
QwbE=
Exponent1: OGdOWatGGyBHKuGoB/DimePotiUpEbWP2zVstLI+kw4dl41wPQfNp6ERTNYe/uWGMlfAZ/YLss8Z
/Yi7biefj/cVMffRWcNa+C9uZHc95kowpUm4JmntmP34iCgwO0hh4A+vh/uKRsA8WVwIsO+KKte7gMovdVPAvcL
Bfw38dmk=
Exponent2: pZxGiVeEVbSy04tefLHEkqe3k5IrQ/+Ypgsl99Byndkz80UdEEQo+dHAhzkyHsEuPjrFIhZktVjs
7utIym5mfq2QosftuVp1ARCg5ICc+6nSQ9w0zxrvluPEYEmyaRjsz1Hmivs+oW15NxkKyPdUp0RpYEnCH46L/hx
6c2AWacE=
Coefficient: cXlUDE4zYp7ATTj0a8KVoQ+0SARHyVocjHyFP2+yLG9wBH9NPwWJ4oA2poGYY+sDMdlFoD+mkU
hc89BHShS+yMp6txdnjyHIQTTT2MGS/WrI80MOGpKSj+YHWO0yYXjlLryU80p0jB43Re40pCaU8/c3ATTJEdc2c
WOGqDfxbR0=
Created: 20100112235725
Publish: 20100112235725
Activate: 20100112235725
Revoke: 20100119235725
Unpublish: 20100119235905
Delete: 20100120000045

How is the metadata used in DNSSEC key lifecycle management?

BIND 9.7.0 introduces a new mechanism for automatically signing a zone. This is implemented with the auto-dnssec directive, which can be added to the zone statement of the named.conf file. Enabling auto-dnssec supports two (2) modes of automatic zone signing:

• allow - When auto-dnssec is set to allow, this permits you to sign the zone "manually" or in a controlled fashion using the rndc command line utility.  Named will use the key-directory to locate current DNSSEC keys and will sign the zone when the rndc sign <zone>  command is provided.
• maintain - When auto-dnssec is set to maintain, the named process will "automatically" sign the zone(s) based upon any KSKs it finds in the respective key-directory.  Additionally, it will use any metadata contained in the keys to control when the keys are published, activated, revoked, inactivated, and/or removed from a zone. 

We will provide a more in-depth information on how to implement auto-dnssec in a later article in this series. 

NOTE: BIND 9.7.0 currently doesn't fully support KSK rollovers. This means that with auto-dnssec maintain; enabled, new KSKs will not be created,and your current KSKs in use may become obsoleted and ultimately removed, breaking the chain of trust.

How does DNSSEC key lifecycle management differ between BIND, DNSSEC-TOOLS, and OpenDNSSEC?

This question is best answered by defining the three (3) main aspects of DNSSEC Key maintenance, including DNSSEC key lifecycle, DNSSEC zone signing operations, and DNSSEC key rollover.  The following table summarizes at a high level how BIND 9.7.0 compares to the other DNSSEC frameworks that exist:

Although BIND 9.7.0 has automatic zone signing, it's currently lacking the ability to generate new KSKs during KSK rollovers.  In other words, current KSKs will be revoked, marked inactive, and ultimately removed from the zone, but NO new KSK will be generated in its place.  According to the ISC, this is a feature or enhancement that will show up in BIND 9.7.1 or later.  In the mean time, a shell script and cron job would be needed to fill that gap in support.

Does the inclusion of new metadata in DNSSEC keys break other implementations?

BIND 9.7.0 can generate "old-style" DNSSEC keys without any metadata.  This is done by passing the -C or compatibility mode command line argument when executing the utilities.  By default, however, this new metadata will be included directly in the DNSSEC ZSK and KSK file(s).  The compatibility mode suppresses the key timing metadata, ensuring backwards compatibility with many of the other existing DNSSEC tools and frameworks that exist.

What's next?

In this fist post, we've covered how BIND 9.7.0 performs DNSSEC key lifecycle and how it stores metadata directly in the DNSSEC keys.  Next, we'll cover the automatic signing support in BIND 9.7.0.