DNSSEC new key metadata
DNSSEC private key file format has been extended to contain key timing metadata, allowing the administrator to schedule when a key will be scheduled, published, and revoked.
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:
Metadata | Description |
---|---|
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 - permits you to sign the zone "manually" or in a controlled fashion using the
rndc
command line utility. Named will use thekey-directory
to locate current DNSSEC keys and will sign the zone when therndc sign <zone>
command is provided. - 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.
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:
Component | BIND 9.7.0 | DNSSEC-TOOLS | OpenDNSSEC |
---|---|---|---|
DNSSEC key lifecycle | Metadata stored in DNSSEC Keys | zone keyrec file | signconf XML datafile |
Zone Signing | Smart Sign/Automatic | zonesigner CLI | ods-signzone CLI |
DNSSEC key rollover | Not fully implemented | rollerd daemon | ods-signerd daemon |
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.