Bind 9 Configuration
This section explains the steps required to configure BIND 9 to integrate with the Vectera Plus HSM to store the keys used for zone file signing. Before starting this section, BIND 9 must already be installed and configured per your specific requirements.
For generating the keys, we are going to use pkcs11-tool available from the OpenSC suite. On both DEB-based and RPM-based distributions, the package is called opensc.
Generate two RSA keys on the Vectera Plus using pkcs11-tool. One will be the Key Signing Key (KSK) and one will be the Zone Signing Key (ZSK). The commands will prompt for the user PIN. Enter the password of the identity configured in the Futurex PKCS #11 file (i.e., fxpkcs11.cfg).
Each key must have a unique label because that label will be used to reference the private key.
The command output should look similar to the following:
The RSA keys stored in the HSM need to be converted into a format that BIND 9 understands. To do so, we will use the dnssec-keyfromlabel tool from BIND 9, which links the raw keys stored in the HSM with K<zone>+<alg>+<id> files that are generated when the command is run. We'll need to provide the OpenSSL engine name (pkcs11), the algorithm (RSASHA256), and the PKCS #11 label that specifies the token (i.e., Futurex), the name of the PKCS #11 object (called label when generating the keys using pkcs11-tool) and the HSM PIN.
The private key file will be used for DNSSEC signing of our zone as if it were a conventional key on the file system (i.e., one created with dnssec-keygen). The key material is stored on the HSM (and we cannot extract it), and the actual signing takes place on the HSM.
KSK:
ZSK:
Confirm that you have one KSK and one ZSK present in the current directory:
The output should look like this (the second number will be different):
The zone signing occurs per the regular process, with only one small difference. Again, we need to provide the name of the OpenSSL engine using the -E command line option.
The KSK, ZSK, and zone files must be present in the directory from which you are running the command.
The following command syntax should be used:
As an example, the command could look like this:
If the command is successful the output will look similar to the following:
When DNSSEC was first introduced, the only way to sign DNS data was using the dnssec-signzone utility; this would take an unsigned zone file and generate a new zone file containing signatures. This file would be loaded by named and served the same as any other zone file. Because DNSSEC signatures expire, the zone would have to be periodically resigned and reloaded.
Later, named acquired the ability to sign zones internally. The master server for a zone could now add and remove keys and generate and regenerate DNSSEC signatures automatically, remaining up-to-date without operator intervention. This required the zone to be configured as dynamic, however, which is incompatible with some existing DNS configurations, such as zones which are transferred from a provisioning database, are served from a master server not running BIND 9, or which need to be static.
With the release of BIND 9.9, ISC introduced a new "inline-signing" option for BIND 9, which allows named to sign zones completely transparently. A server can load or transfer an unsigned zone, and create a signed version of it which answers all queries and transfer requests, without altering the original unsigned version. As the unsigned zone is updated, named will detect the changes that are made to it, and apply those changes to the signed version. This allows a seamless transition to DNSSEC with minimal disruption to existing systems.
The purpose of this integration guide was to provide a basic example of how to configure BIND 9 to integrate with the Vectera Plus HSM for private key storage and signing of zone files. If you wish to implement Inline Signing in BIND, please refer to the following Inline Signing article on ISC's knowledgebase website.