table of contents
DNSSEC-KEYFROMLABEL(8) | BIND9 | DNSSEC-KEYFROMLABEL(8) |
NAME¶
dnssec-keyfromlabel - DNSSEC key generation tool
SYNOPSIS¶
dnssec-keyfromlabel {-l label} [-3] [-a algorithm] [-A date/offset] [-c class] [-D date/offset] [-D sync date/offset] [-E engine] [-f flag] [-G] [-I date/offset] [-i interval] [-k] [-K directory] [-L ttl] [-n nametype] [-P date/offset] [-P sync date/offset] [-p protocol] [-R date/offset] [-S key] [-t type] [-v level] [-V] [-y] {name}
DESCRIPTION¶
dnssec-keyfromlabel generates a key pair of files that referencing a key object stored in a cryptographic hardware service module (HSM). The private key file can be used for DNSSEC signing of zone data as if it were a conventional signing key created by dnssec-keygen, but the key material is stored within the HSM, and the actual signing takes place there.
The name of the key is specified on the command line. This must match the name of the zone for which the key is being generated.
OPTIONS¶
-a algorithm
If no algorithm is specified, then RSASHA1 will be used by default, unless the -3 option is specified, in which case NSEC3RSASHA1 will be used instead. (If -3 is used and an algorithm is specified, that algorithm will be checked for compatibility with NSEC3.)
Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm, and DSA is recommended.
Note 2: DH automatically sets the -k flag.
-3
-E engine
When BIND is built with OpenSSL PKCS#11 support, this defaults to the string "pkcs11", which identifies an OpenSSL engine that can drive a cryptographic accelerator or hardware service module. When BIND is built with native PKCS#11 cryptography (--enable-native-pkcs11), it defaults to the path of the PKCS#11 provider library specified via "--with-pkcs11".
-l label
When BIND 9 is built with OpenSSL-based PKCS#11 support, the label is an arbitrary string that identifies a particular key.
When BIND 9 is built with native PKCS#11 support, the label is a PKCS#11 URI string in the format "pkcs11:keyword=value[;keyword=value;...]" Keywords include "token", which identifies the HSM; "object", which identifies the key; and "pin-source", which identifies a file from which the HSM's PIN code can be obtained. The label will be stored in the on-disk "private" file.
If the label contains a pin-source field, tools using the generated key files will be able to use the HSM for signing and other operations without any need for an operator to manually enter a PIN. Note: Making the HSM's PIN accessible in this manner may reduce the security advantage of using an HSM; be sure this is what you want to do before making use of this feature.
-n nametype
-C
-c class
-f flag
-G
-h
-K directory
-k
-L ttl
-p protocol
-S key
-t type
-v level
-V
-y
TIMING OPTIONS¶
Dates can be expressed in the format YYYYMMDD or YYYYMMDDHHMMSS. If the argument begins with a '+' or '-', it is interpreted as an offset from the present time. For convenience, if such an offset is followed by one of the suffixes 'y', 'mo', 'w', 'd', 'h', or 'mi', then the offset is computed in years (defined as 365 24-hour days, ignoring leap years), months (defined as 30 24-hour days), weeks, days, hours, or minutes, respectively. Without a suffix, the offset is computed in seconds. To explicitly prevent a date from being set, use 'none' or 'never'.
-P date/offset
-P sync date/offset
-A date/offset
-R date/offset
-I date/offset
-D date/offset
-D sync date/offset
-i interval
If the key is being created as an explicit successor to another key, then the default prepublication interval is 30 days; otherwise it is zero.
As with date offsets, if the argument is followed by one of the suffixes 'y', 'mo', 'w', 'd', 'h', or 'mi', then the interval is measured in years, months, weeks, days, hours, or minutes, respectively. Without a suffix, the interval is measured in seconds.
GENERATED KEY FILES¶
When dnssec-keyfromlabel completes successfully, it prints a string of the form Knnnn.+aaa+iiiii to the standard output. This is an identification string for the key files it has generated.
dnssec-keyfromlabel creates two files, with names based on the printed string. Knnnn.+aaa+iiiii.key contains the public key, and Knnnn.+aaa+iiiii.private contains the private key.
The .key file contains a DNS KEY record that can be inserted into a zone file (directly or with a $INCLUDE statement).
The .private file contains algorithm-specific fields. For obvious security reasons, this file does not have general read permission.
SEE ALSO¶
dnssec-keygen(8), dnssec-signzone(8), BIND 9 Administrator Reference Manual, RFC 4034, The PKCS#11 URI Scheme (draft-pechanec-pkcs11uri-13).
AUTHOR¶
Internet Systems Consortium, Inc.
COPYRIGHT¶
Copyright © 2008-2012, 2014-2021 Internet Systems Consortium, Inc. ("ISC")
August 27, 2015 | ISC |