mirror of
https://github.com/isc-projects/bind9.git
synced 2026-05-27 03:46:03 -04:00
7f43520893
Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Earlier commit deals with migration where existing keys match the policy. This commit deals with migration where existing keys do not match the policy. In that case, named must not immediately delete the existing keys, but gracefully roll to the dnssec-policy. However, named did remove the existing keys immediately. This is because the legacy key states were initialized badly. Because those keys had their states initialized to HIDDEN or RUMOURED, the keymgr decides that they can be removed (because only when the key has its states in OMNIPRESENT it can be used safely). The original thought to initialize key states to HIDDEN (and RUMOURED to deal with existing keys) was to ensure that those keys will go through the required propagation time before the keymgr decides they can be used safely. However, those keys are already in the zone for a long time and making the key states represent otherwise is dangerous: keys may be pulled out of the zone while in fact they are required to establish the chain of trust. Fix initializing key states for existing keys by looking more closely at the time metadata. Add TTL and propagation delays to the time metadata and see if the DNSSEC records have been propagated. Initialize the state to OMNIPRESENT if so, otherwise initialize to RUMOURED. If the time metadata is in the future, or does not exist, keep initializing the state to HIDDEN. The added test makes sure that new keys matching the policy are introduced, but existing keys are kept in the zone until the new keys have been propagated. |
||
|---|---|---|
| .. | ||
| bind9 | ||
| dns | ||
| irs | ||
| isc | ||
| isccc | ||
| isccfg | ||
| ns | ||
| samples | ||
| win32/bindevt | ||
| .gitignore | ||
| Kyuafile | ||
| Makefile.in | ||