|
|
# 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
|
|
|
|
|
|
# History
|
|
|
|
|
|
## 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 incoming
|
|
|
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. |