Creating a DNSSEC-HSM signing policy - BlueCat Address Manager - 8.2.0

Address Manager Administration Guide

prodname
BlueCat Address Manager
version_custom
8.2.0

This task describes how to create an DNSSEC-HSM signing policy.

Proceed with creating an DNSSEC-HSM signing policy only after you have completed the following:
  • Created an HSM configuration in Address Manager
  • Added HSM servers
  • Configured the Security World
  • Joined Address Manager to the Security World
  • Enabled HSM on managed BlueCat DNS Servers

An DNSSEC-HSM signing policy contains all of the parameters needed to define the Key Signing Key (KSK) and Zone Signing Key (ZSK) for a zone at the HSM server, including the settings for automatic key rollover.

Administrators can create and manage DNSSEC-HSM signing polices from Administration > DNSSEC Policy Management.
Note: You can create a single DNSSEC signing policy that can be assigned to multiple DNS zones, or you can create multiple DNSSEC signing policies and assign each signing policy to a specific DNS zone.

To create an DNSSEC-HSM signing policy:

  1. Select the Administration tab. Tabs remember the page you last worked on, so select the tab again to ensure you're on the Administration page.
  2. Under General, click DNSSEC Policy Management.
  3. Under DNSSEC Signing Policies, click New and select DNSSEC Signing policy.
  4. Under General, set the following parameters:
    • Policy Name—enter a name for the naming policy.
    • Signature Validity Period (days)—enter the number of days for which the RRSIG resource record is valid. The default period is 10 days.
    • Signature Re-Signing Interval (days)—enter the number of days before the end of the Signature Validity Period at which BIND resigns the zone. The default period is 2 days. For example, if the Signature Validity Period is 10 days and the Signature Re-Signing Interval is 2 days, BIND resigns the zone on day 8 of the Signature Validity Period.
    • Signature Digest Algorithm—indicates the algorithm used for the Delegation Signer (DS) record; select either SHA1 or SHA256 (recommended). This algorithm applies only when you generate a DS record.
    • Key Provider—select Thales HSM as your key provider.
  5. Under Zone Signing Key Policy, set the following parameters:
    • Algorithm—select an algorithm for DNSSEC-HSM zone signing:
      Algorithm Description Adds to zone
      RSASHA1 Uses RSA for authentication and SHA-1 for data integrity NSEC records
      DSA* Uses DSA for authentication and SHA-1 for data integrity NSEC records
      RSAMD5 Uses RSA for authentication and MD5 for data integrity NSEC records
      RSASHA1NSEC3SHA1 Uses RSA for authentication and SHA-1 for data integrity NSEC3 records
      DSANSEC3SHA1* Uses DSA for authentication and SHA-1 for data integrity NSEC3 records
      RSASHA256 Uses RSA for authentication and SHA-256 for data integrity NSEC records
      RSASHA512 Uses RSA for authentication and SHA-512 for data integrity NSEC records
      RSANSEC3SHA256 Uses RSA for authentication and SHA-256 for data integrity NSEC3 records
      RSANSEC3SHA512* Uses RSA for authentication and SHA-512 for data integrity NSEC3 records
      Note: The RSAMD5 algorithm is no longer recommended for generating DNSSEC keys. For more information, see RFC4641, RFC4034 and RFC3110. For more information on DNSSEC algorithms, see http://www.iana.org/assignments/dns-sec-alg-numbers
      Note: The Zone Signing Key and Key Signing Key must both use either NSEC or NSEC3 records. You cannot use NSEC for one key, and NSEC3 for the other key. You can used different algorithms for the ZSK and KSK, but the algorithms for each key must create the same type of resource record.

      For example, you can select RSASHA1 for the ZSK and DSA for the KSK. However, you cannot select RSASHA1 for the ZSK and DSANSEC3SHA1 for the KSK. Address Manager presents a warning if you select incompatible algorithms for the ZSK and KSK.

    • Length (bits)—select the length of the ZSK in bits (by default, 1024). The default value in this field changes depending on which algorithm you select.
    • Override TTL—select this check box to set a override the default Time-To-Live for the ZSK. A text field and drop-down menu open. Enter a value in the text field and select a unit of time from the drop-down menu.
      Note: The Override TTL for the ZSK must be the same as the Override TTL for the KSK.
    • Validity Period (days)—enter the number of days for which the ZSK is valid (by default, 30).
    • Overlap Interval (days)—enter the number of days before the end of the Validity Period at which a new key is generated for key rollover (by default, 7). For example, if the Validity Period (days) is 30 and the Overlap Interval (days) is 2, the new key is generated on day 28 of the ZSK’s validity period.
    • Rollover Method—select a method to make the new ZSK available when the key rolls over (by default, Pre-publish).
      • Pre-publish—publishes the new key at the beginning of the Overlap Interval to advertise the availability of the new key.
      • Double-signing—signs the zone and each resource record with both the existing key and the new key at the beginning of the Overlap Interval.
    • New Key Signing Interval (days)—enter the number of days before the end of the Validity Period that the resource records in the zone are signed by the new key and simultaneously unsigned by the old key (by default, 3). This parameter is only present when you select Pre-publish as the Rollover Method.
    • Protection Type—automatically set as module when choosing Thales HSM as your Key provider.
      Note: A password phrase is not required for module protection.
  6. Under Key Signing Key Policy, set the following parameters:
    • Algorithm—select the algorithm for DNSSEC-HSM zone signing:
      Algorithm Description Adds to zone
      RSASHA1 Uses RSA for authentication and SHA-1 for data integrity NSEC records
      DSA* Uses DSA for authentication and SHA-1 for data integrity NSEC records
      RSAMD5 Uses RSA for authentication and MD5 for data integrity NSEC records
      RSASHA1NSEC3SHA1 Uses RSA for authentication and SHA-1 for data integrity NSEC3 records
      DSANSEC3SHA1* Uses DSA for authentication and SHA-1 for data integrity NSEC3 records
      RSASHA256 Uses RSA for authentication and SHA-256 for data integrity NSEC records
      RSASHA512 Uses RSA for authentication and SHA-512 for data integrity NSEC records
      RSANSEC3SHA256 Uses RSA for authentication and SHA-256 for data integrity NSEC3 records
      RSANSEC3SHA512* Uses RSA for authentication and SHA-512 for data integrity NSEC3 records
      Note: The RSAMD5 algorithm is no longer recommended for generating DNSSEC keys. For more information, see RFC4641, RFC4034 and RFC3110. For more information on DNSSEC algorithms, see http://www.iana.org/assignments/dns-sec-alg-numbers
      Note: The Zone Signing Key and Key Signing Key must both use either NSEC or NSEC3 records. You cannot use NSEC for one key, and NSEC3 for the other key. You can used different algorithms for the ZSK and KSK, but the algorithms for each key must create the same type of resource record.

      For example, you can select RSASHA1 for the ZSK and DSA for the KSK. However, you cannot select RSASHA1 for the ZSK and DSANSEC3SHA1 for the KSK. Address Manager presents a warning if you select incompatible algorithms for the ZSK and KSK.

    • Length (bits)—select the length of the KSK, in bits (by default, 2048). The default value in this field changes depending on which algorithm you select.
    • Override TTL—select this check box to set a override the default Time-to-Live value for the KSK. A text field and drop-down list open. Enter a value in the text field and select a unit of time from the drop-down menu.
      Note: The Override TTL for the KSK must be the same as the Override TTL for the ZSK.
    • Validity Period (days)—enter the number of days for which the KSK is valid (by default, 360).
    • Overlap Interval (days)—enter the number of days before the end of the Validity Period at which a new key is generated for key rollover (by default, 14). For example, if the Validity Period (days) is 365 and the Overlap Interval (days) is 14, the new key is generated on day 351 of the KSK’s validity period.
    • Rollover Method—select a method to make the new KSK available when the key rolls over (by default, Double Signing).
      • Pre-publish—publishes the new key at the beginning of the Overlap Interval to advertise the availability of the new key.
      • Double-signing—signs the zone and each resource record with both the existing key and the new key at the beginning of the Overlap Interval.
    • New Key Signing Interval (days)—enter the number of days before the end of the KSK Validity Period that the resource records in the zone are signed using the new key and are simultaneously unsigned by the old key. This parameter is only present when you select Pre-publish as the KSK Rollover Method.
    • Protection Type—automatically set as module when choosing Thales HSM as your Key provider.
      Note: A password phrase is not required for module protection.
  7. Under Change Control, add comments, if required.
  8. Click Add.
With the DNSSEC-HSM policy defined, the next step is to assign the policy to a zone. For details, go to step 2 in Assigning the DNSSEC-HSM signing policy.