mirror of
https://gitlab.isc.org/isc-projects/bind9.git
synced 2025-04-18 09:44:09 +03:00
5893debf46
I've used the following command to remove the trailing whitespace for all tracked text files: git grep -Il '' | xargs sed -i 's/[ \t]*$//'
223 lines
8.4 KiB
Plaintext
223 lines
8.4 KiB
Plaintext
<!--
|
|
Copyright (C) Internet Systems Consortium, Inc. ("ISC")
|
|
|
|
SPDX-License-Identifier: MPL-2.0
|
|
|
|
This Source Code Form is subject to the terms of the Mozilla Public
|
|
License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
file, you can obtain one at https://mozilla.org/MPL/2.0/.
|
|
|
|
See the COPYRIGHT file distributed with this work for additional
|
|
information regarding copyright ownership.
|
|
-->
|
|
|
|
# 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. Those 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-refresh P3D;
|
|
signatures-validity P14D;
|
|
signatures-validity-dnskey P14D;
|
|
|
|
// Denial of existence (default NSEC)
|
|
nsec3param iterations 5 optout no salt "-";
|
|
nsec3-resalt P100D;
|
|
|
|
// Keys
|
|
dnskey-ttl 3600;
|
|
publish-safety PT3600S;
|
|
retire-safety PT3600S;
|
|
share-keys no;
|
|
purge-keys P90D;
|
|
|
|
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;
|
|
max-zone-ttl 24h;
|
|
|
|
// Parent properties
|
|
parent-propagation-delay PT24H;
|
|
parent-ds-ttl 3600;
|
|
parent-soa-ttl 3600;
|
|
parent-soa-minimum 3600;
|
|
};
|
|
```
|
|
|
|
# KASP design
|
|
|
|
## 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 lifetime unlimited algorithm ECDSAP256SHA256;
|
|
zsk key-directory lifetime P30D algorithm ECDSAP256SHA256;
|
|
csk key-directory lifetime P5Y algorithm 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
|