dnssec-ksr - create signed key response (SKR) files for offline
KSK setups
dnssec-ksr [-E engine] [-e date/offset]
[-F] [-f file] [-h] [-i date/offset] [-K
directory] [-k policy] [-l file] [-o] [-V]
[-v level] {command} {zone}
The dnssec-ksr can be used to issue several commands that
are needed to generate presigned RRsets for a zone where the private key
file of the Key Signing Key (KSK) is typically offline. This requires Zone
Signing Keys (ZSKs) to be pregenerated, and the DNSKEY, CDNSKEY, and CDS
RRsets to be already signed in advance.
The latter is done by creating Key Signing Requests (KSRs) that
can be imported to the environment where the KSK is available. Once there,
this program can create Signed Key Responses (SKRs) that can be loaded by an
authoritative DNS server.
- -E engine
- This option specifies the cryptographic hardware to use, when applicable.
When BIND 9 is built with OpenSSL, this needs to be set to the
OpenSSL engine identifier that drives the cryptographic accelerator or
hardware service module (usually pkcs11).
- -e date/offset
- This option sets the end date for which keys or SKRs need to be generated
(depending on the command).
- -F
- This options turns on FIPS (US Federal Information Processing Standards)
mode if the underlying crytographic library supports running in FIPS
mode.
- -f
- This option sets the SKR file to be signed when issuing a sign
command.
- -h
- This option prints a short summary of the options and arguments to
dnssec-ksr.
- -i date/offset
- This option sets the start date for which keys or SKRs need to be
generated (depending on the command).
- -K directory
- This option sets the directory in which the key files are to be read or
written (depending on the command).
- -k policy
- This option sets the specific dnssec-policy for which keys need to
be generated, or signed.
- -l file
- This option provides a configuration file that contains a
dnssec-policy statement (matching the policy set with
-k).
- -o
- Normally when pregenerating keys, ZSKs are created. When this option is
set, create KSKs instead.
- -V
- This option prints version information.
- -v level
- This option sets the debugging level. Level 1 is intended to be usefully
verbose for general users; higher levels are intended for developers.
command
The KSR command to be executed. See below for the
available commands.
zone
The name of the zone for which the KSR command is being
executed.
- keygen
- Pregenerate a number of keys, given a DNSSEC policy and an interval. The
number of generated keys depends on the interval and the key
lifetime.
- request
- Create a Key Signing Request (KSR), given a DNSSEC policy and an interval.
This will generate a file with a number of key bundles, where each bundle
contains the currently published ZSKs (according to the timing
metadata).
- sign
- Sign a Key Signing Request (KSR), given a DNSSEC policy and an interval,
creating a Signed Key Response (SKR). This will add the corresponding
DNSKEY, CDS, and CDNSKEY records for the KSK that is being used for
signing.
The dnssec-ksr command exits 0 on success, or non-zero if
an error occurred.
When you need to generate ZSKs for the zone
"example.com" for the next year, given a dnssec-policy
named "mypolicy":
dnssec-ksr -i now -e +1y -k mypolicy -l named.conf keygen example.com
Creating a KSR for the same zone and period can be done with:
dnssec-ksr -i now -e +1y -k mypolicy -l named.conf request example.com > ksr.txt
Typically you would now transfer the KSR to the system that has
access to the KSK.
Signing the KSR created above can be done with:
dnssec-ksr -i now -e +1y -k kskpolicy -l named.conf -f ksr.txt sign example.com
Make sure that the DNSSEC parameters in kskpolicy match
those in mypolicy.
dnssec-keygen(8), dnssec-signzone(8), BIND 9
Administrator Reference Manual.
Internet Systems Consortium
2024, Internet Systems Consortium