Validate and test

this section explains how to test and validate that bind 9 is integrated with the {{vectera}} hsm for the storage and signing of zone files before starting this section, install and configure bind 9 per your specific requirements prerequisites you must create a zone file before testing can continue zone file 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 $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 generate keys 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 generate the following rsa keys on the {{vectera}} 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 pkcs11 tool module /usr/local/bin/fxpkcs11/libfxpkcs11 so login keypairgen key type rsa 2048 label "example com ksk"pkcs11 tool module /usr/local/bin/fxpkcs11/libfxpkcs11 so login keypairgen key type rsa 1024 label "example com zsk" the command output should look similar to the following key pair generated private key object; rsa label example com ksk usage decrypt, sign, unwrap public key object; rsa 2048 bits label example com ksk usage encrypt, verify, wrap 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 t he 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 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 dnssec keyfromlabel a rsasha256 l "token=futurex;object=example com zsk;pin value=safest" example com run the following command to confirm that you have one ksk and one zsk present in the current directory ls l k the output should look similar to the following output (with different numbers) kexample com +008+31729 key kexample com +008+31729 private kexample com +008+42231 key kexample com +008+42231 private sign the zone the ksk, zsk, and zone files must be present in the directory from which you run the command use the following command syntax dnssec signzone s o \<zone name> \<zone file> for example, you might use the following command dnssec signzone s o example com db example com if the command succeeds, the output looks similar to the following 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 revoked db example com signed successful example directory layout