Procedural guide to validate and test BIND 9 integration with Vectera Plus HSM for zone signing.
This section explains how to test and validate that BIND 9 is integrated with the Vectera Plus HSM for the storage and signing of zone files. Before starting this section, install and configure BIND 9 per your specific requirements.
A zone file is a text file used by DNS servers like BIND to define the mappings between domain names and IP addresses for a specific DNS zone. It contains DNS records such as SOA, NS, A, and others that describe the structure and behavior of the domain.You copy and paste the following text into a file named db.example.com
None
$TTL 86400@ IN SOA ns1.example.com. admin.example.com. ( 2025073001 ; Serial 3600 ; Refresh 1800 ; Retry 604800 ; Expire 86400 ; Minimum ) IN NS ns1.example.com.ns1 IN A 192.0.2.1
Perform the following steps by using the pkcs11-tool available from the OpenSC (github.com/OpenSC/OpenSC) suite to generate keys. On both DEB-based and RPM-based distributions, the package is called opensc.
1
Generate the following RSA keys on the Vectera Plus by using pkcs11-tool: The KSK and the ZSK. When prompted for the user PIN, enter the password of the identity configured in the Futurex PKCS #11 file, fxpkcs11.cfg.
Each key must have a unique label because later commands use that label to reference the private key.
To convert the RSA keys stored in the HSM into a format that BIND 9 understands, use the dnssec-keyfromlabel tool from BIND 9. This process links the raw keys stored in the HSM with **K<zone>+<alg>+<id>
** files that the command generates.The required information is the PKCS #11 label that specifies the token (such as Futurex), the name of the PKCS #11 object (such as label when generating the keys with pkcs11-tool), and the HSM PIN.The private key file is used for DNSSEC signing of the zone as if it were a conventional key on the file system (such as one created with dnssec-keygen). The HSM stores the key material (which we cannot extract), and the actual signing takes place on the HSM.Run the following command to convert a KSK:
Shell
dnssec-keyfromlabel -a RSASHA256 -l "token=Futurex;object=example.com-ksk;pin-value=safest" -f KSK example.com
Run the following command to convert a ZSK:
Shell
dnssec-keyfromlabel -a RSASHA256 -l "token=Futurex;object=example.com-zsk;pin-value=safest" example.com
3
Run the following command to confirm that you have one KSK and one ZSK present in the current directory:
Shell
ls -l K*
The output should look similar to the following output (with different numbers):
The KSK, ZSK, and zone files must be present in the directory from which you run the command.
Use the following command syntax:
Shell
dnssec-signzone -S -o <zone name> <zone file>
For example, you might use the following command:
Shell
dnssec-signzone -S -o example.com db.example.com
If the command succeeds, the output looks similar to the following:
Shell
Fetching KSK 31729/RSASHA256 from key repository.Fetching ZSK 42231/RSASHA256 from key repository.Verifying the zone using the following algorithms: RSASHA256.Zone fully signed:Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 1 active, 0 stand-by, 0 revokeddb.example.com.signed
