DNSSEC Key and Signing Policy

A DNSSEC key and signing policy (KASP) defines a DNSSEC policy that can be applied to one or more zones.

For some background information, see:

https://www.ietf.org/archive/id/draft-mekking-dnsop-kasp-00.txt

Key manager

The key manager uses the "Flexible and Robust Key Rollover" to ensure DNSSEC correctness.

Flexible and Robust Key Rollover, SATIN 2012

History

DNSSEC in BIND 9

DNSSEC is first implemented in BIND 9. Many adaptations have been made since then. A lot of configuration knobs were added. One aim with introducing KASP configuration is that all these configuration options are grouped together, making the named configuration more intuitive when it comes to DNSSEC, and making it easier to turn on DNSSEC for zones. Instead of configuring many different options per zone, you would be able to do the following:

zone "example.com." {
    ...
    dnssec-policy "default";
};

Existing DNSSEC configuration options

Signing

The following configuration options exist nowadays for named to maintain DNSSEC signed zones. These will no longer work if an explicit DNSSEC policy is set for a zone.

auto-dnssec: When setting a DNSSEC policy for a zone instead, the behavior will be as if auto-dnssec was set to maintain.
dnskey-sig-validity: This option will be replaced in favor of the KASP configuration value signatures-validity-dnskey.
dnssec-dnskey-kskonly: This option will be removed and the key configuration from the policy will be used to determine what RRsets will be signed with which keys (Keys will have a role "KSK" and/or "ZSK").
dnssec-loadkeys-interval: This option will determine how the period that BIND 9 will check its key repository (default once per hour) to see if there are new keys added or if existing keys metadata has changed. This option might go away because the entity that performs DNSSEC maintenance knows exactly when the next step needs to happen. We can set the interval accordingly. This does mean that whenever a new key is added or deprecated manually, the interval needs to be set to now. Alternatively, we keep this option and only pick up new keys when at a certain interval.
dnssec-secure-to-insecure: This option allows a dynamic zone to transition from secure to insecure. This seems to be a safety check when named is not responsible for signing. This will likely go away because explicitly removing the dnssec-policy will be the same signal to (safely) make the zone insecure.
dnssec-update-mode: This option determines how DNSSEC signed dynamic zones are updated. Default is maintain and it is unclear how it is different from auto-dnssec. With KASP, the behavior will be as if the dnssec-update-mode was set to maintain. If you want DNSSEC maintenance to be done outside named, you should not configure a dnssec-policy for that zone.
inline-signing: When set to "yes", this option will sign incoming unsigned zones. This is also no longer needed when KASP is introduced because when setting a dnssec-policy for a secondary zone this indicates that inline-signing is desired.
max-zone-ttl: This will cap all TTLs in a zone file to the specified value. Although this option may be used for non-DNSSEC zones, it is really only useful for DNSSEC-signed zones because when performing key rollovers the timing depends on the largest TTL in the zone. The value set in the dnssec-policy statement will override the existing max-zone-ttl value.
sig-signing-nodes: This specifies the number of nodes to be examined in a quantum when signing a zone with a new DNSKEY. This presumable is to avoid keeping the database connection open for a long time. With the current database approach this probably needs to stay.
sig-signing-signatures: This specifies a threshold number of how many signatures will be generated in a quantum. Similar to sig-signing-nodes.
sig-signing-type: Internal record type number, used to track zone signing process. This likely will go away in favor of a new method.
sig-validity-interval: Specifies the number of days a signature is valid. The second optional value is the refresh interval. Thos option will be replaced by KASP configuration values "signatures-validity" and "signatures-refresh".
update-check-ksk: When set to "no", KSK will also sign non-DNSKEY RRsets. This option will go away and key roles will be used to determine what keys sign which RRsets (A KSK that should sign all RRsets will have both the KSK and ZSK role and is referred to as a CSK).

Other DNSSEC related configuration options that are not related to the policy are likely to stay:

key-directory: This is where the DNSKEY key files can be found.
serial-update-method: This is used for dynamic zones to determne how the SOA SERIAL should be updated. There will likely be a separate configuration option for the serial update method when resigning a zone.

KASP Configuration

The KASP Configuration may look something like the example configuration below. This does not include all options as described in the KASP draft, some options are not required, some options will be added in the future.

dnssec-policy "example" {

    // Signatures
    signatures-refresh P3D;
    signatures-validity P14D;
    signatures-validity-dnskey P14D;

    // Keys
    dnskey-ttl 3600;
    publish-safety PT3600S;
    retire-safety PT3600S;

    keys {
        ksk key-directory lifetime P5Y 13;
        zsk key-directory lifetime 30d 13;
        csk key-directory lifetime PT0S 8 2048;
    };

    // Zone properties
    zone-propagation-delay PT3600S;
    zone-max-ttl 24H;

    // Parent properties
    parent-propagation-delay PT24H;
    parent-registration-delay 1h;
    parent-ds-ttl 3600;
};

KASP design

dnssec-policy versus dnssec-keymgr

Key management in BIND 9 is currently implemented with a Python script called dnssec-keymgr. It uses the DNSSEC tools for manipulating DNSSEC key metadata.

With dnssec-policy configured in named.conf you no longer need to manually call dnssec-keymgr or the tools it wraps around, dnssec-keygen and dnssec-settime (although it is still possible to use them). The policy in named.conf will make named create keys when necessary and set the key timings accordingly.

Key roles

With BIND 9 you can sign your zones with a Zone Signing Key (ZSK) and a Key Signing Key (KSK). If you provide only one key, the zone will be signed with just one key (effectively acting as a Combined Signing Key (CSK). If one of the keys is offline, BIND 9 will temporarily change the key usage: A KSK may sign DNSKEY unrelated RRsets.

ZSKs by default sign the complete zone, except when dnssec-dnskey-kskonly and update-check-ksk are both set to yes.

KASP introduces key roles making key usage more explicit, without depending on state of the keys or additional configuration values. A key that has the KSK role will always sign only DNSKEY related RRsets, and a key with a ZSK role will always sign only DNSKEY unrelated RRsets. A key can have both roles, which is referred to as a CSK. Below is an example configuration for the three types of keys:

        keys {
                ksk hsm "softhsm" P5Y ECDSAP256SHA256;
                zsk directory "/etc/bind9/dnsseckeys/" P30D ECDSAP256SHA256;
                csk key-directory PT0S 8 2048;
        };

NSEC3

Currently if you want to sign your zone with NSEC3 you can do so by introducing an NSEC3PARAM record via Dynamic Update. This is no longer necessary with dnssec-policy as you can configure NSEC3 usage in named.conf (NOT IMPLEMENTED YET).

Changing policies

You can change a zone's policy by referring to a different dnssec-policy or by changing the dnssec-policy itself. After a reload of the configuration key timings may be adjusted. This may trigger a key rollover (for example if the key lifetimes have been shortened, or if other key properties have changed.

Key state machines

Rollover correctness are guaranteed by key state machines. See for more information:

https://nlnetlabs.nl/downloads/publications/satin2012-Schaeffer.pdf

Requirements

Configuration

You can configure DNSSEC for a zone with a single configuration option (dnssec-policy default).
You can configure DNSSEC for a zone manually (dnssec-policy statement).
No human interaction is needed, named will take care of key and signature management.

Key generation

1.A You can create keys in advance with dnssec-keygen 1.B When a zone with a DNSSEC policy set has no keys, named will create keys on the fly. 1.C A zone with a DNSSEC policy set that has keys configured that does not match the policy will have those keys become retired and a new set of keys will be selected or created. 1.D When the key is created, the key is in "Generated" state (no other key timings are set).

Key publication

1.A The first time the zone is signed, the zone will include all the necessary RRSIG and DNSKEY records. 1.B When a key is added to the zone, the zone is in "Published" state (The "published" key timing is set to now or a past time).

Key activation

1.A When the key is published long enough (publication interval has passed), the zone is also in "Active" state (Meaning "active" key timing is set). 1.B When a key is activated and has a lifetime configured, the "retired" key timing must be set to the "active" plus its lifetime. 1.C A key that has the KSK role will always sign DNSKEY related RRsets.

Key rollover

1.A A successor key must be created before the predecessor key will retire. 1.B A successor key will have its "Published" state set in the future (lifetime - publication interval).

Key retirement

1.A Keys that are retired will no longer be used to create new signatures, but existing signatures may be reused until they are close to expiring. 1.B Retired keys will have "retired" key timing set to now or a past time.

Key removal

1.A A key that has no signatures left in the zone, and the retire interval has passed are removed from the zone. 1.B A removed key has the "removed" key timing set to now or a past time.

Key purging

1.A Removed keys may be purged from storage. (NOT IMPLEMENTED YET)

GitLab