Creating a DNSSEC signing policy - BlueCat Address Manager - 9.4.0

Address Manager Administration Guide

Locale
English (United States)
Product name
BlueCat Address Manager
Version
9.4.0

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. The DNSSEC Policy Management page opens.
  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, SHA256 (recommended), or SHA384. 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):
      Note:
      • The RSASHA1, RSAMD5, DSA, and DSANSEC3SHA1 algorithms are not supported in DNS/DHCP Server versions 9.2.2 or higher, due to the BIND version being upgraded for 9.2.2+. You can continue using these algorithms with DNS/DHCP Server v9.2.0/9.2.1 and v9.1.0/9.1.1. However, BlueCat recommends changing the DNSSEC policies to use other algorithms that are supported in v9.2.2+ to facilitate future upgrades.
      • If you are using the DNSSEC-HSM configuration, BlueCat recommends using the RSA algorithm.
      Algorithm Description Adds to zone DNS/DHCP Server versions supported
      RSASHA1 Uses RSA for authentication and SHA-1 for data integrity NSEC records DNS/DHCP Server v9.2.1 and lower (not supported in 9.2.2+)
      DSA* Uses DSA for authentication and SHA-1 for data integrity NSEC records DNS/DHCP Server v9.2.1 and lower (not supported in 9.2.2+)
      RSAMD5 Uses RSA for authentication and MD5 for data integrity NSEC records DNS/DHCP Server v9.2.1 and lower (not supported in 9.2.2+)
      RSASHA1NSEC3SHA1 Uses RSA for authentication and SHA-1 for data integrity NSEC3 records All versions of DNS/DHCP Server
      DSANSEC3SHA1* Uses DSA for authentication and SHA-1 for data integrity NSEC3 records DNS/DHCP Server v9.2.1 and lower (not supported in 9.2.2+)
      RSASHA256 Uses RSA for authentication and SHA-256 for data integrity NSEC records All versions of DNS/DHCP Server
      RSASHA512 Uses RSA for authentication and SHA-512 for data integrity NSEC records All versions of DNS/DHCP Server
      RSANSEC3SHA256 Uses RSA for authentication and SHA-256 for data integrity NSEC3 records All versions of DNS/DHCP Server
      RSANSEC3SHA512 Uses RSA for authentication and SHA-512 for data integrity NSEC3 records All versions of DNS/DHCP Server
      ECDSAP256SHA256* Uses ECDSA algorithms with P256 curve for authentication and SHA-256 for data integrity NSEC records DNS/DHCP Server v9.3.0 and higher
      ECDSAP384SHA384* Uses ECDSA algorithms with P356 curve for authentication and SHA-384 for data integrity NSEC records DNS/DHCP Server v9.3.0 and higher
      ED25519* Uses EdDSA algorithm with Ed25519 curve for authentication and SHA-512 signatures for data integrity NSEC records DNS/DHCP Server v9.3.0 and higher
      ED448* Uses EdDSA algorithm with Ed448 curve for authentication and SHAKE-256 signatures for data integrity NSEC records DNS/DHCP Server v9.3.0 and higher
      Note: *These algorithms are only available if you select Address Manager as your key provider.
      Warning: Support for EdDSA algorithms is not as widespread as ECDSA currently. If publishing with EdDSA, some users may lose the benefit of DNSSEC, as recursive resolvers that do not recognize EdDSA algorithms will treat the DNS response as unsigned. ECDSA algorithms are recommended to ensure a broader level of support across current DNS infrastructure.
      Note: The RSAMD5 algorithm is no longer recommended for generating DNSSEC keys. For more information, refer to RFC4641, RFC4034 and RFC3110. For more information on DNSSEC algorithms, refer to 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 can't 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 can't 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 Entrust HSM as your Key provider (option not available if you selected Address Manager as your Key Provider).
  6. Under Change Control, add comments, if required.
  7. Click Add.
With the DNSSEC signing policy defined, the next step is to assign the policy to a forward or reverse zone.