mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-31 14:35:26 +00:00
Code Issues Releases Wiki Activity

Update DNSSEC Key and Signing Policy (KASP)

Matthijs Mekking
2019-09-02 06:43:50 -04:00
parent 4fd7f729f0
commit fc833cab73
1 changed files with 206 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

206
DNSSEC-Key-and-Signing-Policy-(KASP).md

@@ -69,3 +69,209 @@ is set for a zone.
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.
1. `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.
1. `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.
1. `sig-signing-signatures`: This specifies a threshold number of how many
signatures will be generated in a quantum. Similar to `sig-signing-nodes`.
1. `sig-signing-type`: Internal record type number, used to track zone
signing process. This likely will go away in favor of a new method.
1. `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".
1. `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:
1. `key-directory`: This is where the DNSKEY key files can be found.
1. `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 includes all options as described in the KASP draft, but we may
decide that some options are not required.
```
dnssec-policy "nsec3" {
description "policy for zones that require zone walking mitigation";
// Signatures
signatures-resign PT2H;
signatures-refresh P3D;
signatures-validity P14D;
signatures-validity-dnskey P14D;
signatures-validity-denial P7D;
signatures-jitter PT12H;
signatures-inception-offset PT300S;
// Denial of existence
denial-type nsec3;
nsec3param-ttl 0;
nsec3-optout no;
nsec3-hash-algorithm 1;
nsec3-hash-iterations 5;
nsec3-salt-length 8;
nsec3-resalt P100D;
// Keys
dnskey-ttl 3600;
dnskey-publish-safety PT3600S;
dnskey-retire-safety PT3600S;
share-keys no;
purge-keys-after P14D;
keys {
ksk hsm "softhsm" P5Y ECDSAP256SHA256;
zsk directory "/etc/bind9/dnsseckeys/" P30D ECDSAP256SHA256;
csk key-directory PT0S 8 2048;
};
// Parent synchronization
cds yes;
cdnskey yes;
check-ds { 127.0.0.53; };
check-ds-interval PT3600S;
// Zone properties
zone-propagation-delay PT3600S;
zone-soa-ttl 3600;
zone-soa-minimum 3600;
zone-soa-serial-update-method unixtime;
zone-max-ttl 24H;
// Parent properties
parent-propagation-delay PT24H;
parent-ds-ttl 3600;
parent-soa-ttl 3600;
parent-soa-minimum 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`.
## 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
1. You can configure DNSSEC for a zone with a single configuration option (`dnssec-policy _default`).
1. You can configure DNSSEC for a zone manually (`dnssec-policy` statement).
1. 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.