mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-30 14:07:59 +00:00
Code Issues Releases Wiki Activity

Create dnssec policy wiki page

Matthijs Mekking
2019-09-02 06:15:36 -04:00
parent 5ccc2c1b3b
commit 4fd7f729f0
1 changed files with 71 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

71
DNSSEC-Key-and-Signing-Policy-(KASP).md Normal file

@@ -0,0 +1,71 @@
# 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.