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 ifauto-dnssec
was set tomaintain
. -
dnskey-sig-validity
: This option will be replaced in favor of the KASP configuration valuesignatures-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 ismaintain
and it is unclear how it is different fromauto-dnssec
. With KASP, the behavior will be as if thednssec-update-mode
was set tomaintain
. If you want DNSSEC maintenance to be done outsidenamed
, you should not configure adnssec-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 adnssec-policy
for a secondary zone this indicates thatinline-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 thednssec-policy
statement will override the existingmax-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 tosig-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)