upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-06-08 22:32:07 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Design documentation 'dnssec-policy'

Browse source 
Initial design document.
This commit is contained in:
Matthijs Mekking 2019-09-02 15:51:10 +02:00
parent b7c5bfb203
commit 1fbd8bb1b3
2 changed files with 228 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

227
doc/design/dnssec-policy Normal file
View file

@ -0,0 +1,227 @@
Copyright (C) Internet Systems Consortium, Inc. ("ISC")
See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
# 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
# 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.
1. `auto-dnssec`: When setting a DNSSEC policy for a zone instead, the
behavior will be as if `auto-dnssec` was set to `maintain`.
1. `dnskey-sig-validity`: This option will be replaced in favor of the KASP
configuration value `signatures-validity-dnskey`.
1. `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").
1. `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.
1. `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.
1. `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.
1. `inline-signing`: When set to "yes", this option will sign transferred
unsigned zones, and unsigned zone from file. This is also no longer needed
when KASP is introduced because when setting a `dnssec-policy` for a
secondary zone or a zone with zone file, 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;
// Denial of existence
denial-type nsec3;
nsec3-param ttl 0 hash algorithm 1 iterations 5 optout;
nsec3-salt length 8 resalt P100D;
// Keys
dnskey-ttl 3600;
publish-safety PT3600S;
retire-safety PT3600S;
share-keys no;
purge-keys-after P14D;
keys {
ksk key-directory P5Y ECDSAP256SHA256;
zsk key-directory 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-registration-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
BIND 9.14 allows 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.
With BIND 9.14, 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 key-directory P5Y ECDSAP256SHA256;
zsk key-directory 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

1
util/copyrights
View file

@ -1499,6 +1499,7 @@
./doc/design/db_rules TXT.BRIEF 1999,2000,2001,2004,2016,2018,2019
./doc/design/decompression TXT.BRIEF 1999,2000,2001,2004,2016,2018,2019
./doc/design/dispatch TXT.BRIEF 2000,2001,2004,2016,2018,2019
./doc/design/dnssec-policy TXT.BRIEF 2019
./doc/design/dscp TXT.BRIEF 2013,2016,2018,2019
./doc/design/keydone TXT.BRIEF 2011,2016,2018,2019
./doc/design/logging TXT.BRIEF 1999,2000,2001,2004,2016,2018,2019