From: Matthijs Mekking Date: Mon, 2 Sep 2019 13:51:10 +0000 (+0200) Subject: Design documentation 'dnssec-policy' X-Git-Tag: v9.15.6~26^2~40 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=1fbd8bb1b3c4a5607cad0d0bd655a764a1eb367a;p=thirdparty%2Fbind9.git Design documentation 'dnssec-policy' Initial design document. --- diff --git a/doc/design/dnssec-policy b/doc/design/dnssec-policy new file mode 100644 index 00000000000..2079c8edc27 --- /dev/null +++ b/doc/design/dnssec-policy @@ -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 diff --git a/util/copyrights b/util/copyrights index d10b5bcb559..31f059b23bb 100644 --- a/util/copyrights +++ b/util/copyrights @@ -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