> ## Documentation Index
> Fetch the complete documentation index at: https://docs.futurex.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Validate and test

> Instructions to validate and test BIND 9 integration with CryptoHub for zone signing.

This section explains how to test and validate BIND 9 to integrate with CryptoHub for storing the keys used for zone file signing. Before starting this section, install and configure BIND 9 per your specific requirements.

## Prerequisites

You must create a zone file before testing can continue.

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.

Copy and paste the following text into a file named `db.example.com`.

```none expandable lines wrap title="None" theme={null}
$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**](https://github.com/OpenSC/OpenSC)) suite to generate keys. On both DEB-based and RPM-based distributions, the package is called**opensc**.

<Note>
  If you didn't change the PIN or password for the endpoint, you must copy the password from the `fxpkcs11.cfg` file when prompted after running these commands.
</Note>

<Steps>
  <Step>
    Generate the following RSA keys on the CryptoHub 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`.

    <Note>
      Each key must have a unique label because later commands use that label to reference the private key.
    </Note>

    ```shell expandable lines wrap title="Shell" theme={null}
    pkcs11-tool --module /usr/local/lib/fxpkcs11/libfxpkcs11.so --login --keypairgen --key-type rsa:2048 --label "example.com-ksk"
    ```

    ```shell expandable lines wrap title="Shell" theme={null}
    pkcs11-tool --module /usr/local/lib/fxpkcs11/libfxpkcs11.so --login --keypairgen --key-type rsa:1024 --label "example.com-zsk"
    ```

    <Check>
      The command output should look similar to the following:

      ```shell expandable lines wrap title="Shell" theme={null}
      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
      ```
    </Check>
  </Step>

  <Step>
    To convert the RSA keys stored in on CryptoHub 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 CryptoHub 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**). CryptoHub stores the key material (which we cannot extract), and the actual signing takes place on CryptoHub.

    Run the following command to convert a KSK:

    ```shell expandable lines wrap title="Shell" theme={null}
    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 expandable lines wrap title="Shell" theme={null}
    dnssec-keyfromlabel -a RSASHA256 -l "token=Futurex;object=example.com-zsk;pin-value=safest" example.com
    ```
  </Step>

  <Step>
    Run the following command to confirm that you have one KSK and one ZSK present in the current directory:

    ```shell expandable lines wrap title="Shell" theme={null}
    ls -l K*
    ```

    <Check>
      The output should look similar to the following output (with different numbers):

      ```shell expandable lines wrap title="Shell" theme={null}
      Kexample.com.+008+31729.key
      Kexample.com.+008+31729.private
      Kexample.com.+008+42231.key
      Kexample.com.+008+42231.private
      ```
    </Check>
  </Step>
</Steps>

## Sign the zone

<Note>
  The KSK, ZSK, and zone files must be present in the directory from which you run the command.
</Note>

<Note>
  Before signing, export the following environment variables so that BIND tools can access the HSM:

  ```shell expandable lines wrap title="Shell" theme={null}
  export PKCS11_MODULE=/usr/local/lib/fxpkcs11/libfxpkcs11.so
  export PKCS11_PIN='your-hsm-pin'
  ```

  Replace `your-hsm-pin` with the PIN from your `fxpkcs11.cfg` file.
</Note>

Use the following command syntax:

```shell expandable lines wrap title="Shell" theme={null}
dnssec-signzone -S -o <zone name> <zone file>
```

For example, you might use the following command:

```shell expandable lines wrap title="Shell" theme={null}
dnssec-signzone -S -o example.com db.example.com
```

<Check>
  If the command succeeds, the output looks similar to the following:

  ```shell expandable lines wrap title="Shell" theme={null}
  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
  ```

  The following example shows a successful example directory layout:

  ```Plaintext wrap theme={null}
  test\_bind/
    \|--- db.example.com
    \|--- db.example.com.signed
    \|--- dsset-example.com
    \|--- Kexample.com.+008+31729.key
    \|--- Kexample.com.+008+31729.private
    \|--- Kexample.com.+008+42231.key
    \|--- Kexample.com.+008+42231.private
  ```
</Check>