... | ... | @@ -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. |
|
|
\ No newline at end of file |