Creating a DNSSEC Signing Policy - BlueCat Address Manager - 8.3.1

Address Manager Administration Guide

prodname
BlueCat Address Manager
version_custom
8.3.1

DNSSEC Signing Policies simplify administration by allowing you to configure DNSSEC settings in one place, and then apply the policy to forward and reverse zones. A DNSSEC Signing Policy contains all of the parameters needed to define the Key Signing Key and Zone Signing Key for a zone, including the settings for automatic key rollover.

Administrators can create and manage DNSSEC signing polices from the DNSSEC Policy Management link on the Administration tab. You can create multiple signing policies to create KSKs and ZSKs to meet the unique requirements for each zone, but a zone can only be linked to a single signing policy at any given time. If you need to configure a DNSSEC-HSM signing policy, refer to Creating a DNSSEC-HSM signing policy.

To create a DNSSEC 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.
  5. Under Zone Signing Key Policy, set the following parameters:
    • Algorithm—select an algorithm for the Zone Signing Key (ZSK):
      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: *These algorithms are only available if you select Address Manager as your key provider.
      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.
      • 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 only if you selected Thales HSM as your Key provider (option not available if you selected Address Manager as your Key Provider).
  6. Under Key Signing Key Policy, set the following parameters:
    • Algorithm—select an algorithm for the Key Signing Key (KSK):
      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: *These algorithms are only available if you select Address Manager as your key provider.
      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.
      • 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 only if you selected Thales HSM as your Key provider (option not available if you selected Address Manager as your Key Provider).
  7. Under Change Control, add comments, if required.
  8. Click Add.
With the DNSSEC signing policy defined, the next step is to assign the policy to a forward or reverse zone.