Configure BIND 9

this section explains how to configure bind 9 to integrate with {{ch}} for storing keys used in signing zone files before proceeding, ensure that bind 9 is installed and configured according to your specific requirements generate a key to generate the keys, use pkcs11 tool from opensc https //github com/opensc/opensc the package is called opensc on both deb based and rpm based distributions install the opensc package on deb based distributions use on rpm based distributions use generate two rsa keys in {{ch}} by using pkcs11 tool the key signing key (ksk) and the zone signing key (zsk) the commands prompt for the user pin enter the identity password configured inside the \<crypto opr pass> tag in the fxpkcs11 cfg file each key must have a unique label because that label references the private key sudo pkcs11 tool module /usr/local/bin/fxpkcs11/libfxpkcs11 so login keypairgen key type rsa 2048 label "example com ksk" sudo 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 convert the rsa keys stored in {{ch}} into a format that bind 9 understands by using the dnssec keyfromlabel tool from bind 9, which links the raw keys stored in {{ch}} with k\<zone>+\<alg>+\<id> files that are generated when the command is run provide the following elements openssl engine name ( pkcs11 ) the algorithm ( rsasha256 ) the pkcs #11 label that specifies the token ( futurex ) the name of the pkcs #11 object (called label when generating the keys by using pkcs11 tool ) the hsm pin (the {{ch}} identity password configured inside the \<crypto opr pass> tag in the fxpkcs11 cfg file) the private key file is used for dnssec signing of the zone as if it were a conventional key on the file system (that is, one created with dnssec keygen ) the key material is stored in {{ch}} (and we cannot extract it), and the actual signing takes place on the {{ch}} ksk sudo dnssec keyfromlabel e pkcs11 a rsasha256 l "token=futurex;object=example com ksk;pin value=identity password" f ksk example com change the identity password value to the identity password configured inside the \<crypto opr pass> tag in the fxpkcs11 cfg file zsk sudo dnssec keyfromlabel e pkcs11 a rsasha256 l "token=futurex;object=example com zsk;pin value=identity password" example com change the identity password value to the identity password configured inside the \<crypto opr pass> tag in the fxpkcs11 cfg file confirm that you have one ksk and one zsk present in the current directory ls l k the output should look like this (the second number squence will be different) kexample com +008+31729 key kexample com +008+31729 private kexample com +008+42231 key kexample com +008+42231 private sign the zone 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 example shows the command syntax sudo dnssec signzone e pkcs11 s o \<zone name> \<zone file> the command could look like the following sample sudo dnssec signzone e pkcs11 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