DNSSEC Key and Signing Policy (KASP)

The configuration and administration of DNS Security Extensions (DNSSEC) can be cumbersome and error-prone. For each zone you'd like to sign, the IETF’s DNSSEC operational practices document (RFC 6781) recommends (but doesn’t require) two key pairs: a zone signing key (ZSK) which is a shorter key to lessen computational complexity and time for signing all of the zone resource record sets (RRSets). Typically a longer key, the key signing key (KSK) is used only to sign the DNSKEY RRSet, that is the RRSet that identifies the public keys, ZSKs and KSKs, used (or to be or have been used) within the zone.

The manual steps for performing this signing process entail creating the ZSK and KSK key pairs, each composed of a private key and a public key. The dnssec-keygen facility included with the BIND distribution can be used for this purpose. The public keys are then added to your zone as members of the DNSKEY RRSet. Then you can sign the zone using dnssec-signzone, another ISC-distributed utility. By signing a zone, the resource records within the zone are canonically ordered. Given that DNSSEC provides not only resource record authentication and data integrity verification, but also authenticated denial of existence (e.g., validated NXDOMAINs), the NSEC or NSEC3 resource records are inserted into the zone to close the gaps within the canonically ordered zone. These records enable verification that a given queried domain name was not provisioned in the zone. Finally, each RRSet is signed, and the corresponding signature for each RRSet is added to the zone in the form of RRSIG resource records.

A validating DNSSEC resolver receives not only the queried RRSet but the associated signature (RRSIG) and public zone keys (DNSKEY) to enable it to validate the signature on the resolved RRSet. The validating resolver must be configured with a trusted key or "trust anchor" to validate successfully. Thanks to the inherent domain tree, DNSSEC applies a chain of trust from the signed zone up to the DNS root zone such that a resolver possessing the root zone public key set can validate any RRSet linked within this chain of trust. This linkage comes in the form of Delegation Signer (DS) resource records in each parent zone, which verifies the child zone's DNSKEY RRSet. Periodically, keys need to be changed, like passwords, and this change process is referred to as a key rollover. Please feel free to reference my blog, video channel or books for more details on this process.

Having stated all that, the goal of DNSSEC policies in BIND 9.16 is automate much of this process by automating key generation, key rollover, and zone signing. Updating the parent zone's DS record when a zone's KSK is rolled over is still a manual process however. You can define the same signing policy for every zone, have a different policy per zone or a combination of these approaches. Note that even if the same policy is used across multiple zones, each zone still utilizes its own set of keys. However, when using views, each version of a given zone among different views uses the same set of keys.

BIND 9.16 DNSSEC Policy Declaration

These DNSSEC policy parameters are defined as follows.

• name - administrators can define a name for each policy. There are two pre-defined policies: none and default. Setting a zone's policy to none disables zone signing. Setting the policy to default causes the zone to be signed with a signle combined-signing key (CSK), which has an unlimited lifetime.
• dnskey-ttl - dictates the TTL to use for DNSSEC resource records; the default is one hour.
• keys - this statement sub-block specifies the algorithms and roles for automatically generated keys and zone signing. Thus administrators can define the algorithms, directories and lifetimes for each type of key used in the zone: KSK, ZSK and CSK which is a combined signing key, i.e., a KSK which signs all zone RRSets like a ZSK.
• max-zone-ttl - defines the maximum TTL permitted for the zone.
• nsec3param - sets the parameters of the NSEC3PARAM resource record, which defines the use of and settings for generating NSEC3 records within the zone.
• parent-ds-ttl - sets the TTL of the DS RRSet that the parent zone uses; the default is one day.
• parent-propagation-delay - the expected interval from the time the parent zone is updated to the time when this update is served by all of the parent zone name servers; the default is one hour.
• publish-safety - indicates the time interval between when keys are published in a zone and when they become active to increase the pre-publication interval. One hour is the default value.
• purge-keys - defines the time after which DNSSEC keys which have been removed from the zone can be deleted from disk. The default is 90 days.
• retire-safety - sets the margin added to the post-publication interval during key rollover, increasing the time a key remains published after it is no longer active; the default in 1 hour.
• signatures-refresh - dictates how frequently RRSIG records need to be refreshed. Each RRSIG defines a validity interval by start and end time; this parameter indicates when signatures may be refreshed when this close to expiring; the default is 5 days.
• signatures-validity - sets the RRSIG signature validity interval; the default is two weeks.
• signatures-validity-dnskey - sets the signature validity interval for the DNSKEY RRset; the default is two weeks.
• zone-propagation-delay - the expected interval from the time a primary zone is updated until all secondary zones are updated. The default is 5 minutes.