mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-22 18:19:42 +00:00
Code Issues Releases Wiki Activity
bind/lib/dns/keymgr.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

2868 lines
82 KiB
C
Raw Normal View History

Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/*
* Copyright (C) Internet Systems Consortium, Inc. ("ISC")
*
* SPDX-License-Identifier: MPL-2.0
Update the copyright information in all files in the repository This commit converts the license handling to adhere to the REUSE specification. It specifically: 1. Adds used licnses to LICENSES/ directory 2. Add "isc" template for adding the copyright boilerplate 3. Changes all source files to include copyright and SPDX license header, this includes all the C sources, documentation, zone files, configuration files. There are notes in the doc/dev/copyrights file on how to add correct headers to the new files. 4. Handle the rest that can't be modified via .reuse/dep5 file. The binary (or otherwise unmodifiable) files could have license places next to them in <foo>.license file, but this would lead to cluttered repository and most of the files handled in the .reuse/dep5 file are system test files.
2021-06-03 08:37:05 +02:00
*
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
* 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.
*/
/*! \file */
#include <inttypes.h>
#include <stdbool.h>
#include <stdlib.h>
Purge keys implementation On each keymgr run, we now also check if key files can be removed. The 'purge-keys' interval determines how long keys should be retained after they have become completely hidden. Key files should not be removed if it has a state that is set to something else then HIDDEN, if purge-keys is 0 (disabled), if the key goal is set to OMNIPRESENT, or if the key is unused (a key is unused if no timing metadata set, and no states are set or if set, they are set to HIDDEN). If the last changed timing metadata plus the purge-keys interval is in the past, the key files may be removed. Add a dst_key_t variable 'purge' to signal that the key file should not be written to file again.
2021-02-08 15:15:57 +01:00
#include <unistd.h>
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
#include <isc/buffer.h>
#include <isc/dir.h>
Convert all categories and modules into static lists Remove the complicated mechanism that could be (in theory) used by external libraries to register new categories and modules with statically defined lists in <isc/log.h>. This is similar to what we have done for <isc/result.h> result codes. All the libraries are now internal to BIND 9, so we don't need to provide a mechanism to register extra categories and modules.
2024-08-14 13:25:50 +02:00
#include <isc/log.h>
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
#include <isc/mem.h>
Make isc_result a static enum Remove the dynamic registration of result codes. Convert isc_result_t from unsigned + #defines into 32-bit enum type in grand unified <isc/result.h> header. Keep the existing values of the result codes even at the expense of the description and identifier tables being unnecessary large. Additionally, add couple of: switch (result) { [...] default: break; } statements where compiler now complains about missing enum values in the switch statement.
2021-10-04 17:14:53 +02:00
#include <isc/result.h>
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
#include <isc/string.h>
Create private keys with PKCS#11 object If there is a keystore configured with a PKCS#11 URI, zones that are using a dnssec-policy that uses such a keystore should create keys via the PKCS#11 interface. Those keys are generally stored inside an HSM. Some changes to the code are required, to store the engine reference into the keystore.
2022-02-28 11:50:43 +01:00
#include <isc/time.h>
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
#include <isc/util.h>
#include <dns/dnssec.h>
#include <dns/kasp.h>
#include <dns/keymgr.h>
#include <dns/keyvalues.h>
#include <dst/dst.h>
#define RETERR(x) \
do { \
result = (x); \
if (result != ISC_R_SUCCESS) \
goto failure; \
} while (0)
/*
Address Coverity warnings in keymgr.c Coverity showed that the return value of `dst_key_gettime` was unchecked in INITIALIZE_STATE. If DST_TIME_CREATED was not set we would set the state to be initialized to a weird last changed time. This would normally not happen because DST_TIME_CREATED is always set. However, we would rather set the time to now (as the comment also indicates) not match the creation time. The comment on INITIALIZE_STATE also needs updating as we no longer always initialize to HIDDEN.
2020-04-06 09:59:18 +02:00
* Set key state to `target` state and change last changed
* to `time`, only if key state has not been set before.
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
*/
Add key state init debugging When debugging an issue it can be useful to see what BIND initially set the key states to.
2023-01-06 12:39:10 +01:00
#define INITIALIZE_STATE(key, state, timing, target, time) \
do { \
dst_key_state_t s; \
char keystr[DST_KEY_FORMATSIZE]; \
if (dst_key_getstate((key), (state), &s) == ISC_R_NOTFOUND) { \
dst_key_setstate((key), (state), (target)); \
dst_key_settime((key), (timing), time); \
\
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
if (isc_log_wouldlog(ISC_LOG_DEBUG(1))) { \
Add key state init debugging When debugging an issue it can be useful to see what BIND initially set the key states to.
2023-01-06 12:39:10 +01:00
dst_key_format((key), keystr, sizeof(keystr)); \
isc_log_write( \
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
DNS_LOGCATEGORY_DNSSEC, \
Add key state init debugging When debugging an issue it can be useful to see what BIND initially set the key states to.
2023-01-06 12:39:10 +01:00
DNS_LOGMODULE_DNSSEC, \
ISC_LOG_DEBUG(3), \
"keymgr: DNSKEY %s (%s) initialize " \
"%s state to %s (policy %s)", \
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
keystr, keymgr_keyrole(key), \
Add key state init debugging When debugging an issue it can be useful to see what BIND initially set the key states to.
2023-01-06 12:39:10 +01:00
keystatetags[state], \
keystatestrings[target], \
dns_kasp_getname(kasp)); \
} \
} \
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
} while (0)
/* Shorter keywords for better readability. */
#define HIDDEN DST_KEY_STATE_HIDDEN
#define RUMOURED DST_KEY_STATE_RUMOURED
#define OMNIPRESENT DST_KEY_STATE_OMNIPRESENT
#define UNRETENTIVE DST_KEY_STATE_UNRETENTIVE
#define NA DST_KEY_STATE_NA
/* Quickly get key state timing metadata. */
#define NUM_KEYSTATES (DST_MAX_KEYSTATES)
static int keystatetimes[NUM_KEYSTATES] = { DST_TIME_DNSKEY, DST_TIME_ZRRSIG,
DST_TIME_KRRSIG, DST_TIME_DS };
/* Readable key state types and values. */
static const char *keystatetags[NUM_KEYSTATES] = { "DNSKEY", "ZRRSIG", "KRRSIG",
"DS" };
static const char *keystatestrings[4] = { "HIDDEN", "RUMOURED", "OMNIPRESENT",
"UNRETENTIVE" };
Log key calculation overflows
2024-06-26 14:49:51 +10:00
static void
log_key_overflow(dst_key_t *key, const char *what) {
char keystr[DST_KEY_FORMATSIZE];
dst_key_format(key, keystr, sizeof(keystr));
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(
DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC, ISC_LOG_WARNING,
"keymgr: DNSKEY %s (%s) calculation overflowed", keystr, what);
Log key calculation overflows
2024-06-26 14:49:51 +10:00
}
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/*
* Print key role.
*
*/
static const char *
keymgr_keyrole(dst_key_t *key) {
Check return value of dst_key_getbool() Fix Coverity CHECKED_RETURN reports for dst_key_getbool(). In most cases we do not really care about its return value, but it is prudent to check it. In one case, where a dst_key_getbool() error should be treated identically as success, cast the return value to void and add a relevant comment.
2020-07-06 12:07:24 +02:00
bool ksk = false, zsk = false;
isc_result_t ret;
ret = dst_key_getbool(key, DST_BOOL_KSK, &ksk);
if (ret != ISC_R_SUCCESS) {
return "UNKNOWN";
}
ret = dst_key_getbool(key, DST_BOOL_ZSK, &zsk);
if (ret != ISC_R_SUCCESS) {
return "UNKNOWN";
}
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
if (ksk && zsk) {
return "CSK";
} else if (ksk) {
return "KSK";
keymgr_keyrole couldn't emit "NOSIGN". 92 } else { 93 return ("ZSK"); 94 } CID 1455900 (#1 of 1): Structurally dead code (UNREACHABLE) unreachable: This code cannot be reached: return "NOSIGN";. 95 return ("NOSIGN");
2020-02-05 16:04:09 +11:00
} else if (zsk) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
return "ZSK";
}
return "NOSIGN";
}
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
/*
* Set the remove time on key given its retire time.
*
*/
static void
keymgr_settime_remove(dns_dnsseckey_t *key, dns_kasp_t *kasp) {
isc_stdtime_t retire = 0, remove = 0, ksk_remove = 0, zsk_remove = 0;
bool zsk = false, ksk = false;
isc_result_t ret;
REQUIRE(key != NULL);
REQUIRE(key->key != NULL);
ret = dst_key_gettime(key->key, DST_TIME_INACTIVE, &retire);
if (ret != ISC_R_SUCCESS) {
return;
}
ret = dst_key_getbool(key->key, DST_BOOL_ZSK, &zsk);
if (ret == ISC_R_SUCCESS && zsk) {
Ignore max-zone-ttl on dnssec-policy insecure Allow larger TTL values in zones that go insecure. This is necessary because otherwise the zone will not be loaded due to the max-zone-ttl of P1D that is part of the current insecure policy. In the keymgr.c code, default back to P1D if the max-zone-ttl is set to zero.
2023-07-26 11:50:57 +02:00
dns_ttl_t ttlsig = dns_kasp_zonemaxttl(kasp, true);
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
/* ZSK: Iret = Dsgn + Dprp + TTLsig */
Ignore max-zone-ttl on dnssec-policy insecure Allow larger TTL values in zones that go insecure. This is necessary because otherwise the zone will not be loaded due to the max-zone-ttl of P1D that is part of the current insecure policy. In the keymgr.c code, default back to P1D if the max-zone-ttl is set to zero.
2023-07-26 11:50:57 +02:00
zsk_remove =
retire + ttlsig + dns_kasp_zonepropagationdelay(kasp) +
dns_kasp_retiresafety(kasp) + dns_kasp_signdelay(kasp);
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
}
ret = dst_key_getbool(key->key, DST_BOOL_KSK, &ksk);
if (ret == ISC_R_SUCCESS && ksk) {
/* KSK: Iret = DprpP + TTLds */
ksk_remove = retire + dns_kasp_dsttl(kasp) +
dns_kasp_parentpropagationdelay(kasp) +
dns_kasp_retiresafety(kasp);
}
Test keytimes on CSK rollover This improves keytime testing on CSK rollover. It now tests for specific times, and also tests for SyncPublish and Removed keytimes. Since an "active key" for ZSK and KSK means something different, this makes it tricky to decide when a CSK is active. An "active key" intuitively means the key is signing so we say a CSK is active when it is creating zone signatures. This change means a lot of timings for the CSK rollover tests need to be adjusted. The keymgr code needs a slight change on calculating the prepublication time: For a KSK we need to include the parent registration delay, but for CSK we look at the zone signing property and stick with the ZSK prepublication calculation.
2020-05-11 15:12:32 +02:00
Nit changes in keymgr and kasp Use the ISC_MAX define instead of "x = a > b ? a : b" paradigm. Remove an unneeded include.
2022-06-21 12:45:54 +02:00
remove = ISC_MAX(ksk_remove, zsk_remove);
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
dst_key_settime(key->key, DST_TIME_DELETE, remove);
}
/*
Nit changes in keymgr and kasp Use the ISC_MAX define instead of "x = a > b ? a : b" paradigm. Remove an unneeded include.
2022-06-21 12:45:54 +02:00
* Set the SyncPublish time (when the DS may be submitted to the parent).
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
*
*/
dnssec-ksr keygen -o to create KSKs Add an option to dnssec-ksr keygen, -o, to create KSKs instead of ZSKs. This way, we can create a set of KSKS for a given period too. For KSKs we also need to set timing metadata, including "SyncPublish" and "SyncDelete". This functionality already exists in keymgr.c so let's make the function accessible. Replace dnssec-keygen calls with dnssec-ksr keygen for KSK in the ksr system test and check keys for created KSKs as well. This requires a slight modification of the check_keys function to take into account KSK timings and metadata.
2024-09-03 17:24:22 +02:00
void
dns_keymgr_settime_syncpublish(dst_key_t *key, dns_kasp_t *kasp, bool first) {
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
isc_stdtime_t published, syncpublish;
bool ksk = false;
isc_result_t ret;
REQUIRE(key != NULL);
dnssec-ksr keygen -o to create KSKs Add an option to dnssec-ksr keygen, -o, to create KSKs instead of ZSKs. This way, we can create a set of KSKS for a given period too. For KSKs we also need to set timing metadata, including "SyncPublish" and "SyncDelete". This functionality already exists in keymgr.c so let's make the function accessible. Replace dnssec-keygen calls with dnssec-ksr keygen for KSK in the ksr system test and check keys for created KSKs as well. This requires a slight modification of the check_keys function to take into account KSK timings and metadata.
2024-09-03 17:24:22 +02:00
ret = dst_key_gettime(key, DST_TIME_PUBLISH, &published);
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
if (ret != ISC_R_SUCCESS) {
return;
}
dnssec-ksr keygen -o to create KSKs Add an option to dnssec-ksr keygen, -o, to create KSKs instead of ZSKs. This way, we can create a set of KSKS for a given period too. For KSKs we also need to set timing metadata, including "SyncPublish" and "SyncDelete". This functionality already exists in keymgr.c so let's make the function accessible. Replace dnssec-keygen calls with dnssec-ksr keygen for KSK in the ksr system test and check keys for created KSKs as well. This requires a slight modification of the check_keys function to take into account KSK timings and metadata.
2024-09-03 17:24:22 +02:00
ret = dst_key_getbool(key, DST_BOOL_KSK, &ksk);
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
if (ret != ISC_R_SUCCESS || !ksk) {
return;
}
dnssec-ksr keygen -o to create KSKs Add an option to dnssec-ksr keygen, -o, to create KSKs instead of ZSKs. This way, we can create a set of KSKS for a given period too. For KSKs we also need to set timing metadata, including "SyncPublish" and "SyncDelete". This functionality already exists in keymgr.c so let's make the function accessible. Replace dnssec-keygen calls with dnssec-ksr keygen for KSK in the ksr system test and check keys for created KSKs as well. This requires a slight modification of the check_keys function to take into account KSK timings and metadata.
2024-09-03 17:24:22 +02:00
syncpublish = published + dst_key_getttl(key) +
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
dns_kasp_zonepropagationdelay(kasp) +
dns_kasp_publishsafety(kasp);
if (first) {
/* Also need to wait until the signatures are omnipresent. */
isc_stdtime_t zrrsig_present;
Ignore max-zone-ttl on dnssec-policy insecure Allow larger TTL values in zones that go insecure. This is necessary because otherwise the zone will not be loaded due to the max-zone-ttl of P1D that is part of the current insecure policy. In the keymgr.c code, default back to P1D if the max-zone-ttl is set to zero.
2023-07-26 11:50:57 +02:00
dns_ttl_t ttlsig = dns_kasp_zonemaxttl(kasp, true);
zrrsig_present = published + ttlsig +
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
dns_kasp_zonepropagationdelay(kasp) +
dns_kasp_publishsafety(kasp);
if (zrrsig_present > syncpublish) {
syncpublish = zrrsig_present;
}
}
dnssec-ksr keygen -o to create KSKs Add an option to dnssec-ksr keygen, -o, to create KSKs instead of ZSKs. This way, we can create a set of KSKS for a given period too. For KSKs we also need to set timing metadata, including "SyncPublish" and "SyncDelete". This functionality already exists in keymgr.c so let's make the function accessible. Replace dnssec-keygen calls with dnssec-ksr keygen for KSK in the ksr system test and check keys for created KSKs as well. This requires a slight modification of the check_keys function to take into account KSK timings and metadata.
2024-09-03 17:24:22 +02:00
dst_key_settime(key, DST_TIME_SYNCPUBLISH, syncpublish);
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
}
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/*
* Calculate prepublication time of a successor key of 'key'.
* This function can have side effects:
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
* 1. If there is no active time set, which would be super weird, set it now.
* 2. If there is no published time set, also super weird, set it now.
Set SyncPublish on keys Set the SyncPublish metadata on keys that don't have them yet.
2020-04-30 13:22:23 +02:00
* 3. If there is no syncpublished time set, set it now.
* 4. If the lifetime is not set, it will be set now.
* 5. If there should be a retire time and it is not set, it will be set now.
* 6. The removed time is adjusted accordingly.
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
*
* This returns when the successor key needs to be published in the zone.
* A special value of 0 means there is no need for a successor.
*
*/
static isc_stdtime_t
keymgr_prepublication_time(dns_dnsseckey_t *key, dns_kasp_t *kasp,
uint32_t lifetime, isc_stdtime_t now) {
isc_result_t ret;
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
isc_stdtime_t active, retire, pub, prepub;
Test keytimes on CSK rollover This improves keytime testing on CSK rollover. It now tests for specific times, and also tests for SyncPublish and Removed keytimes. Since an "active key" for ZSK and KSK means something different, this makes it tricky to decide when a CSK is active. An "active key" intuitively means the key is signing so we say a CSK is active when it is creating zone signatures. This change means a lot of timings for the CSK rollover tests need to be adjusted. The keymgr code needs a slight change on calculating the prepublication time: For a KSK we need to include the parent registration delay, but for CSK we look at the zone signing property and stick with the ZSK prepublication calculation.
2020-05-11 15:12:32 +02:00
bool zsk = false, ksk = false;
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
REQUIRE(key != NULL);
REQUIRE(key->key != NULL);
active = 0;
Set SyncPublish on keys Set the SyncPublish metadata on keys that don't have them yet.
2020-04-30 13:22:23 +02:00
pub = 0;
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
retire = 0;
Set SyncPublish on keys Set the SyncPublish metadata on keys that don't have them yet.
2020-04-30 13:22:23 +02:00
/*
* An active key must have publish and activate timing
* metadata.
*/
ret = dst_key_gettime(key->key, DST_TIME_ACTIVATE, &active);
if (ret != ISC_R_SUCCESS) {
/* Super weird, but if it happens, set it to now. */
dst_key_settime(key->key, DST_TIME_ACTIVATE, now);
active = now;
}
ret = dst_key_gettime(key->key, DST_TIME_PUBLISH, &pub);
if (ret != ISC_R_SUCCESS) {
/* Super weird, but if it happens, set it to now. */
dst_key_settime(key->key, DST_TIME_PUBLISH, now);
pub = now;
}
/*
* Calculate prepublication time.
*/
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
prepub = dst_key_getttl(key->key) + dns_kasp_publishsafety(kasp) +
dns_kasp_zonepropagationdelay(kasp);
ret = dst_key_getbool(key->key, DST_BOOL_KSK, &ksk);
if (ret == ISC_R_SUCCESS && ksk) {
Set SyncPublish on keys Set the SyncPublish metadata on keys that don't have them yet.
2020-04-30 13:22:23 +02:00
isc_stdtime_t syncpub;
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/*
Set SyncPublish on keys Set the SyncPublish metadata on keys that don't have them yet.
2020-04-30 13:22:23 +02:00
* Set PublishCDS if not set.
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
*/
Set SyncPublish on keys Set the SyncPublish metadata on keys that don't have them yet.
2020-04-30 13:22:23 +02:00
ret = dst_key_gettime(key->key, DST_TIME_SYNCPUBLISH, &syncpub);
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
if (ret != ISC_R_SUCCESS) {
Set SyncPublish on keys Set the SyncPublish metadata on keys that don't have them yet.
2020-04-30 13:22:23 +02:00
uint32_t tag;
isc_stdtime_t syncpub1, syncpub2;
syncpub1 = pub + prepub;
syncpub2 = 0;
ret = dst_key_getnum(key->key, DST_NUM_PREDECESSOR,
&tag);
if (ret != ISC_R_SUCCESS) {
/*
* No predecessor, wait for zone to be
* completely signed.
*/
Ignore max-zone-ttl on dnssec-policy insecure Allow larger TTL values in zones that go insecure. This is necessary because otherwise the zone will not be loaded due to the max-zone-ttl of P1D that is part of the current insecure policy. In the keymgr.c code, default back to P1D if the max-zone-ttl is set to zero.
2023-07-26 11:50:57 +02:00
dns_ttl_t ttlsig = dns_kasp_zonemaxttl(kasp,
true);
syncpub2 = pub + ttlsig +
Set SyncPublish on keys Set the SyncPublish metadata on keys that don't have them yet.
2020-04-30 13:22:23 +02:00
dns_kasp_publishsafety(kasp) +
dns_kasp_zonepropagationdelay(kasp);
}
Nit changes in keymgr and kasp Use the ISC_MAX define instead of "x = a > b ? a : b" paradigm. Remove an unneeded include.
2022-06-21 12:45:54 +02:00
syncpub = ISC_MAX(syncpub1, syncpub2);
Set SyncPublish on keys Set the SyncPublish metadata on keys that don't have them yet.
2020-04-30 13:22:23 +02:00
dst_key_settime(key->key, DST_TIME_SYNCPUBLISH,
syncpub);
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
}
Test keytimes on CSK rollover This improves keytime testing on CSK rollover. It now tests for specific times, and also tests for SyncPublish and Removed keytimes. Since an "active key" for ZSK and KSK means something different, this makes it tricky to decide when a CSK is active. An "active key" intuitively means the key is signing so we say a CSK is active when it is creating zone signatures. This change means a lot of timings for the CSK rollover tests need to be adjusted. The keymgr code needs a slight change on calculating the prepublication time: For a KSK we need to include the parent registration delay, but for CSK we look at the zone signing property and stick with the ZSK prepublication calculation.
2020-05-11 15:12:32 +02:00
}
kasp: registration delay adjustments Registration delay is not part of the Iret retire interval, thus removed from the calculation when setting the Delete time metadata. Include the registration delay in prepublication time, because we need to prepublish the key sooner than just the Ipub publication interval.
2020-05-04 12:30:40 +02:00
Check return value of dst_key_getbool() Fix Coverity CHECKED_RETURN reports for dst_key_getbool(). In most cases we do not really care about its return value, but it is prudent to check it. In one case, where a dst_key_getbool() error should be treated identically as success, cast the return value to void and add a relevant comment.
2020-07-06 12:07:24 +02:00
/*
* Not sure what to do when dst_key_getbool() fails here. Extending
* the prepublication time anyway is arguably the safest thing to do,
* so ignore the result code.
*/
Test keytimes on CSK rollover This improves keytime testing on CSK rollover. It now tests for specific times, and also tests for SyncPublish and Removed keytimes. Since an "active key" for ZSK and KSK means something different, this makes it tricky to decide when a CSK is active. An "active key" intuitively means the key is signing so we say a CSK is active when it is creating zone signatures. This change means a lot of timings for the CSK rollover tests need to be adjusted. The keymgr code needs a slight change on calculating the prepublication time: For a KSK we need to include the parent registration delay, but for CSK we look at the zone signing property and stick with the ZSK prepublication calculation.
2020-05-11 15:12:32 +02:00
(void)dst_key_getbool(key->key, DST_BOOL_ZSK, &zsk);
Set SyncPublish on keys Set the SyncPublish metadata on keys that don't have them yet.
2020-04-30 13:22:23 +02:00
ret = dst_key_gettime(key->key, DST_TIME_INACTIVE, &retire);
if (ret != ISC_R_SUCCESS) {
uint32_t klifetime = 0;
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
ret = dst_key_getnum(key->key, DST_NUM_LIFETIME, &klifetime);
if (ret != ISC_R_SUCCESS) {
dst_key_setnum(key->key, DST_NUM_LIFETIME, lifetime);
klifetime = lifetime;
}
if (klifetime == 0) {
/*
* No inactive time and no lifetime,
* so no need to start a rollover.
*/
return 0;
}
Check for overflow when adding lifetime
2024-06-26 14:39:04 +10:00
if (ISC_OVERFLOW_ADD(active, klifetime, &retire)) {
Log key calculation overflows
2024-06-26 14:49:51 +10:00
log_key_overflow(key->key, "retire");
Check for overflow when adding lifetime
2024-06-26 14:39:04 +10:00
retire = UINT32_MAX;
}
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
dst_key_settime(key->key, DST_TIME_INACTIVE, retire);
}
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
/*
* Update remove time.
*/
keymgr_settime_remove(key, kasp);
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/*
* Publish successor 'prepub' time before the 'retire' time of 'key'.
*/
If prepub > retire, prepub now Catch a case where if the prepublication time of the successor key is later than the retire time of the predecessor. If that is the case we should prepublish as soon as possible, a.k.a. now.
2020-05-14 15:36:13 +02:00
if (prepub > retire) {
/* We should have already prepublished the new key. */
return now;
}
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
return retire - prepub;
}
static void
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
keymgr_key_retire(dns_dnsseckey_t *key, dns_kasp_t *kasp, isc_stdtime_t now) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
char keystr[DST_KEY_FORMATSIZE];
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
isc_result_t ret;
isc_stdtime_t retire;
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
dst_key_state_t s;
Check return value of dst_key_getbool() Fix Coverity CHECKED_RETURN reports for dst_key_getbool(). In most cases we do not really care about its return value, but it is prudent to check it. In one case, where a dst_key_getbool() error should be treated identically as success, cast the return value to void and add a relevant comment.
2020-07-06 12:07:24 +02:00
bool ksk = false, zsk = false;
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
REQUIRE(key != NULL);
REQUIRE(key->key != NULL);
/* This key wants to retire and hide in a corner. */
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
ret = dst_key_gettime(key->key, DST_TIME_INACTIVE, &retire);
if (ret != ISC_R_SUCCESS || (retire > now)) {
dst_key_settime(key->key, DST_TIME_INACTIVE, now);
}
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
dst_key_setstate(key->key, DST_KEY_GOAL, HIDDEN);
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
keymgr_settime_remove(key, kasp);
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/* This key may not have key states set yet. Pretend as if they are
* in the OMNIPRESENT state.
*/
if (dst_key_getstate(key->key, DST_KEY_DNSKEY, &s) != ISC_R_SUCCESS) {
dst_key_setstate(key->key, DST_KEY_DNSKEY, OMNIPRESENT);
dst_key_settime(key->key, DST_TIME_DNSKEY, now);
}
Check return value of dst_key_getbool() Fix Coverity CHECKED_RETURN reports for dst_key_getbool(). In most cases we do not really care about its return value, but it is prudent to check it. In one case, where a dst_key_getbool() error should be treated identically as success, cast the return value to void and add a relevant comment.
2020-07-06 12:07:24 +02:00
ret = dst_key_getbool(key->key, DST_BOOL_KSK, &ksk);
if (ret == ISC_R_SUCCESS && ksk) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
if (dst_key_getstate(key->key, DST_KEY_KRRSIG, &s) !=
Update sources to Clang 15 formatting
2022-11-02 19:33:14 +01:00
ISC_R_SUCCESS)
{
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
dst_key_setstate(key->key, DST_KEY_KRRSIG, OMNIPRESENT);
dst_key_settime(key->key, DST_TIME_KRRSIG, now);
}
if (dst_key_getstate(key->key, DST_KEY_DS, &s) != ISC_R_SUCCESS)
{
dst_key_setstate(key->key, DST_KEY_DS, OMNIPRESENT);
dst_key_settime(key->key, DST_TIME_DS, now);
}
}
Check return value of dst_key_getbool() Fix Coverity CHECKED_RETURN reports for dst_key_getbool(). In most cases we do not really care about its return value, but it is prudent to check it. In one case, where a dst_key_getbool() error should be treated identically as success, cast the return value to void and add a relevant comment.
2020-07-06 12:07:24 +02:00
ret = dst_key_getbool(key->key, DST_BOOL_ZSK, &zsk);
if (ret == ISC_R_SUCCESS && zsk) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
if (dst_key_getstate(key->key, DST_KEY_ZRRSIG, &s) !=
Update sources to Clang 15 formatting
2022-11-02 19:33:14 +01:00
ISC_R_SUCCESS)
{
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
dst_key_setstate(key->key, DST_KEY_ZRRSIG, OMNIPRESENT);
dst_key_settime(key->key, DST_TIME_ZRRSIG, now);
}
}
dst_key_format(key->key, keystr, sizeof(keystr));
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
ISC_LOG_INFO, "keymgr: retire DNSKEY %s (%s)", keystr,
keymgr_keyrole(key->key));
}
Update key lifetime and metadata after reconfig If dnssec-policy is reconfigured and the key lifetime has changed, update existing keys with the new lifetime and adjust the retire and removed timing metadata accordingly. If the key has no lifetime yet, just initialize the lifetime. It may be that the retire/removed timing metadata has already been set. Skip keys which goal is not set to omnipresent. These keys are already in the progress of retiring, or still unused.
2024-06-24 15:14:16 +02:00
/* Update lifetime and retire and remove time accordingly. */
static void
keymgr_key_update_lifetime(dns_dnsseckey_t *key, dns_kasp_t *kasp,
isc_stdtime_t now, uint32_t lifetime) {
uint32_t l;
dst_key_state_t g = HIDDEN;
isc_result_t r;
(void)dst_key_getstate(key->key, DST_KEY_GOAL, &g);
r = dst_key_getnum(key->key, DST_NUM_LIFETIME, &l);
/* Initialize lifetime. */
if (r != ISC_R_SUCCESS) {
dst_key_setnum(key->key, DST_NUM_LIFETIME, lifetime);
return;
}
/* Skip keys that are still hidden or already retiring. */
if (g != OMNIPRESENT) {
return;
}
/* Update lifetime and timing metadata. */
if (l != lifetime) {
dst_key_setnum(key->key, DST_NUM_LIFETIME, lifetime);
if (lifetime > 0) {
uint32_t a = now;
Check for overflow when adding lifetime
2024-06-26 14:39:04 +10:00
uint32_t inactive;
Update key lifetime and metadata after reconfig If dnssec-policy is reconfigured and the key lifetime has changed, update existing keys with the new lifetime and adjust the retire and removed timing metadata accordingly. If the key has no lifetime yet, just initialize the lifetime. It may be that the retire/removed timing metadata has already been set. Skip keys which goal is not set to omnipresent. These keys are already in the progress of retiring, or still unused.
2024-06-24 15:14:16 +02:00
(void)dst_key_gettime(key->key, DST_TIME_ACTIVATE, &a);
Check for overflow when adding lifetime
2024-06-26 14:39:04 +10:00
if (ISC_OVERFLOW_ADD(a, lifetime, &inactive)) {
Log key calculation overflows
2024-06-26 14:49:51 +10:00
log_key_overflow(key->key, "inactive");
Check for overflow when adding lifetime
2024-06-26 14:39:04 +10:00
inactive = UINT32_MAX;
}
dst_key_settime(key->key, DST_TIME_INACTIVE, inactive);
Update key lifetime and metadata after reconfig If dnssec-policy is reconfigured and the key lifetime has changed, update existing keys with the new lifetime and adjust the retire and removed timing metadata accordingly. If the key has no lifetime yet, just initialize the lifetime. It may be that the retire/removed timing metadata has already been set. Skip keys which goal is not set to omnipresent. These keys are already in the progress of retiring, or still unused.
2024-06-24 15:14:16 +02:00
keymgr_settime_remove(key, kasp);
} else {
dst_key_unsettime(key->key, DST_TIME_INACTIVE);
dst_key_unsettime(key->key, DST_TIME_DELETE);
}
}
}
Check for keyid conflicts between new keys When the keymgr needs to create new keys, it is possible it needs to create multiple keys. The keymgr checks for keyid conflicts with already existing keys, but it should also check against that it just created.
2021-04-12 16:22:00 +02:00
static bool
Add the concept of allowed key tag ranges to kasp
2024-08-06 14:41:50 +10:00
keymgr_keyid_conflict(dst_key_t *newkey, uint16_t min, uint16_t max,
dns_dnsseckeylist_t *keys) {
Check for keyid conflicts between new keys When the keymgr needs to create new keys, it is possible it needs to create multiple keys. The keymgr checks for keyid conflicts with already existing keys, but it should also check against that it just created.
2021-04-12 16:22:00 +02:00
uint16_t id = dst_key_id(newkey);
uint32_t rid = dst_key_rid(newkey);
uint32_t alg = dst_key_alg(newkey);
Add the concept of allowed key tag ranges to kasp
2024-08-06 14:41:50 +10:00
if (id < min || id > max) {
return true;
}
if (rid < min || rid > max) {
return true;
}
Check for keyid conflicts between new keys When the keymgr needs to create new keys, it is possible it needs to create multiple keys. The keymgr checks for keyid conflicts with already existing keys, but it should also check against that it just created.
2021-04-12 16:22:00 +02:00
for (dns_dnsseckey_t *dkey = ISC_LIST_HEAD(*keys); dkey != NULL;
dkey = ISC_LIST_NEXT(dkey, link))
{
if (dst_key_alg(dkey->key) != alg) {
continue;
}
if (dst_key_id(dkey->key) == id ||
dst_key_rid(dkey->key) == id ||
dst_key_id(dkey->key) == rid ||
dst_key_rid(dkey->key) == rid)
{
return true;
}
}
return false;
}
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/*
* Create a new key for 'origin' given the kasp key configuration 'kkey'.
* This will check for key id collisions with keys in 'keylist'.
* The created key will be stored in 'dst_key'.
*
*/
static isc_result_t
keymgr_createkey(dns_kasp_key_t *kkey, const dns_name_t *origin,
Better PKCS#11 label creation When using the same PKCS#11 URI for a zone that uses different DNSSEC policies, the PKCS#11 label could collide, i.e. the same label could be used for different keys. Add the policy name to the label to make it more unique. Also, the zone name could contain characters that are interpreted as special characters when parsing the PKCS#11 URI string. Mangle the zone name through 'dns_name_tofilenametext()' to make it PKCS#11 safe. Move the creation to a separate function for clarity. Furthermore, add a log message whenever a PKCS#11 object has been successfully created.
2023-11-17 10:45:05 +01:00
dns_kasp_t *kasp, dns_rdataclass_t rdclass, isc_mem_t *mctx,
const char *keydir, dns_dnsseckeylist_t *keylist,
dns_dnsseckeylist_t *newkeys, dst_key_t **dst_key) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
isc_result_t result = ISC_R_SUCCESS;
Create private keys with PKCS#11 object If there is a keystore configured with a PKCS#11 URI, zones that are using a dnssec-policy that uses such a keystore should create keys via the PKCS#11 interface. Those keys are generally stored inside an HSM. Some changes to the code are required, to store the engine reference into the keystore.
2022-02-28 11:50:43 +01:00
bool conflict = false;
int flags = DNS_KEYOWNER_ZONE;
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
dst_key_t *newkey = NULL;
Create private keys with PKCS#11 object If there is a keystore configured with a PKCS#11 URI, zones that are using a dnssec-policy that uses such a keystore should create keys via the PKCS#11 interface. Those keys are generally stored inside an HSM. Some changes to the code are required, to store the engine reference into the keystore.
2022-02-28 11:50:43 +01:00
uint32_t alg = dns_kasp_key_algorithm(kkey);
dns_keystore_t *keystore = dns_kasp_key_keystore(kkey);
Refactor dns_keystore_directory() Add a default key-directory parameter to the function that can be returned if there is no keystore, or if the keystore directory is NULL (the latter is also true for the built-in keystore).
2023-11-17 17:09:00 +01:00
const char *dir = NULL;
Create private keys with PKCS#11 object If there is a keystore configured with a PKCS#11 URI, zones that are using a dnssec-policy that uses such a keystore should create keys via the PKCS#11 interface. Those keys are generally stored inside an HSM. Some changes to the code are required, to store the engine reference into the keystore.
2022-02-28 11:50:43 +01:00
int size = dns_kasp_key_size(kkey);
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
Create private keys with PKCS#11 object If there is a keystore configured with a PKCS#11 URI, zones that are using a dnssec-policy that uses such a keystore should create keys via the PKCS#11 interface. Those keys are generally stored inside an HSM. Some changes to the code are required, to store the engine reference into the keystore.
2022-02-28 11:50:43 +01:00
if (dns_kasp_key_ksk(kkey)) {
flags |= DNS_KEYFLAG_KSK;
}
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
Create private keys with PKCS#11 object If there is a keystore configured with a PKCS#11 URI, zones that are using a dnssec-policy that uses such a keystore should create keys via the PKCS#11 interface. Those keys are generally stored inside an HSM. Some changes to the code are required, to store the engine reference into the keystore.
2022-02-28 11:50:43 +01:00
do {
if (keystore == NULL) {
RETERR(dst_key_generate(origin, alg, size, 0, flags,
DNS_KEYPROTO_DNSSEC, rdclass,
NULL, mctx, &newkey, NULL));
} else {
Better PKCS#11 label creation When using the same PKCS#11 URI for a zone that uses different DNSSEC policies, the PKCS#11 label could collide, i.e. the same label could be used for different keys. Add the policy name to the label to make it more unique. Also, the zone name could contain characters that are interpreted as special characters when parsing the PKCS#11 URI string. Mangle the zone name through 'dns_name_tofilenametext()' to make it PKCS#11 safe. Move the creation to a separate function for clarity. Furthermore, add a log message whenever a PKCS#11 object has been successfully created.
2023-11-17 10:45:05 +01:00
RETERR(dns_keystore_keygen(
keystore, origin, dns_kasp_getname(kasp),
rdclass, mctx, alg, size, flags, &newkey));
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
}
/* Key collision? */
Add the concept of allowed key tag ranges to kasp
2024-08-06 14:41:50 +10:00
conflict = keymgr_keyid_conflict(newkey, kkey->tag_min,
kkey->tag_max, keylist);
Check for keyid conflicts between new keys When the keymgr needs to create new keys, it is possible it needs to create multiple keys. The keymgr checks for keyid conflicts with already existing keys, but it should also check against that it just created.
2021-04-12 16:22:00 +02:00
if (!conflict) {
Add the concept of allowed key tag ranges to kasp
2024-08-06 14:41:50 +10:00
conflict = keymgr_keyid_conflict(
newkey, kkey->tag_min, kkey->tag_max, newkeys);
Check for keyid conflicts between new keys When the keymgr needs to create new keys, it is possible it needs to create multiple keys. The keymgr checks for keyid conflicts with already existing keys, but it should also check against that it just created.
2021-04-12 16:22:00 +02:00
}
if (conflict) {
/* Try again. */
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
Check for keyid conflicts between new keys When the keymgr needs to create new keys, it is possible it needs to create multiple keys. The keymgr checks for keyid conflicts with already existing keys, but it should also check against that it just created.
2021-04-12 16:22:00 +02:00
DNS_LOGMODULE_DNSSEC, ISC_LOG_WARNING,
"keymgr: key collision id %d",
dst_key_id(newkey));
dst_key_free(&newkey);
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
}
change 'expr == true' to 'expr' in conditionals
2020-03-30 13:47:58 -07:00
} while (conflict);
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
INSIST(!conflict);
dst_key_setnum(newkey, DST_NUM_LIFETIME, dns_kasp_key_lifetime(kkey));
dst_key_setbool(newkey, DST_BOOL_KSK, dns_kasp_key_ksk(kkey));
dst_key_setbool(newkey, DST_BOOL_ZSK, dns_kasp_key_zsk(kkey));
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
Refactor dns_keystore_directory() Add a default key-directory parameter to the function that can be returned if there is no keystore, or if the keystore directory is NULL (the latter is also true for the built-in keystore).
2023-11-17 17:09:00 +01:00
dir = dns_keystore_directory(keystore, keydir);
if (dir != NULL) {
dst_key_setdirectory(newkey, dir);
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
}
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
*dst_key = newkey;
return ISC_R_SUCCESS;
failure:
return result;
}
/*
* Return the desired state for this record 'type'. The desired state depends
* on whether the key wants to be active, or wants to retire. This implements
* the edges of our state machine:
*
* ----> OMNIPRESENT ----
* | |
* | \|/
*
* RUMOURED <----> UNRETENTIVE
*
* /|\ |
* | |
* ---- HIDDEN <----
*
* A key that wants to be active eventually wants to have its record types
* in the OMNIPRESENT state (that is, all resolvers that know about these
* type of records know about these records specifically).
*
* A key that wants to be retired eventually wants to have its record types
* in the HIDDEN state (that is, all resolvers that know about these type
* of records specifically don't know about these records).
*
*/
static dst_key_state_t
keymgr_desiredstate(dns_dnsseckey_t *key, dst_key_state_t state) {
dst_key_state_t goal;
if (dst_key_getstate(key->key, DST_KEY_GOAL, &goal) != ISC_R_SUCCESS) {
/* No goal? No movement. */
return state;
}
if (goal == HIDDEN) {
switch (state) {
case RUMOURED:
case OMNIPRESENT:
return UNRETENTIVE;
case HIDDEN:
case UNRETENTIVE:
return HIDDEN;
default:
return state;
}
} else if (goal == OMNIPRESENT) {
switch (state) {
case RUMOURED:
case OMNIPRESENT:
return OMNIPRESENT;
case HIDDEN:
case UNRETENTIVE:
return RUMOURED;
default:
return state;
}
}
/* Unknown goal. */
return state;
}
/*
* Check if 'key' matches specific 'states'.
* A state in 'states' that is NA matches any state.
* A state in 'states' that is HIDDEN also matches if the state is not set.
* If 'next_state' is set (not NA), we are pretending as if record 'type' of
* 'subject' key already transitioned to the 'next state'.
*
*/
static bool
keymgr_key_match_state(dst_key_t *key, dst_key_t *subject, int type,
Use NUM_KEYSTATES constant where appropriate We use the number 4 a lot when working on key states. Better to use the NUM_KEYSTATES constant instead.
2021-02-01 09:40:44 +01:00
dst_key_state_t next_state,
dst_key_state_t states[NUM_KEYSTATES]) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
REQUIRE(key != NULL);
Use NUM_KEYSTATES constant where appropriate We use the number 4 a lot when working on key states. Better to use the NUM_KEYSTATES constant instead.
2021-02-01 09:40:44 +01:00
for (int i = 0; i < NUM_KEYSTATES; i++) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
dst_key_state_t state;
if (states[i] == NA) {
continue;
}
if (next_state != NA && i == type &&
Fix algorithm rollover bug wrt keytag conflicts If there is an algorithm rollover and two keys of different algorithm share the same keytags, then there is a possibility that if we check that a key matches a specific state, we are checking against the wrong key. Fix this by not only checking for matching key id but also key algorithm.
2024-08-21 17:14:48 +02:00
dst_key_alg(key) == dst_key_alg(subject) &&
Update sources to Clang 15 formatting
2022-11-02 19:33:14 +01:00
dst_key_id(key) == dst_key_id(subject))
{
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/* Check next state rather than current state. */
state = next_state;
} else if (dst_key_getstate(key, i, &state) != ISC_R_SUCCESS) {
/* This is fine only if expected state is HIDDEN. */
if (states[i] != HIDDEN) {
return false;
}
continue;
}
if (state != states[i]) {
return false;
}
}
/* Match. */
return true;
}
/*
Implement Equation(2) of "Flexible Key Rollover" So far the key manager could only deal with two keys in a rollover, because it used a simplified version of the successor relationship equation from "Flexible and Robust Key Rollover" paper. The simplified version assumes only two keys take part in the key rollover and it for that it is enough to check the direct relationship between two keys (is key x the direct predecessor of key z and is key z the direct successor of key x?). But when a third key (or more keys) comes into the equation, the key manager would assume that one key (or more) is redundant and removed it from the zone prematurely. Fix by implementing Equation(2) correctly, where we check for dependencies on keys: z ->T x: Dep(x, T) = ∅ ∧ (x ∈ Dep(z, T) ∨ ∃ y ∈ Dep(z, T)(y != z ∧ y ->T x ∧ DyKyRySy = DzKzRzSz)) This says: key z is a successor of key x if: - key x depends on key z if z is a direct successor of x, - or if there is another key y that depends on key z that has identical key states as key z and key y is a successor of key x. - Also, key x may not have any other keys depending on it. This is still a simplified version of Equation(2) (but at least much better), because the paper allows for a set of keys to depend on a key. This is defined as the set Dep(x, T). Keys in the set Dep(x, T) have a dependency on key x for record type T. The BIND implementation can only have one key in the set Dep(x, T). The function 'keymgr_dep()' stores this key in 'uint32_t *dep' if there is a dependency. There are two scenarios where multiple keys can depend on a single key: 1. Rolling keys is faster than the time required to finish the rollover procedure. This scenario is covered by the recursive implementation, and checking for a chain of direct dependencies will suffice. 2. Changing the policy, when a zone is requested to be signed with a different key length for example. BIND 9 will not mark successor relationships in this case, but tries to move towards the new policy. Since there is no successor relationship, the rules are even more strict, and the DNSSEC reconfiguration is actually slower than required. Note: this commit breaks the build, because the function definition of 'keymgr_key_is_successor' changed. This will be fixed in the following commit.
2021-01-07 10:30:15 +01:00
* Key d directly depends on k if d is the direct predecessor of k.
*/
static bool
keymgr_direct_dep(dst_key_t *d, dst_key_t *k) {
uint32_t s, p;
if (dst_key_getnum(d, DST_NUM_SUCCESSOR, &s) != ISC_R_SUCCESS) {
return false;
}
if (dst_key_getnum(k, DST_NUM_PREDECESSOR, &p) != ISC_R_SUCCESS) {
return false;
}
return dst_key_id(d) == p && dst_key_id(k) == s;
}
/*
* Determine which key (if any) has a dependency on k.
*/
static bool
keymgr_dep(dst_key_t *k, dns_dnsseckeylist_t *keyring, uint32_t *dep) {
for (dns_dnsseckey_t *d = ISC_LIST_HEAD(*keyring); d != NULL;
d = ISC_LIST_NEXT(d, link))
{
/*
* Check if k is a direct successor of d, e.g. d depends on k.
*/
if (keymgr_direct_dep(d->key, k)) {
Fix bug in keymgr Depends function The Depends relation refers to types of rollovers in which a certain record type is going to be swapped. Specifically, the Depends relation says there should be no dependency on the predecessor key (the set Dep(x, T) must be empty). But if the key is phased out (all its states are in HIDDEN), there is no longer a dependency. Since the relationship is still maintained (Predecessor and Successor metadata), the keymgr_dep function still returned true. In other words, the set Dep(x, T) is not considered empty. This slows down key rollovers, only retiring keys when the successor key has been fully propagated.
2024-01-31 12:25:29 +01:00
dst_key_state_t hidden[NUM_KEYSTATES] = {
HIDDEN, HIDDEN, HIDDEN, HIDDEN
};
if (keymgr_key_match_state(d->key, k, NA, NA, hidden)) {
continue;
}
Implement Equation(2) of "Flexible Key Rollover" So far the key manager could only deal with two keys in a rollover, because it used a simplified version of the successor relationship equation from "Flexible and Robust Key Rollover" paper. The simplified version assumes only two keys take part in the key rollover and it for that it is enough to check the direct relationship between two keys (is key x the direct predecessor of key z and is key z the direct successor of key x?). But when a third key (or more keys) comes into the equation, the key manager would assume that one key (or more) is redundant and removed it from the zone prematurely. Fix by implementing Equation(2) correctly, where we check for dependencies on keys: z ->T x: Dep(x, T) = ∅ ∧ (x ∈ Dep(z, T) ∨ ∃ y ∈ Dep(z, T)(y != z ∧ y ->T x ∧ DyKyRySy = DzKzRzSz)) This says: key z is a successor of key x if: - key x depends on key z if z is a direct successor of x, - or if there is another key y that depends on key z that has identical key states as key z and key y is a successor of key x. - Also, key x may not have any other keys depending on it. This is still a simplified version of Equation(2) (but at least much better), because the paper allows for a set of keys to depend on a key. This is defined as the set Dep(x, T). Keys in the set Dep(x, T) have a dependency on key x for record type T. The BIND implementation can only have one key in the set Dep(x, T). The function 'keymgr_dep()' stores this key in 'uint32_t *dep' if there is a dependency. There are two scenarios where multiple keys can depend on a single key: 1. Rolling keys is faster than the time required to finish the rollover procedure. This scenario is covered by the recursive implementation, and checking for a chain of direct dependencies will suffice. 2. Changing the policy, when a zone is requested to be signed with a different key length for example. BIND 9 will not mark successor relationships in this case, but tries to move towards the new policy. Since there is no successor relationship, the rules are even more strict, and the DNSSEC reconfiguration is actually slower than required. Note: this commit breaks the build, because the function definition of 'keymgr_key_is_successor' changed. This will be fixed in the following commit.
2021-01-07 10:30:15 +01:00
if (dep != NULL) {
*dep = dst_key_id(d->key);
}
return true;
}
}
return false;
}
/*
* Check if a 'z' is a successor of 'x'.
* This implements Equation(2) of "Flexible and Robust Key Rollover".
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
*/
static bool
Implement Equation(2) of "Flexible Key Rollover" So far the key manager could only deal with two keys in a rollover, because it used a simplified version of the successor relationship equation from "Flexible and Robust Key Rollover" paper. The simplified version assumes only two keys take part in the key rollover and it for that it is enough to check the direct relationship between two keys (is key x the direct predecessor of key z and is key z the direct successor of key x?). But when a third key (or more keys) comes into the equation, the key manager would assume that one key (or more) is redundant and removed it from the zone prematurely. Fix by implementing Equation(2) correctly, where we check for dependencies on keys: z ->T x: Dep(x, T) = ∅ ∧ (x ∈ Dep(z, T) ∨ ∃ y ∈ Dep(z, T)(y != z ∧ y ->T x ∧ DyKyRySy = DzKzRzSz)) This says: key z is a successor of key x if: - key x depends on key z if z is a direct successor of x, - or if there is another key y that depends on key z that has identical key states as key z and key y is a successor of key x. - Also, key x may not have any other keys depending on it. This is still a simplified version of Equation(2) (but at least much better), because the paper allows for a set of keys to depend on a key. This is defined as the set Dep(x, T). Keys in the set Dep(x, T) have a dependency on key x for record type T. The BIND implementation can only have one key in the set Dep(x, T). The function 'keymgr_dep()' stores this key in 'uint32_t *dep' if there is a dependency. There are two scenarios where multiple keys can depend on a single key: 1. Rolling keys is faster than the time required to finish the rollover procedure. This scenario is covered by the recursive implementation, and checking for a chain of direct dependencies will suffice. 2. Changing the policy, when a zone is requested to be signed with a different key length for example. BIND 9 will not mark successor relationships in this case, but tries to move towards the new policy. Since there is no successor relationship, the rules are even more strict, and the DNSSEC reconfiguration is actually slower than required. Note: this commit breaks the build, because the function definition of 'keymgr_key_is_successor' changed. This will be fixed in the following commit.
2021-01-07 10:30:15 +01:00
keymgr_key_is_successor(dst_key_t *x, dst_key_t *z, dst_key_t *key, int type,
dst_key_state_t next_state,
dns_dnsseckeylist_t *keyring) {
uint32_t dep_x;
uint32_t dep_z;
/*
* The successor relation requires that the predecessor key must not
* have any other keys relying on it. In other words, there must be
* nothing depending on x.
*/
if (keymgr_dep(x, keyring, &dep_x)) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
return false;
}
Implement Equation(2) of "Flexible Key Rollover" So far the key manager could only deal with two keys in a rollover, because it used a simplified version of the successor relationship equation from "Flexible and Robust Key Rollover" paper. The simplified version assumes only two keys take part in the key rollover and it for that it is enough to check the direct relationship between two keys (is key x the direct predecessor of key z and is key z the direct successor of key x?). But when a third key (or more keys) comes into the equation, the key manager would assume that one key (or more) is redundant and removed it from the zone prematurely. Fix by implementing Equation(2) correctly, where we check for dependencies on keys: z ->T x: Dep(x, T) = ∅ ∧ (x ∈ Dep(z, T) ∨ ∃ y ∈ Dep(z, T)(y != z ∧ y ->T x ∧ DyKyRySy = DzKzRzSz)) This says: key z is a successor of key x if: - key x depends on key z if z is a direct successor of x, - or if there is another key y that depends on key z that has identical key states as key z and key y is a successor of key x. - Also, key x may not have any other keys depending on it. This is still a simplified version of Equation(2) (but at least much better), because the paper allows for a set of keys to depend on a key. This is defined as the set Dep(x, T). Keys in the set Dep(x, T) have a dependency on key x for record type T. The BIND implementation can only have one key in the set Dep(x, T). The function 'keymgr_dep()' stores this key in 'uint32_t *dep' if there is a dependency. There are two scenarios where multiple keys can depend on a single key: 1. Rolling keys is faster than the time required to finish the rollover procedure. This scenario is covered by the recursive implementation, and checking for a chain of direct dependencies will suffice. 2. Changing the policy, when a zone is requested to be signed with a different key length for example. BIND 9 will not mark successor relationships in this case, but tries to move towards the new policy. Since there is no successor relationship, the rules are even more strict, and the DNSSEC reconfiguration is actually slower than required. Note: this commit breaks the build, because the function definition of 'keymgr_key_is_successor' changed. This will be fixed in the following commit.
2021-01-07 10:30:15 +01:00
/*
* If there is no keys relying on key z, then z is not a successor.
*/
if (!keymgr_dep(z, keyring, &dep_z)) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
return false;
}
Implement Equation(2) of "Flexible Key Rollover" So far the key manager could only deal with two keys in a rollover, because it used a simplified version of the successor relationship equation from "Flexible and Robust Key Rollover" paper. The simplified version assumes only two keys take part in the key rollover and it for that it is enough to check the direct relationship between two keys (is key x the direct predecessor of key z and is key z the direct successor of key x?). But when a third key (or more keys) comes into the equation, the key manager would assume that one key (or more) is redundant and removed it from the zone prematurely. Fix by implementing Equation(2) correctly, where we check for dependencies on keys: z ->T x: Dep(x, T) = ∅ ∧ (x ∈ Dep(z, T) ∨ ∃ y ∈ Dep(z, T)(y != z ∧ y ->T x ∧ DyKyRySy = DzKzRzSz)) This says: key z is a successor of key x if: - key x depends on key z if z is a direct successor of x, - or if there is another key y that depends on key z that has identical key states as key z and key y is a successor of key x. - Also, key x may not have any other keys depending on it. This is still a simplified version of Equation(2) (but at least much better), because the paper allows for a set of keys to depend on a key. This is defined as the set Dep(x, T). Keys in the set Dep(x, T) have a dependency on key x for record type T. The BIND implementation can only have one key in the set Dep(x, T). The function 'keymgr_dep()' stores this key in 'uint32_t *dep' if there is a dependency. There are two scenarios where multiple keys can depend on a single key: 1. Rolling keys is faster than the time required to finish the rollover procedure. This scenario is covered by the recursive implementation, and checking for a chain of direct dependencies will suffice. 2. Changing the policy, when a zone is requested to be signed with a different key length for example. BIND 9 will not mark successor relationships in this case, but tries to move towards the new policy. Since there is no successor relationship, the rules are even more strict, and the DNSSEC reconfiguration is actually slower than required. Note: this commit breaks the build, because the function definition of 'keymgr_key_is_successor' changed. This will be fixed in the following commit.
2021-01-07 10:30:15 +01:00
/*
* x depends on z, thus key z is a direct successor of key x.
*/
if (dst_key_id(x) == dep_z) {
return true;
}
/*
* It is possible to roll keys faster than the time required to finish
* the rollover procedure. For example, consider the keys x, y, z.
* Key x is currently published and is going to be replaced by y. The
* DNSKEY for x is removed from the zone and at the same moment the
* DNSKEY for y is introduced. Key y is a direct dependency for key x
* and is therefore the successor of x. However, before the new DNSKEY
* has been propagated, key z will replace key y. The DNSKEY for y is
* removed and moves into the same state as key x. Key y now directly
* depends on key z, and key z will be a new successor key for x.
*/
Use NUM_KEYSTATES constant where appropriate We use the number 4 a lot when working on key states. Better to use the NUM_KEYSTATES constant instead.
2021-02-01 09:40:44 +01:00
dst_key_state_t zst[NUM_KEYSTATES] = { NA, NA, NA, NA };
for (int i = 0; i < NUM_KEYSTATES; i++) {
Implement Equation(2) of "Flexible Key Rollover" So far the key manager could only deal with two keys in a rollover, because it used a simplified version of the successor relationship equation from "Flexible and Robust Key Rollover" paper. The simplified version assumes only two keys take part in the key rollover and it for that it is enough to check the direct relationship between two keys (is key x the direct predecessor of key z and is key z the direct successor of key x?). But when a third key (or more keys) comes into the equation, the key manager would assume that one key (or more) is redundant and removed it from the zone prematurely. Fix by implementing Equation(2) correctly, where we check for dependencies on keys: z ->T x: Dep(x, T) = ∅ ∧ (x ∈ Dep(z, T) ∨ ∃ y ∈ Dep(z, T)(y != z ∧ y ->T x ∧ DyKyRySy = DzKzRzSz)) This says: key z is a successor of key x if: - key x depends on key z if z is a direct successor of x, - or if there is another key y that depends on key z that has identical key states as key z and key y is a successor of key x. - Also, key x may not have any other keys depending on it. This is still a simplified version of Equation(2) (but at least much better), because the paper allows for a set of keys to depend on a key. This is defined as the set Dep(x, T). Keys in the set Dep(x, T) have a dependency on key x for record type T. The BIND implementation can only have one key in the set Dep(x, T). The function 'keymgr_dep()' stores this key in 'uint32_t *dep' if there is a dependency. There are two scenarios where multiple keys can depend on a single key: 1. Rolling keys is faster than the time required to finish the rollover procedure. This scenario is covered by the recursive implementation, and checking for a chain of direct dependencies will suffice. 2. Changing the policy, when a zone is requested to be signed with a different key length for example. BIND 9 will not mark successor relationships in this case, but tries to move towards the new policy. Since there is no successor relationship, the rules are even more strict, and the DNSSEC reconfiguration is actually slower than required. Note: this commit breaks the build, because the function definition of 'keymgr_key_is_successor' changed. This will be fixed in the following commit.
2021-01-07 10:30:15 +01:00
dst_key_state_t state;
if (dst_key_getstate(z, i, &state) != ISC_R_SUCCESS) {
continue;
}
zst[i] = state;
}
for (dns_dnsseckey_t *y = ISC_LIST_HEAD(*keyring); y != NULL;
y = ISC_LIST_NEXT(y, link))
{
if (dst_key_id(y->key) == dst_key_id(z)) {
continue;
}
if (dst_key_id(y->key) != dep_z) {
continue;
}
/*
* This is another key y, that depends on key z. It may be
* part of the successor relation if the key states match
* those of key z.
*/
if (keymgr_key_match_state(y->key, key, type, next_state, zst))
{
/*
* If y is a successor of x, then z is also a
* successor of x.
*/
return keymgr_key_is_successor(x, y->key, key, type,
next_state, keyring);
}
}
return false;
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
}
/*
* Check if a key exists in 'keyring' that matches 'states'.
*
* If 'match_algorithms', the key must also match the algorithm of 'key'.
* If 'next_state' is not NA, we are actually looking for a key as if
* 'key' already transitioned to the next state.
* If 'check_successor', we also want to make sure there is a successor
* relationship with the found key that matches 'states2'.
*/
static bool
keymgr_key_exists_with_state(dns_dnsseckeylist_t *keyring, dns_dnsseckey_t *key,
int type, dst_key_state_t next_state,
Use NUM_KEYSTATES constant where appropriate We use the number 4 a lot when working on key states. Better to use the NUM_KEYSTATES constant instead.
2021-02-01 09:40:44 +01:00
dst_key_state_t states[NUM_KEYSTATES],
dst_key_state_t states2[NUM_KEYSTATES],
bool check_successor, bool match_algorithms) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
for (dns_dnsseckey_t *dkey = ISC_LIST_HEAD(*keyring); dkey != NULL;
dkey = ISC_LIST_NEXT(dkey, link))
{
if (match_algorithms &&
Update sources to Clang 15 formatting
2022-11-02 19:33:14 +01:00
(dst_key_alg(dkey->key) != dst_key_alg(key->key)))
{
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
continue;
}
Update keymgr_key_is_successor() calls The previous commit changed the function definition of 'keymgr_key_is_successor()', this commit updates the code where this function is called. In 'keymgr_key_exists_with_state()' the logic is also updated slightly to become more readable. First handle the easy cases: - If the key does not match the state, continue with the next key. - If we found a key with matching state, and there is no need to check the successor relationship, return (true). - Otherwise check the successor relationship. In 'keymgr_key_has_successor()' it is enough to check if a key has a direct successor, so instead of calling 'keymgr_key_is_successor()', we can just check 'keymgr_direct_dep()'. In 'dns_keymgr_run()', we want to make sure that there is no dependency on the keys before retiring excess keys, so replace 'keymgr_key_is_successor()' with 'keymgr_dep()'.
2021-01-07 12:04:14 +01:00
if (!keymgr_key_match_state(dkey->key, key->key, type,
Update sources to Clang 15 formatting
2022-11-02 19:33:14 +01:00
next_state, states))
{
Update keymgr_key_is_successor() calls The previous commit changed the function definition of 'keymgr_key_is_successor()', this commit updates the code where this function is called. In 'keymgr_key_exists_with_state()' the logic is also updated slightly to become more readable. First handle the easy cases: - If the key does not match the state, continue with the next key. - If we found a key with matching state, and there is no need to check the successor relationship, return (true). - Otherwise check the successor relationship. In 'keymgr_key_has_successor()' it is enough to check if a key has a direct successor, so instead of calling 'keymgr_key_is_successor()', we can just check 'keymgr_direct_dep()'. In 'dns_keymgr_run()', we want to make sure that there is no dependency on the keys before retiring excess keys, so replace 'keymgr_key_is_successor()' with 'keymgr_dep()'.
2021-01-07 12:04:14 +01:00
continue;
}
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
Update keymgr_key_is_successor() calls The previous commit changed the function definition of 'keymgr_key_is_successor()', this commit updates the code where this function is called. In 'keymgr_key_exists_with_state()' the logic is also updated slightly to become more readable. First handle the easy cases: - If the key does not match the state, continue with the next key. - If we found a key with matching state, and there is no need to check the successor relationship, return (true). - Otherwise check the successor relationship. In 'keymgr_key_has_successor()' it is enough to check if a key has a direct successor, so instead of calling 'keymgr_key_is_successor()', we can just check 'keymgr_direct_dep()'. In 'dns_keymgr_run()', we want to make sure that there is no dependency on the keys before retiring excess keys, so replace 'keymgr_key_is_successor()' with 'keymgr_dep()'.
2021-01-07 12:04:14 +01:00
/* Found a match. */
if (!check_successor) {
return true;
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
}
Update keymgr_key_is_successor() calls The previous commit changed the function definition of 'keymgr_key_is_successor()', this commit updates the code where this function is called. In 'keymgr_key_exists_with_state()' the logic is also updated slightly to become more readable. First handle the easy cases: - If the key does not match the state, continue with the next key. - If we found a key with matching state, and there is no need to check the successor relationship, return (true). - Otherwise check the successor relationship. In 'keymgr_key_has_successor()' it is enough to check if a key has a direct successor, so instead of calling 'keymgr_key_is_successor()', we can just check 'keymgr_direct_dep()'. In 'dns_keymgr_run()', we want to make sure that there is no dependency on the keys before retiring excess keys, so replace 'keymgr_key_is_successor()' with 'keymgr_dep()'.
2021-01-07 12:04:14 +01:00
/*
* We have to make sure that the key we are checking, also
* has a successor relationship with another key.
*/
for (dns_dnsseckey_t *skey = ISC_LIST_HEAD(*keyring);
skey != NULL; skey = ISC_LIST_NEXT(skey, link))
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
{
Update keymgr_key_is_successor() calls The previous commit changed the function definition of 'keymgr_key_is_successor()', this commit updates the code where this function is called. In 'keymgr_key_exists_with_state()' the logic is also updated slightly to become more readable. First handle the easy cases: - If the key does not match the state, continue with the next key. - If we found a key with matching state, and there is no need to check the successor relationship, return (true). - Otherwise check the successor relationship. In 'keymgr_key_has_successor()' it is enough to check if a key has a direct successor, so instead of calling 'keymgr_key_is_successor()', we can just check 'keymgr_direct_dep()'. In 'dns_keymgr_run()', we want to make sure that there is no dependency on the keys before retiring excess keys, so replace 'keymgr_key_is_successor()' with 'keymgr_dep()'.
2021-01-07 12:04:14 +01:00
if (skey == dkey) {
continue;
}
if (!keymgr_key_match_state(skey->key, key->key, type,
Update sources to Clang 15 formatting
2022-11-02 19:33:14 +01:00
next_state, states2))
{
Update keymgr_key_is_successor() calls The previous commit changed the function definition of 'keymgr_key_is_successor()', this commit updates the code where this function is called. In 'keymgr_key_exists_with_state()' the logic is also updated slightly to become more readable. First handle the easy cases: - If the key does not match the state, continue with the next key. - If we found a key with matching state, and there is no need to check the successor relationship, return (true). - Otherwise check the successor relationship. In 'keymgr_key_has_successor()' it is enough to check if a key has a direct successor, so instead of calling 'keymgr_key_is_successor()', we can just check 'keymgr_direct_dep()'. In 'dns_keymgr_run()', we want to make sure that there is no dependency on the keys before retiring excess keys, so replace 'keymgr_key_is_successor()' with 'keymgr_dep()'.
2021-01-07 12:04:14 +01:00
continue;
}
/*
* Found a possible successor, check.
*/
if (keymgr_key_is_successor(dkey->key, skey->key,
key->key, type, next_state,
keyring))
{
return true;
}
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
}
}
/* No match. */
return false;
}
/*
* Check if a key has a successor.
*/
static bool
Fix bug in keymgr_key_has_successor The logic in `keymgr_key_has_successor(key, keyring)` is flawed, it returns true if there is any key in the keyring that has a successor, while what we really want here is to make sure that the given key has a successor in the given keyring. Rather than relying on `keymgr_key_exists_with_state`, walk the list of keys in the keyring and check if the key is a successor of the given predecessor key.
2020-05-14 15:06:54 +02:00
keymgr_key_has_successor(dns_dnsseckey_t *predecessor,
dns_dnsseckeylist_t *keyring) {
for (dns_dnsseckey_t *successor = ISC_LIST_HEAD(*keyring);
successor != NULL; successor = ISC_LIST_NEXT(successor, link))
{
Update keymgr_key_is_successor() calls The previous commit changed the function definition of 'keymgr_key_is_successor()', this commit updates the code where this function is called. In 'keymgr_key_exists_with_state()' the logic is also updated slightly to become more readable. First handle the easy cases: - If the key does not match the state, continue with the next key. - If we found a key with matching state, and there is no need to check the successor relationship, return (true). - Otherwise check the successor relationship. In 'keymgr_key_has_successor()' it is enough to check if a key has a direct successor, so instead of calling 'keymgr_key_is_successor()', we can just check 'keymgr_direct_dep()'. In 'dns_keymgr_run()', we want to make sure that there is no dependency on the keys before retiring excess keys, so replace 'keymgr_key_is_successor()' with 'keymgr_dep()'.
2021-01-07 12:04:14 +01:00
if (keymgr_direct_dep(predecessor->key, successor->key)) {
Fix bug in keymgr_key_has_successor The logic in `keymgr_key_has_successor(key, keyring)` is flawed, it returns true if there is any key in the keyring that has a successor, while what we really want here is to make sure that the given key has a successor in the given keyring. Rather than relying on `keymgr_key_exists_with_state`, walk the list of keys in the keyring and check if the key is a successor of the given predecessor key.
2020-05-14 15:06:54 +02:00
return true;
}
}
return false;
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
}
/*
* Check if all keys have their DS hidden. If not, then there must be at
* least one key with an OMNIPRESENT DNSKEY.
*
* If 'next_state' is not NA, we are actually looking for a key as if
* 'key' already transitioned to the next state.
* If 'match_algorithms', only consider keys with same algorithm of 'key'.
*
*/
static bool
keymgr_ds_hidden_or_chained(dns_dnsseckeylist_t *keyring, dns_dnsseckey_t *key,
int type, dst_key_state_t next_state,
bool match_algorithms, bool must_be_hidden) {
Use NUM_KEYSTATES constant where appropriate We use the number 4 a lot when working on key states. Better to use the NUM_KEYSTATES constant instead.
2021-02-01 09:40:44 +01:00
/* (3e) */
dst_key_state_t dnskey_chained[NUM_KEYSTATES] = { OMNIPRESENT, NA,
OMNIPRESENT, NA };
dst_key_state_t ds_hidden[NUM_KEYSTATES] = { NA, NA, NA, HIDDEN };
/* successor n/a */
dst_key_state_t na[NUM_KEYSTATES] = { NA, NA, NA, NA };
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
for (dns_dnsseckey_t *dkey = ISC_LIST_HEAD(*keyring); dkey != NULL;
dkey = ISC_LIST_NEXT(dkey, link))
{
if (match_algorithms &&
Update sources to Clang 15 formatting
2022-11-02 19:33:14 +01:00
(dst_key_alg(dkey->key) != dst_key_alg(key->key)))
{
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
continue;
}
if (keymgr_key_match_state(dkey->key, key->key, type,
Update sources to Clang 15 formatting
2022-11-02 19:33:14 +01:00
next_state, ds_hidden))
{
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/* This key has its DS hidden. */
continue;
}
if (must_be_hidden) {
return false;
}
/*
* This key does not have its DS hidden. There must be at
* least one key with the same algorithm that provides a
* chain of trust (can be this key).
*/
Fix DS/DNSKEY hidden or chained functions There was a bug in function 'keymgr_ds_hidden_or_chained()'. The funcion 'keymgr_ds_hidden_or_chained()' implements (3e) of rule2 as defined in the "Flexible and Robust Key Rollover" paper. The rules says: All DS records need to be in the HIDDEN state, or if it is not there must be a key with its DNSKEY and KRRSIG in OMNIPRESENT, and its DS in the same state as the key in question. In human langauge, if all keys have their DS in HIDDEN state you can do what you want, but if a DS record is available to some validators, there must be a chain of trust for it. Note that the barriers on transitions first check if the current state is valid, and then if the next state is valid too. But here we falsely updated the 'dnskey_omnipresent' (now 'dnskey_chained') with the next state. The next state applies to 'key' not to the state to be checked. Updating the state here leads to (true) always, because the key that will move its state will match the falsely updated expected state. This could lead to the assumption that Key 2 would be a valid chain of trust for Key 1, while clearly the presence of any DS is uncertain. The fix here is to check if the DNSKEY and KRRSIG are in OMNIPRESENT state for the key that does not have its DS in the HIDDEN state, and only if that is not the case, ensure that there is a key with the same algorithm, that provides a valid chain of trust, that is, has its DNSKEY, KRRSIG, and DS in OMNIPRESENT state. The changes in 'keymgr_dnskey_hidden_or_chained()' are only cosmetical, renaming 'rrsig_omnipresent' to 'rrsig_chained' and removing the redundant initialization of the DST_KEY_DNSKEY expected state to NA.
2021-01-07 12:12:46 +01:00
if (keymgr_key_match_state(dkey->key, key->key, type,
next_state, dnskey_chained))
{
/* This DNSKEY and KRRSIG are OMNIPRESENT. */
continue;
}
/*
* Perhaps another key provides a chain of trust.
*/
dnskey_chained[DST_KEY_DS] = OMNIPRESENT;
if (!keymgr_key_exists_with_state(keyring, key, type,
next_state, dnskey_chained,
na, false, match_algorithms))
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
{
/* There is no chain of trust. */
return false;
}
}
/* All good. */
return true;
}
/*
* Check if all keys have their DNSKEY hidden. If not, then there must be at
* least one key with an OMNIPRESENT ZRRSIG.
*
* If 'next_state' is not NA, we are actually looking for a key as if
* 'key' already transitioned to the next state.
* If 'match_algorithms', only consider keys with same algorithm of 'key'.
*
*/
static bool
keymgr_dnskey_hidden_or_chained(dns_dnsseckeylist_t *keyring,
dns_dnsseckey_t *key, int type,
dst_key_state_t next_state,
bool match_algorithms) {
Use NUM_KEYSTATES constant where appropriate We use the number 4 a lot when working on key states. Better to use the NUM_KEYSTATES constant instead.
2021-02-01 09:40:44 +01:00
/* (3i) */
dst_key_state_t rrsig_chained[NUM_KEYSTATES] = { OMNIPRESENT,
OMNIPRESENT, NA, NA };
dst_key_state_t dnskey_hidden[NUM_KEYSTATES] = { HIDDEN, NA, NA, NA };
/* successor n/a */
dst_key_state_t na[NUM_KEYSTATES] = { NA, NA, NA, NA };
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
for (dns_dnsseckey_t *dkey = ISC_LIST_HEAD(*keyring); dkey != NULL;
dkey = ISC_LIST_NEXT(dkey, link))
{
if (match_algorithms &&
Update sources to Clang 15 formatting
2022-11-02 19:33:14 +01:00
(dst_key_alg(dkey->key) != dst_key_alg(key->key)))
{
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
continue;
}
if (keymgr_key_match_state(dkey->key, key->key, type,
next_state, dnskey_hidden))
{
/* This key has its DNSKEY hidden. */
continue;
}
/*
* This key does not have its DNSKEY hidden. There must be at
* least one key with the same algorithm that has its RRSIG
* records OMNIPRESENT.
*/
(void)dst_key_getstate(dkey->key, DST_KEY_DNSKEY,
Fix DS/DNSKEY hidden or chained functions There was a bug in function 'keymgr_ds_hidden_or_chained()'. The funcion 'keymgr_ds_hidden_or_chained()' implements (3e) of rule2 as defined in the "Flexible and Robust Key Rollover" paper. The rules says: All DS records need to be in the HIDDEN state, or if it is not there must be a key with its DNSKEY and KRRSIG in OMNIPRESENT, and its DS in the same state as the key in question. In human langauge, if all keys have their DS in HIDDEN state you can do what you want, but if a DS record is available to some validators, there must be a chain of trust for it. Note that the barriers on transitions first check if the current state is valid, and then if the next state is valid too. But here we falsely updated the 'dnskey_omnipresent' (now 'dnskey_chained') with the next state. The next state applies to 'key' not to the state to be checked. Updating the state here leads to (true) always, because the key that will move its state will match the falsely updated expected state. This could lead to the assumption that Key 2 would be a valid chain of trust for Key 1, while clearly the presence of any DS is uncertain. The fix here is to check if the DNSKEY and KRRSIG are in OMNIPRESENT state for the key that does not have its DS in the HIDDEN state, and only if that is not the case, ensure that there is a key with the same algorithm, that provides a valid chain of trust, that is, has its DNSKEY, KRRSIG, and DS in OMNIPRESENT state. The changes in 'keymgr_dnskey_hidden_or_chained()' are only cosmetical, renaming 'rrsig_omnipresent' to 'rrsig_chained' and removing the redundant initialization of the DST_KEY_DNSKEY expected state to NA.
2021-01-07 12:12:46 +01:00
&rrsig_chained[DST_KEY_DNSKEY]);
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
if (!keymgr_key_exists_with_state(keyring, key, type,
Fix DS/DNSKEY hidden or chained functions There was a bug in function 'keymgr_ds_hidden_or_chained()'. The funcion 'keymgr_ds_hidden_or_chained()' implements (3e) of rule2 as defined in the "Flexible and Robust Key Rollover" paper. The rules says: All DS records need to be in the HIDDEN state, or if it is not there must be a key with its DNSKEY and KRRSIG in OMNIPRESENT, and its DS in the same state as the key in question. In human langauge, if all keys have their DS in HIDDEN state you can do what you want, but if a DS record is available to some validators, there must be a chain of trust for it. Note that the barriers on transitions first check if the current state is valid, and then if the next state is valid too. But here we falsely updated the 'dnskey_omnipresent' (now 'dnskey_chained') with the next state. The next state applies to 'key' not to the state to be checked. Updating the state here leads to (true) always, because the key that will move its state will match the falsely updated expected state. This could lead to the assumption that Key 2 would be a valid chain of trust for Key 1, while clearly the presence of any DS is uncertain. The fix here is to check if the DNSKEY and KRRSIG are in OMNIPRESENT state for the key that does not have its DS in the HIDDEN state, and only if that is not the case, ensure that there is a key with the same algorithm, that provides a valid chain of trust, that is, has its DNSKEY, KRRSIG, and DS in OMNIPRESENT state. The changes in 'keymgr_dnskey_hidden_or_chained()' are only cosmetical, renaming 'rrsig_omnipresent' to 'rrsig_chained' and removing the redundant initialization of the DST_KEY_DNSKEY expected state to NA.
2021-01-07 12:12:46 +01:00
next_state, rrsig_chained, na,
false, match_algorithms))
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
{
/* There is no chain of trust. */
return false;
}
}
/* All good. */
return true;
}
/*
* Check for existence of DS.
*
*/
static bool
keymgr_have_ds(dns_dnsseckeylist_t *keyring, dns_dnsseckey_t *key, int type,
Update keymgr to allow transition to insecure mode The keymgr prevented zones from going to insecure mode. If we have a policy with an empty key list this is a signal that the zone wants to go back to insecure mode. In this case allow one extra state transition to be valid when checking for DNSSEC safety.
2020-12-03 16:04:28 +01:00
dst_key_state_t next_state, bool secure_to_insecure) {
Use NUM_KEYSTATES constant where appropriate We use the number 4 a lot when working on key states. Better to use the NUM_KEYSTATES constant instead.
2021-02-01 09:40:44 +01:00
/* (3a) */
dst_key_state_t states[2][NUM_KEYSTATES] = {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/* DNSKEY, ZRRSIG, KRRSIG, DS */
{ NA, NA, NA, OMNIPRESENT }, /* DS present */
{ NA, NA, NA, RUMOURED } /* DS introducing */
};
Use NUM_KEYSTATES constant where appropriate We use the number 4 a lot when working on key states. Better to use the NUM_KEYSTATES constant instead.
2021-02-01 09:40:44 +01:00
/* successor n/a */
dst_key_state_t na[NUM_KEYSTATES] = { NA, NA, NA, NA };
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/*
* Equation (3a):
* There is a key with the DS in either RUMOURD or OMNIPRESENT state.
*/
return keymgr_key_exists_with_state(keyring, key, type, next_state,
states[0], na, false, false) ||
keymgr_key_exists_with_state(keyring, key, type, next_state,
Update keymgr to allow transition to insecure mode The keymgr prevented zones from going to insecure mode. If we have a policy with an empty key list this is a signal that the zone wants to go back to insecure mode. In this case allow one extra state transition to be valid when checking for DNSSEC safety.
2020-12-03 16:04:28 +01:00
states[1], na, false, false) ||
(secure_to_insecure &&
keymgr_key_exists_with_state(keyring, key, type, next_state, na,
na, false, false));
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
}
/*
* Check for existence of DNSKEY, or at least a good DNSKEY state.
* See equations what are good DNSKEY states.
*
*/
static bool
keymgr_have_dnskey(dns_dnsseckeylist_t *keyring, dns_dnsseckey_t *key, int type,
dst_key_state_t next_state) {
Use NUM_KEYSTATES constant where appropriate We use the number 4 a lot when working on key states. Better to use the NUM_KEYSTATES constant instead.
2021-02-01 09:40:44 +01:00
dst_key_state_t states[9][NUM_KEYSTATES] = {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/* DNSKEY, ZRRSIG, KRRSIG, DS */
{ OMNIPRESENT, NA, OMNIPRESENT, OMNIPRESENT }, /* (3b) */
{ OMNIPRESENT, NA, OMNIPRESENT, UNRETENTIVE }, /* (3c)p */
{ OMNIPRESENT, NA, OMNIPRESENT, RUMOURED }, /* (3c)s */
{ UNRETENTIVE, NA, UNRETENTIVE, OMNIPRESENT }, /* (3d)p */
{ OMNIPRESENT, NA, UNRETENTIVE, OMNIPRESENT }, /* (3d)p */
{ UNRETENTIVE, NA, OMNIPRESENT, OMNIPRESENT }, /* (3d)p */
{ RUMOURED, NA, RUMOURED, OMNIPRESENT }, /* (3d)s */
{ OMNIPRESENT, NA, RUMOURED, OMNIPRESENT }, /* (3d)s */
{ RUMOURED, NA, OMNIPRESENT, OMNIPRESENT }, /* (3d)s */
};
Use NUM_KEYSTATES constant where appropriate We use the number 4 a lot when working on key states. Better to use the NUM_KEYSTATES constant instead.
2021-02-01 09:40:44 +01:00
/* successor n/a */
dst_key_state_t na[NUM_KEYSTATES] = { NA, NA, NA, NA };
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
return
/*
* Equation (3b):
* There is a key with the same algorithm with its DNSKEY,
* KRRSIG and DS records in OMNIPRESENT state.
*/
keymgr_key_exists_with_state(keyring, key, type, next_state,
states[0], na, false, true) ||
/*
* Equation (3c):
* There are two or more keys with an OMNIPRESENT DNSKEY and
* the DS records get swapped. These keys must be in a
* successor relation.
*/
keymgr_key_exists_with_state(keyring, key, type, next_state,
states[1], states[2], true,
true) ||
/*
* Equation (3d):
* There are two or more keys with an OMNIPRESENT DS and
* the DNSKEY records and its KRRSIG records get swapped.
* These keys must be in a successor relation. Since the
* state for DNSKEY and KRRSIG move independently, we have
* to check all combinations for DNSKEY and KRRSIG in
* OMNIPRESENT/UNRETENTIVE state for the predecessor, and
* OMNIPRESENT/RUMOURED state for the successor.
*/
keymgr_key_exists_with_state(keyring, key, type, next_state,
states[3], states[6], true,
true) ||
keymgr_key_exists_with_state(keyring, key, type, next_state,
states[3], states[7], true,
true) ||
keymgr_key_exists_with_state(keyring, key, type, next_state,
states[3], states[8], true,
true) ||
keymgr_key_exists_with_state(keyring, key, type, next_state,
states[4], states[6], true,
true) ||
keymgr_key_exists_with_state(keyring, key, type, next_state,
states[4], states[7], true,
true) ||
keymgr_key_exists_with_state(keyring, key, type, next_state,
states[4], states[8], true,
true) ||
keymgr_key_exists_with_state(keyring, key, type, next_state,
states[5], states[6], true,
true) ||
keymgr_key_exists_with_state(keyring, key, type, next_state,
states[5], states[7], true,
true) ||
keymgr_key_exists_with_state(keyring, key, type, next_state,
states[5], states[8], true,
true) ||
/*
* Equation (3e):
* The key may be in any state as long as all keys have their
* DS HIDDEN, or when their DS is not HIDDEN, there must be a
* key with its DS in the same state and its DNSKEY omnipresent.
* In other words, if a DS record for the same algorithm is
* is still available to some validators, there must be a
* chain of trust for those validators.
*/
keymgr_ds_hidden_or_chained(keyring, key, type, next_state,
true, false);
}
/*
* Check for existence of RRSIG (zsk), or a good RRSIG state.
* See equations what are good RRSIG states.
*
*/
static bool
keymgr_have_rrsig(dns_dnsseckeylist_t *keyring, dns_dnsseckey_t *key, int type,
dst_key_state_t next_state) {
Use NUM_KEYSTATES constant where appropriate We use the number 4 a lot when working on key states. Better to use the NUM_KEYSTATES constant instead.
2021-02-01 09:40:44 +01:00
dst_key_state_t states[11][NUM_KEYSTATES] = {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/* DNSKEY, ZRRSIG, KRRSIG, DS */
{ OMNIPRESENT, OMNIPRESENT, NA, NA }, /* (3f) */
{ UNRETENTIVE, OMNIPRESENT, NA, NA }, /* (3g)p */
{ RUMOURED, OMNIPRESENT, NA, NA }, /* (3g)s */
{ OMNIPRESENT, UNRETENTIVE, NA, NA }, /* (3h)p */
{ OMNIPRESENT, RUMOURED, NA, NA }, /* (3h)s */
};
Use NUM_KEYSTATES constant where appropriate We use the number 4 a lot when working on key states. Better to use the NUM_KEYSTATES constant instead.
2021-02-01 09:40:44 +01:00
/* successor n/a */
dst_key_state_t na[NUM_KEYSTATES] = { NA, NA, NA, NA };
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
return
/*
* If all DS records are hidden than this rule can be ignored.
*/
keymgr_ds_hidden_or_chained(keyring, key, type, next_state,
true, true) ||
/*
* Equation (3f):
* There is a key with the same algorithm with its DNSKEY and
* ZRRSIG records in OMNIPRESENT state.
*/
keymgr_key_exists_with_state(keyring, key, type, next_state,
states[0], na, false, true) ||
/*
* Equation (3g):
* There are two or more keys with OMNIPRESENT ZRRSIG
* records and the DNSKEY records get swapped. These keys
* must be in a successor relation.
*/
keymgr_key_exists_with_state(keyring, key, type, next_state,
states[1], states[2], true,
true) ||
/*
* Equation (3h):
* There are two or more keys with an OMNIPRESENT DNSKEY
* and the ZRRSIG records get swapped. These keys must be in
* a successor relation.
*/
keymgr_key_exists_with_state(keyring, key, type, next_state,
states[3], states[4], true,
true) ||
/*
* Equation (3i):
* If no DNSKEYs are published, the state of the signatures is
* irrelevant. In case a DNSKEY is published however, there
* must be a path that can be validated from there.
*/
keymgr_dnskey_hidden_or_chained(keyring, key, type, next_state,
true);
}
/*
* Check if a transition in the state machine is allowed by the policy.
* This means when we do rollovers, we want to follow the rules of the
* 1. Pre-publish rollover method (in case of a ZSK)
* - First introduce the DNSKEY record.
* - Only if the DNSKEY record is OMNIPRESENT, introduce ZRRSIG records.
*
* 2. Double-KSK rollover method (in case of a KSK)
* - First introduce the DNSKEY record, as well as the KRRSIG records.
* - Only if the DNSKEY record is OMNIPRESENT, suggest to introduce the DS.
*/
static bool
keymgr_policy_approval(dns_dnsseckeylist_t *keyring, dns_dnsseckey_t *key,
Fix CDS (non-)publication The CDS/CDNSKEY record will be published when the DS is in the rumoured state. However, with the introduction of the rndc '-checkds' command, the logic in the keymgr was changed to prevent the DS state to go in RUMOURED unless the specific command was given. Hence, the CDS was never published before it was seen in the parent. Initially I thought this was a policy approval rule, however it is actually a DNSSEC timing rule. Remove the restriction from 'keymgr_policy_approval' and update the 'keymgr_transition_time' function. When looking to move the DS state to OMNIPRESENT it will no longer calculate the state from its last change, but from when the DS was seen in the parent, "DS Publish". If the time was not set, default to next key event of an hour. Similarly for moving the DS state to HIDDEN, the time to wait will be derived from the "DS Delete" time, not from when the DS state last changed.
2020-08-27 14:24:50 +02:00
int type, dst_key_state_t next) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
dst_key_state_t dnskeystate = HIDDEN;
Use NUM_KEYSTATES constant where appropriate We use the number 4 a lot when working on key states. Better to use the NUM_KEYSTATES constant instead.
2021-02-01 09:40:44 +01:00
dst_key_state_t ksk_present[NUM_KEYSTATES] = { OMNIPRESENT, NA,
OMNIPRESENT,
OMNIPRESENT };
dst_key_state_t ds_rumoured[NUM_KEYSTATES] = { OMNIPRESENT, NA,
OMNIPRESENT, RUMOURED };
dst_key_state_t ds_retired[NUM_KEYSTATES] = { OMNIPRESENT, NA,
OMNIPRESENT,
UNRETENTIVE };
dst_key_state_t ksk_rumoured[NUM_KEYSTATES] = { RUMOURED, NA, NA,
OMNIPRESENT };
dst_key_state_t ksk_retired[NUM_KEYSTATES] = { UNRETENTIVE, NA, NA,
OMNIPRESENT };
/* successor n/a */
dst_key_state_t na[NUM_KEYSTATES] = { NA, NA, NA, NA };
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
Fix CDS (non-)publication The CDS/CDNSKEY record will be published when the DS is in the rumoured state. However, with the introduction of the rndc '-checkds' command, the logic in the keymgr was changed to prevent the DS state to go in RUMOURED unless the specific command was given. Hence, the CDS was never published before it was seen in the parent. Initially I thought this was a policy approval rule, however it is actually a DNSSEC timing rule. Remove the restriction from 'keymgr_policy_approval' and update the 'keymgr_transition_time' function. When looking to move the DS state to OMNIPRESENT it will no longer calculate the state from its last change, but from when the DS was seen in the parent, "DS Publish". If the time was not set, default to next key event of an hour. Similarly for moving the DS state to HIDDEN, the time to wait will be derived from the "DS Delete" time, not from when the DS state last changed.
2020-08-27 14:24:50 +02:00
if (next != RUMOURED) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/*
* Local policy only adds an extra barrier on transitions to
Cleanup keymgr.c Three small cleanups: 1. Remove an unused keystr/dst_key_format. 2. Initialize a dst_key_state_t state with NA. 3. Update false comment about local policy (local policy only adds barrier on transitions to the RUMOURED state, not the UNRETENTIVE state).
2021-01-07 12:26:53 +01:00
* the RUMOURED state.
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
*/
return true;
}
switch (type) {
case DST_KEY_DNSKEY:
/* No restrictions. */
return true;
case DST_KEY_ZRRSIG:
/* Make sure the DNSKEY record is OMNIPRESENT. */
(void)dst_key_getstate(key->key, DST_KEY_DNSKEY, &dnskeystate);
if (dnskeystate == OMNIPRESENT) {
return true;
}
/*
* Or are we introducing a new key for this algorithm? Because
* in that case allow publishing the RRSIG records before the
* DNSKEY.
*/
return !(keymgr_key_exists_with_state(keyring, key, type, next,
ksk_present, na, false,
true) ||
keymgr_key_exists_with_state(keyring, key, type, next,
ds_retired, ds_rumoured,
true, true) ||
keymgr_key_exists_with_state(keyring, key, type, next,
ksk_retired, ksk_rumoured,
true, true));
case DST_KEY_KRRSIG:
/* Only introduce if the DNSKEY is also introduced. */
(void)dst_key_getstate(key->key, DST_KEY_DNSKEY, &dnskeystate);
return dnskeystate != HIDDEN;
case DST_KEY_DS:
Fix CDS (non-)publication The CDS/CDNSKEY record will be published when the DS is in the rumoured state. However, with the introduction of the rndc '-checkds' command, the logic in the keymgr was changed to prevent the DS state to go in RUMOURED unless the specific command was given. Hence, the CDS was never published before it was seen in the parent. Initially I thought this was a policy approval rule, however it is actually a DNSSEC timing rule. Remove the restriction from 'keymgr_policy_approval' and update the 'keymgr_transition_time' function. When looking to move the DS state to OMNIPRESENT it will no longer calculate the state from its last change, but from when the DS was seen in the parent, "DS Publish". If the time was not set, default to next key event of an hour. Similarly for moving the DS state to HIDDEN, the time to wait will be derived from the "DS Delete" time, not from when the DS state last changed.
2020-08-27 14:24:50 +02:00
/* Make sure the DNSKEY record is OMNIPRESENT. */
(void)dst_key_getstate(key->key, DST_KEY_DNSKEY, &dnskeystate);
return dnskeystate == OMNIPRESENT;
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
default:
return false;
}
}
/*
* Check if a transition in the state machine is DNSSEC safe.
* This implements Equation(1) of "Flexible and Robust Key Rollover".
*
*/
static bool
keymgr_transition_allowed(dns_dnsseckeylist_t *keyring, dns_dnsseckey_t *key,
Update keymgr to allow transition to insecure mode The keymgr prevented zones from going to insecure mode. If we have a policy with an empty key list this is a signal that the zone wants to go back to insecure mode. In this case allow one extra state transition to be valid when checking for DNSSEC safety.
2020-12-03 16:04:28 +01:00
int type, dst_key_state_t next_state,
bool secure_to_insecure) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/* Debug logging. */
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
if (isc_log_wouldlog(ISC_LOG_DEBUG(1))) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
bool rule1a, rule1b, rule2a, rule2b, rule3a, rule3b;
char keystr[DST_KEY_FORMATSIZE];
dst_key_format(key->key, keystr, sizeof(keystr));
Update keymgr to allow transition to insecure mode The keymgr prevented zones from going to insecure mode. If we have a policy with an empty key list this is a signal that the zone wants to go back to insecure mode. In this case allow one extra state transition to be valid when checking for DNSSEC safety.
2020-12-03 16:04:28 +01:00
rule1a = keymgr_have_ds(keyring, key, type, NA,
secure_to_insecure);
rule1b = keymgr_have_ds(keyring, key, type, next_state,
secure_to_insecure);
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
rule2a = keymgr_have_dnskey(keyring, key, type, NA);
rule2b = keymgr_have_dnskey(keyring, key, type, next_state);
rule3a = keymgr_have_rrsig(keyring, key, type, NA);
rule3b = keymgr_have_rrsig(keyring, key, type, next_state);
isc_log_write(
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
ISC_LOG_DEBUG(1),
"keymgr: dnssec evaluation of %s %s record %s: "
"rule1=(~%s or %s) rule2=(~%s or %s) "
"rule3=(~%s or %s)",
keymgr_keyrole(key->key), keystr, keystatetags[type],
rule1a ? "true" : "false", rule1b ? "true" : "false",
rule2a ? "true" : "false", rule2b ? "true" : "false",
rule3a ? "true" : "false", rule3b ? "true" : "false");
}
return
/*
* Rule 1: There must be a DS at all times.
* First check the current situation: if the rule check fails,
* we allow the transition to attempt to move us out of the
* invalid state. If the rule check passes, also check if
* the next state is also still a valid situation.
*/
Update keymgr to allow transition to insecure mode The keymgr prevented zones from going to insecure mode. If we have a policy with an empty key list this is a signal that the zone wants to go back to insecure mode. In this case allow one extra state transition to be valid when checking for DNSSEC safety.
2020-12-03 16:04:28 +01:00
(!keymgr_have_ds(keyring, key, type, NA, secure_to_insecure) ||
keymgr_have_ds(keyring, key, type, next_state,
secure_to_insecure)) &&
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/*
* Rule 2: There must be a DNSKEY at all times. Again, first
* check the current situation, then assess the next state.
*/
(!keymgr_have_dnskey(keyring, key, type, NA) ||
keymgr_have_dnskey(keyring, key, type, next_state)) &&
/*
* Rule 3: There must be RRSIG records at all times. Again,
* first check the current situation, then assess the next
* state.
*/
(!keymgr_have_rrsig(keyring, key, type, NA) ||
keymgr_have_rrsig(keyring, key, type, next_state));
}
/*
* Calculate the time when it is safe to do the next transition.
*
*/
static void
keymgr_transition_time(dns_dnsseckey_t *key, int type,
dst_key_state_t next_state, dns_kasp_t *kasp,
isc_stdtime_t now, isc_stdtime_t *when) {
isc_result_t ret;
Fix CDS (non-)publication The CDS/CDNSKEY record will be published when the DS is in the rumoured state. However, with the introduction of the rndc '-checkds' command, the logic in the keymgr was changed to prevent the DS state to go in RUMOURED unless the specific command was given. Hence, the CDS was never published before it was seen in the parent. Initially I thought this was a policy approval rule, however it is actually a DNSSEC timing rule. Remove the restriction from 'keymgr_policy_approval' and update the 'keymgr_transition_time' function. When looking to move the DS state to OMNIPRESENT it will no longer calculate the state from its last change, but from when the DS was seen in the parent, "DS Publish". If the time was not set, default to next key event of an hour. Similarly for moving the DS state to HIDDEN, the time to wait will be derived from the "DS Delete" time, not from when the DS state last changed.
2020-08-27 14:24:50 +02:00
isc_stdtime_t lastchange, dstime, nexttime = now;
Ignore max-zone-ttl on dnssec-policy insecure Allow larger TTL values in zones that go insecure. This is necessary because otherwise the zone will not be loaded due to the max-zone-ttl of P1D that is part of the current insecure policy. In the keymgr.c code, default back to P1D if the max-zone-ttl is set to zero.
2023-07-26 11:50:57 +02:00
dns_ttl_t ttlsig = dns_kasp_zonemaxttl(kasp, true);
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/*
* No need to wait if we move things into an uncertain state.
*/
if (next_state == RUMOURED || next_state == UNRETENTIVE) {
*when = now;
return;
}
ret = dst_key_gettime(key->key, keystatetimes[type], &lastchange);
if (ret != ISC_R_SUCCESS) {
/* No last change, for safety purposes let's set it to now. */
dst_key_settime(key->key, keystatetimes[type], now);
lastchange = now;
}
switch (type) {
case DST_KEY_DNSKEY:
case DST_KEY_KRRSIG:
switch (next_state) {
case OMNIPRESENT:
/*
* RFC 7583: The publication interval (Ipub) is the
* amount of time that must elapse after the
* publication of a DNSKEY (plus RRSIG (KSK)) before
* it can be assumed that any resolvers that have the
* relevant RRset cached have a copy of the new
* information. This is the sum of the propagation
* delay (Dprp) and the DNSKEY TTL (TTLkey). This
* translates to zone-propagation-delay + dnskey-ttl.
* We will also add the publish-safety interval.
*/
nexttime = lastchange + dst_key_getttl(key->key) +
dns_kasp_zonepropagationdelay(kasp) +
dns_kasp_publishsafety(kasp);
break;
case HIDDEN:
/*
* Same as OMNIPRESENT but without the publish-safety
* interval.
*/
nexttime = lastchange + dst_key_getttl(key->key) +
dns_kasp_zonepropagationdelay(kasp);
break;
default:
nexttime = now;
break;
}
break;
case DST_KEY_ZRRSIG:
switch (next_state) {
case OMNIPRESENT:
case HIDDEN:
/*
* RFC 7583: The retire interval (Iret) is the amount
* of time that must elapse after a DNSKEY or
* associated data enters the retire state for any
* dependent information (RRSIG ZSK) to be purged from
* validating resolver caches. This is defined as:
*
* Iret = Dsgn + Dprp + TTLsig
*
* Where Dsgn is the Dsgn is the delay needed to
* ensure that all existing RRsets have been re-signed
* with the new key, Dprp is the propagation delay and
* TTLsig is the maximum TTL of all zone RRSIG
* records. This translates to:
*
[#1625] Algorithm rollover waited too long Algorithm rollover waited too long before introducing zone signatures. It waited to make sure all signatures were resigned, but when introducing a new algorithm, all signatures are resigned immediately. Only add the sign delay if there is a predecessor key.
2020-02-18 16:57:37 +01:00
* Dsgn + zone-propagation-delay + max-zone-ttl.
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
*
* We will also add the retire-safety interval.
*/
Ignore max-zone-ttl on dnssec-policy insecure Allow larger TTL values in zones that go insecure. This is necessary because otherwise the zone will not be loaded due to the max-zone-ttl of P1D that is part of the current insecure policy. In the keymgr.c code, default back to P1D if the max-zone-ttl is set to zero.
2023-07-26 11:50:57 +02:00
nexttime = lastchange + ttlsig +
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
dns_kasp_zonepropagationdelay(kasp) +
dns_kasp_retiresafety(kasp);
[#1625] Algorithm rollover waited too long Algorithm rollover waited too long before introducing zone signatures. It waited to make sure all signatures were resigned, but when introducing a new algorithm, all signatures are resigned immediately. Only add the sign delay if there is a predecessor key.
2020-02-18 16:57:37 +01:00
/*
* Only add the sign delay Dsgn if there is an actual
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
* predecessor or successor key.
[#1625] Algorithm rollover waited too long Algorithm rollover waited too long before introducing zone signatures. It waited to make sure all signatures were resigned, but when introducing a new algorithm, all signatures are resigned immediately. Only add the sign delay if there is a predecessor key.
2020-02-18 16:57:37 +01:00
*/
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
uint32_t tag;
ret = dst_key_getnum(key->key, DST_NUM_PREDECESSOR,
&tag);
if (ret != ISC_R_SUCCESS) {
ret = dst_key_getnum(key->key,
DST_NUM_SUCCESSOR, &tag);
}
if (ret == ISC_R_SUCCESS) {
[#1625] Algorithm rollover waited too long Algorithm rollover waited too long before introducing zone signatures. It waited to make sure all signatures were resigned, but when introducing a new algorithm, all signatures are resigned immediately. Only add the sign delay if there is a predecessor key.
2020-02-18 16:57:37 +01:00
nexttime += dns_kasp_signdelay(kasp);
}
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
break;
default:
nexttime = now;
break;
}
break;
case DST_KEY_DS:
switch (next_state) {
Fix CDS (non-)publication The CDS/CDNSKEY record will be published when the DS is in the rumoured state. However, with the introduction of the rndc '-checkds' command, the logic in the keymgr was changed to prevent the DS state to go in RUMOURED unless the specific command was given. Hence, the CDS was never published before it was seen in the parent. Initially I thought this was a policy approval rule, however it is actually a DNSSEC timing rule. Remove the restriction from 'keymgr_policy_approval' and update the 'keymgr_transition_time' function. When looking to move the DS state to OMNIPRESENT it will no longer calculate the state from its last change, but from when the DS was seen in the parent, "DS Publish". If the time was not set, default to next key event of an hour. Similarly for moving the DS state to HIDDEN, the time to wait will be derived from the "DS Delete" time, not from when the DS state last changed.
2020-08-27 14:24:50 +02:00
/*
* RFC 7583: The successor DS record is published in
* the parent zone and after the registration delay
* (Dreg), the time taken after the DS record has been
* submitted to the parent zone manager for it to be
* placed in the zone. Key N (the predecessor) must
* remain in the zone until any caches that contain a
* copy of the DS RRset have a copy containing the new
* DS record. This interval is the retire interval
* (Iret), given by:
*
* Iret = DprpP + TTLds
*
* This translates to:
*
* parent-propagation-delay + parent-ds-ttl.
*
* We will also add the retire-safety interval.
*/
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
case OMNIPRESENT:
Fix CDS (non-)publication The CDS/CDNSKEY record will be published when the DS is in the rumoured state. However, with the introduction of the rndc '-checkds' command, the logic in the keymgr was changed to prevent the DS state to go in RUMOURED unless the specific command was given. Hence, the CDS was never published before it was seen in the parent. Initially I thought this was a policy approval rule, however it is actually a DNSSEC timing rule. Remove the restriction from 'keymgr_policy_approval' and update the 'keymgr_transition_time' function. When looking to move the DS state to OMNIPRESENT it will no longer calculate the state from its last change, but from when the DS was seen in the parent, "DS Publish". If the time was not set, default to next key event of an hour. Similarly for moving the DS state to HIDDEN, the time to wait will be derived from the "DS Delete" time, not from when the DS state last changed.
2020-08-27 14:24:50 +02:00
/* Make sure DS has been seen in the parent. */
ret = dst_key_gettime(key->key, DST_TIME_DSPUBLISH,
&dstime);
if (ret != ISC_R_SUCCESS || dstime > now) {
/* Not yet, try again in an hour. */
nexttime = now + 3600;
} else {
nexttime =
dstime + dns_kasp_dsttl(kasp) +
dns_kasp_parentpropagationdelay(kasp) +
dns_kasp_retiresafety(kasp);
}
break;
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
case HIDDEN:
Fix CDS (non-)publication The CDS/CDNSKEY record will be published when the DS is in the rumoured state. However, with the introduction of the rndc '-checkds' command, the logic in the keymgr was changed to prevent the DS state to go in RUMOURED unless the specific command was given. Hence, the CDS was never published before it was seen in the parent. Initially I thought this was a policy approval rule, however it is actually a DNSSEC timing rule. Remove the restriction from 'keymgr_policy_approval' and update the 'keymgr_transition_time' function. When looking to move the DS state to OMNIPRESENT it will no longer calculate the state from its last change, but from when the DS was seen in the parent, "DS Publish". If the time was not set, default to next key event of an hour. Similarly for moving the DS state to HIDDEN, the time to wait will be derived from the "DS Delete" time, not from when the DS state last changed.
2020-08-27 14:24:50 +02:00
/* Make sure DS has been withdrawn from the parent. */
ret = dst_key_gettime(key->key, DST_TIME_DSDELETE,
&dstime);
if (ret != ISC_R_SUCCESS || dstime > now) {
/* Not yet, try again in an hour. */
nexttime = now + 3600;
} else {
nexttime =
dstime + dns_kasp_dsttl(kasp) +
dns_kasp_parentpropagationdelay(kasp) +
dns_kasp_retiresafety(kasp);
}
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
break;
default:
nexttime = now;
break;
}
break;
default:
Simplify way we tag unreachable code with only ISC_UNREACHABLE() Previously, the unreachable code paths would have to be tagged with: INSIST(0); ISC_UNREACHABLE(); There was also older parts of the code that used comment annotation: /* NOTREACHED */ Unify the handling of unreachable code paths to just use: UNREACHABLE(); The UNREACHABLE() macro now asserts when reached and also uses __builtin_unreachable(); when such builtin is available in the compiler.
2021-10-11 12:50:17 +02:00
UNREACHABLE();
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
break;
}
*when = nexttime;
}
/*
* Update keys.
* This implements Algorithm (1) of "Flexible and Robust Key Rollover".
*
*/
static isc_result_t
keymgr_update(dns_dnsseckeylist_t *keyring, dns_kasp_t *kasp, isc_stdtime_t now,
Update keymgr to allow transition to insecure mode The keymgr prevented zones from going to insecure mode. If we have a policy with an empty key list this is a signal that the zone wants to go back to insecure mode. In this case allow one extra state transition to be valid when checking for DNSSEC safety.
2020-12-03 16:04:28 +01:00
isc_stdtime_t *nexttime, bool secure_to_insecure) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
bool changed;
/* Repeat until nothing changed. */
transition:
changed = false;
/* For all keys in the zone. */
for (dns_dnsseckey_t *dkey = ISC_LIST_HEAD(*keyring); dkey != NULL;
dkey = ISC_LIST_NEXT(dkey, link))
{
char keystr[DST_KEY_FORMATSIZE];
dst_key_format(dkey->key, keystr, sizeof(keystr));
Small keymgr improvement When a key is to be purged, don't run the key state machinery for it.
2024-08-19 09:49:21 +02:00
if (dkey->purge) {
/* Skip purged keys. */
continue;
}
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/* For all records related to this key. */
for (int i = 0; i < NUM_KEYSTATES; i++) {
isc_result_t ret;
isc_stdtime_t when;
dst_key_state_t state, next_state;
ret = dst_key_getstate(dkey->key, i, &state);
if (ret == ISC_R_NOTFOUND) {
/*
* This record type is not applicable for this
* key, continue to the next record type.
*/
continue;
}
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
DNS_LOGMODULE_DNSSEC, ISC_LOG_DEBUG(1),
"keymgr: examine %s %s type %s "
"in state %s",
keymgr_keyrole(dkey->key), keystr,
keystatetags[i], keystatestrings[state]);
/* Get the desired next state. */
next_state = keymgr_desiredstate(dkey, state);
if (state == next_state) {
/*
* This record is in a stable state.
* No change needed, continue with the next
* record type.
*/
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
DNS_LOGMODULE_DNSSEC,
ISC_LOG_DEBUG(1),
"keymgr: %s %s type %s in "
"stable state %s",
keymgr_keyrole(dkey->key), keystr,
keystatetags[i],
keystatestrings[state]);
continue;
}
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
DNS_LOGMODULE_DNSSEC, ISC_LOG_DEBUG(1),
"keymgr: can we transition %s %s type %s "
"state %s to state %s?",
keymgr_keyrole(dkey->key), keystr,
keystatetags[i], keystatestrings[state],
keystatestrings[next_state]);
/* Is the transition allowed according to policy? */
if (!keymgr_policy_approval(keyring, dkey, i,
Update sources to Clang 15 formatting
2022-11-02 19:33:14 +01:00
next_state))
{
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/* No, please respect rollover methods. */
isc_log_write(
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
DNS_LOGCATEGORY_DNSSEC,
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
DNS_LOGMODULE_DNSSEC, ISC_LOG_DEBUG(1),
"keymgr: policy says no to %s %s type "
"%s "
"state %s to state %s",
keymgr_keyrole(dkey->key), keystr,
keystatetags[i], keystatestrings[state],
keystatestrings[next_state]);
continue;
}
/* Is the transition DNSSEC safe? */
if (!keymgr_transition_allowed(keyring, dkey, i,
Update keymgr to allow transition to insecure mode The keymgr prevented zones from going to insecure mode. If we have a policy with an empty key list this is a signal that the zone wants to go back to insecure mode. In this case allow one extra state transition to be valid when checking for DNSSEC safety.
2020-12-03 16:04:28 +01:00
next_state,
secure_to_insecure))
{
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/* No, this would make the zone bogus. */
isc_log_write(
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
DNS_LOGCATEGORY_DNSSEC,
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
DNS_LOGMODULE_DNSSEC, ISC_LOG_DEBUG(1),
"keymgr: dnssec says no to %s %s type "
"%s "
"state %s to state %s",
keymgr_keyrole(dkey->key), keystr,
keystatetags[i], keystatestrings[state],
keystatestrings[next_state]);
continue;
}
/* Is it time to make the transition? */
when = now;
keymgr_transition_time(dkey, i, next_state, kasp, now,
&when);
if (when > now) {
/* Not yet. */
isc_log_write(
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
DNS_LOGCATEGORY_DNSSEC,
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
DNS_LOGMODULE_DNSSEC, ISC_LOG_DEBUG(1),
"keymgr: time says no to %s %s type %s "
"state %s to state %s (wait %u "
"seconds)",
keymgr_keyrole(dkey->key), keystr,
keystatetags[i], keystatestrings[state],
keystatestrings[next_state],
when - now);
if (*nexttime == 0 || *nexttime > when) {
*nexttime = when;
}
continue;
}
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
DNS_LOGMODULE_DNSSEC, ISC_LOG_DEBUG(1),
"keymgr: transition %s %s type %s "
"state %s to state %s!",
keymgr_keyrole(dkey->key), keystr,
keystatetags[i], keystatestrings[state],
keystatestrings[next_state]);
/* It is safe to make the transition. */
dst_key_setstate(dkey->key, i, next_state);
dst_key_settime(dkey->key, keystatetimes[i], now);
Check if key metadata is modified before writing Add a new parameter to the dst_key structure, mark a key modified if dst_key_(un)set[bool,num,state,time] is called. Only write out key files during a keymgr run if the metadata has changed.
2022-05-03 12:28:31 +02:00
INSIST(dst_key_ismodified(dkey->key));
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
changed = true;
}
}
/* We changed something, continue processing. */
if (changed) {
goto transition;
}
return ISC_R_SUCCESS;
}
/*
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
* See if this key needs to be initialized with properties. A key created
* and derived from a dnssec-policy will have the required metadata available,
* otherwise these may be missing and need to be initialized. The key states
* will be initialized according to existing timing metadata.
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
*
*/
static void
Migrate a single key to CSK with dnssec-policy When migrating keys to dnssec-policy, if a zone has only one key, assume it is going to be a CSK.
2021-08-16 11:12:36 +02:00
keymgr_key_init(dns_dnsseckey_t *key, dns_kasp_t *kasp, isc_stdtime_t now,
bool csk) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
bool ksk, zsk;
isc_result_t ret;
Correctly initialize old key with state file The 'key_init()' function is used to initialize a state file for keys that don't have one yet. This can happen if you are migrating from a 'auto-dnssec' or 'inline-signing' to a 'dnssec-policy' configuration. It did not look at the "Inactive" and "Delete" timing metadata and so old keys left behind in the key directory would also be considered as a possible active key. This commit fixes this and now explicitly sets the key goal to OMNIPRESENT for keys that have their "Active/Publish" timing metadata in the past, but their "Inactive/Delete" timing metadata in the future. If the "Inactive/Delete" timing metadata is also in the past, the key goal is set to HIDDEN. If the "Inactive/Delete" timing metadata is in the past, also the key states are adjusted to either UNRETENTIVE or HIDDEN, depending on how far in the past the metadata is set.
2021-01-26 11:32:24 +01:00
isc_stdtime_t active = 0, pub = 0, syncpub = 0, retire = 0, remove = 0;
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
dst_key_state_t dnskey_state = HIDDEN;
dst_key_state_t ds_state = HIDDEN;
dst_key_state_t zrrsig_state = HIDDEN;
Correctly initialize old key with state file The 'key_init()' function is used to initialize a state file for keys that don't have one yet. This can happen if you are migrating from a 'auto-dnssec' or 'inline-signing' to a 'dnssec-policy' configuration. It did not look at the "Inactive" and "Delete" timing metadata and so old keys left behind in the key directory would also be considered as a possible active key. This commit fixes this and now explicitly sets the key goal to OMNIPRESENT for keys that have their "Active/Publish" timing metadata in the past, but their "Inactive/Delete" timing metadata in the future. If the "Inactive/Delete" timing metadata is also in the past, the key goal is set to HIDDEN. If the "Inactive/Delete" timing metadata is in the past, also the key states are adjusted to either UNRETENTIVE or HIDDEN, depending on how far in the past the metadata is set.
2021-01-26 11:32:24 +01:00
dst_key_state_t goal_state = HIDDEN;
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
REQUIRE(key != NULL);
REQUIRE(key->key != NULL);
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
/* Initialize role. */
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
ret = dst_key_getbool(key->key, DST_BOOL_KSK, &ksk);
if (ret != ISC_R_SUCCESS) {
ksk = ((dst_key_flags(key->key) & DNS_KEYFLAG_KSK) != 0);
Migrate a single key to CSK with dnssec-policy When migrating keys to dnssec-policy, if a zone has only one key, assume it is going to be a CSK.
2021-08-16 11:12:36 +02:00
dst_key_setbool(key->key, DST_BOOL_KSK, (ksk || csk));
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
}
ret = dst_key_getbool(key->key, DST_BOOL_ZSK, &zsk);
if (ret != ISC_R_SUCCESS) {
zsk = ((dst_key_flags(key->key) & DNS_KEYFLAG_KSK) == 0);
Migrate a single key to CSK with dnssec-policy When migrating keys to dnssec-policy, if a zone has only one key, assume it is going to be a CSK.
2021-08-16 11:12:36 +02:00
dst_key_setbool(key->key, DST_BOOL_ZSK, (zsk || csk));
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
}
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
/* Get time metadata. */
ret = dst_key_gettime(key->key, DST_TIME_ACTIVATE, &active);
if (active <= now && ret == ISC_R_SUCCESS) {
Ignore max-zone-ttl on dnssec-policy insecure Allow larger TTL values in zones that go insecure. This is necessary because otherwise the zone will not be loaded due to the max-zone-ttl of P1D that is part of the current insecure policy. In the keymgr.c code, default back to P1D if the max-zone-ttl is set to zero.
2023-07-26 11:50:57 +02:00
dns_ttl_t ttlsig = dns_kasp_zonemaxttl(kasp, true);
ttlsig += dns_kasp_zonepropagationdelay(kasp);
if ((active + ttlsig) <= now) {
Fix keymgr key init bug The 'keymgr_key_init()' function initializes key states if they have not been set previously. It looks at the key timing metadata and determines using the given times whether a state should be set to RUMOURED or OMNIPRESENT. However, the DNSKEY and ZRRSIG states were mixed up: When looking at the Activate timing metadata we should set the ZRRSIG state, and when looking at the Published timing metadata we should set the DNSKEY state.
2021-02-26 09:27:32 +01:00
zrrsig_state = OMNIPRESENT;
Test migration to dnssec-policy, retire old keys 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.
2020-04-01 14:29:49 +02:00
} else {
Fix keymgr key init bug The 'keymgr_key_init()' function initializes key states if they have not been set previously. It looks at the key timing metadata and determines using the given times whether a state should be set to RUMOURED or OMNIPRESENT. However, the DNSKEY and ZRRSIG states were mixed up: When looking at the Activate timing metadata we should set the ZRRSIG state, and when looking at the Published timing metadata we should set the DNSKEY state.
2021-02-26 09:27:32 +01:00
zrrsig_state = RUMOURED;
Test migration to dnssec-policy, retire old keys 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.
2020-04-01 14:29:49 +02:00
}
Correctly initialize old key with state file The 'key_init()' function is used to initialize a state file for keys that don't have one yet. This can happen if you are migrating from a 'auto-dnssec' or 'inline-signing' to a 'dnssec-policy' configuration. It did not look at the "Inactive" and "Delete" timing metadata and so old keys left behind in the key directory would also be considered as a possible active key. This commit fixes this and now explicitly sets the key goal to OMNIPRESENT for keys that have their "Active/Publish" timing metadata in the past, but their "Inactive/Delete" timing metadata in the future. If the "Inactive/Delete" timing metadata is also in the past, the key goal is set to HIDDEN. If the "Inactive/Delete" timing metadata is in the past, also the key states are adjusted to either UNRETENTIVE or HIDDEN, depending on how far in the past the metadata is set.
2021-01-26 11:32:24 +01:00
goal_state = OMNIPRESENT;
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
}
ret = dst_key_gettime(key->key, DST_TIME_PUBLISH, &pub);
if (pub <= now && ret == ISC_R_SUCCESS) {
Fix keymgr key init bug The 'keymgr_key_init()' function initializes key states if they have not been set previously. It looks at the key timing metadata and determines using the given times whether a state should be set to RUMOURED or OMNIPRESENT. However, the DNSKEY and ZRRSIG states were mixed up: When looking at the Activate timing metadata we should set the ZRRSIG state, and when looking at the Published timing metadata we should set the DNSKEY state.
2021-02-26 09:27:32 +01:00
dns_ttl_t key_ttl = dst_key_getttl(key->key);
key_ttl += dns_kasp_zonepropagationdelay(kasp);
if ((pub + key_ttl) <= now) {
dnskey_state = OMNIPRESENT;
Test migration to dnssec-policy, retire old keys 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.
2020-04-01 14:29:49 +02:00
} else {
Fix keymgr key init bug The 'keymgr_key_init()' function initializes key states if they have not been set previously. It looks at the key timing metadata and determines using the given times whether a state should be set to RUMOURED or OMNIPRESENT. However, the DNSKEY and ZRRSIG states were mixed up: When looking at the Activate timing metadata we should set the ZRRSIG state, and when looking at the Published timing metadata we should set the DNSKEY state.
2021-02-26 09:27:32 +01:00
dnskey_state = RUMOURED;
Test migration to dnssec-policy, retire old keys 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.
2020-04-01 14:29:49 +02:00
}
Correctly initialize old key with state file The 'key_init()' function is used to initialize a state file for keys that don't have one yet. This can happen if you are migrating from a 'auto-dnssec' or 'inline-signing' to a 'dnssec-policy' configuration. It did not look at the "Inactive" and "Delete" timing metadata and so old keys left behind in the key directory would also be considered as a possible active key. This commit fixes this and now explicitly sets the key goal to OMNIPRESENT for keys that have their "Active/Publish" timing metadata in the past, but their "Inactive/Delete" timing metadata in the future. If the "Inactive/Delete" timing metadata is also in the past, the key goal is set to HIDDEN. If the "Inactive/Delete" timing metadata is in the past, also the key states are adjusted to either UNRETENTIVE or HIDDEN, depending on how far in the past the metadata is set.
2021-01-26 11:32:24 +01:00
goal_state = OMNIPRESENT;
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
}
ret = dst_key_gettime(key->key, DST_TIME_SYNCPUBLISH, &syncpub);
if (syncpub <= now && ret == ISC_R_SUCCESS) {
Test migration to dnssec-policy, retire old keys 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.
2020-04-01 14:29:49 +02:00
dns_ttl_t ds_ttl = dns_kasp_dsttl(kasp);
ds_ttl += dns_kasp_parentpropagationdelay(kasp);
if ((syncpub + ds_ttl) <= now) {
ds_state = OMNIPRESENT;
} else {
ds_state = RUMOURED;
}
Correctly initialize old key with state file The 'key_init()' function is used to initialize a state file for keys that don't have one yet. This can happen if you are migrating from a 'auto-dnssec' or 'inline-signing' to a 'dnssec-policy' configuration. It did not look at the "Inactive" and "Delete" timing metadata and so old keys left behind in the key directory would also be considered as a possible active key. This commit fixes this and now explicitly sets the key goal to OMNIPRESENT for keys that have their "Active/Publish" timing metadata in the past, but their "Inactive/Delete" timing metadata in the future. If the "Inactive/Delete" timing metadata is also in the past, the key goal is set to HIDDEN. If the "Inactive/Delete" timing metadata is in the past, also the key states are adjusted to either UNRETENTIVE or HIDDEN, depending on how far in the past the metadata is set.
2021-01-26 11:32:24 +01:00
goal_state = OMNIPRESENT;
}
ret = dst_key_gettime(key->key, DST_TIME_INACTIVE, &retire);
if (retire <= now && ret == ISC_R_SUCCESS) {
Ignore max-zone-ttl on dnssec-policy insecure Allow larger TTL values in zones that go insecure. This is necessary because otherwise the zone will not be loaded due to the max-zone-ttl of P1D that is part of the current insecure policy. In the keymgr.c code, default back to P1D if the max-zone-ttl is set to zero.
2023-07-26 11:50:57 +02:00
dns_ttl_t ttlsig = dns_kasp_zonemaxttl(kasp, true);
ttlsig += dns_kasp_zonepropagationdelay(kasp);
if ((retire + ttlsig) <= now) {
Correctly initialize old key with state file The 'key_init()' function is used to initialize a state file for keys that don't have one yet. This can happen if you are migrating from a 'auto-dnssec' or 'inline-signing' to a 'dnssec-policy' configuration. It did not look at the "Inactive" and "Delete" timing metadata and so old keys left behind in the key directory would also be considered as a possible active key. This commit fixes this and now explicitly sets the key goal to OMNIPRESENT for keys that have their "Active/Publish" timing metadata in the past, but their "Inactive/Delete" timing metadata in the future. If the "Inactive/Delete" timing metadata is also in the past, the key goal is set to HIDDEN. If the "Inactive/Delete" timing metadata is in the past, also the key states are adjusted to either UNRETENTIVE or HIDDEN, depending on how far in the past the metadata is set.
2021-01-26 11:32:24 +01:00
zrrsig_state = HIDDEN;
} else {
zrrsig_state = UNRETENTIVE;
}
ds_state = UNRETENTIVE;
goal_state = HIDDEN;
}
ret = dst_key_gettime(key->key, DST_TIME_DELETE, &remove);
if (remove <= now && ret == ISC_R_SUCCESS) {
dns_ttl_t key_ttl = dst_key_getttl(key->key);
key_ttl += dns_kasp_zonepropagationdelay(kasp);
if ((remove + key_ttl) <= now) {
dnskey_state = HIDDEN;
} else {
dnskey_state = UNRETENTIVE;
}
zrrsig_state = HIDDEN;
ds_state = HIDDEN;
goal_state = HIDDEN;
}
/* Set goal if not already set. */
if (dst_key_getstate(key->key, DST_KEY_GOAL, &goal_state) !=
Update sources to Clang 15 formatting
2022-11-02 19:33:14 +01:00
ISC_R_SUCCESS)
{
Correctly initialize old key with state file The 'key_init()' function is used to initialize a state file for keys that don't have one yet. This can happen if you are migrating from a 'auto-dnssec' or 'inline-signing' to a 'dnssec-policy' configuration. It did not look at the "Inactive" and "Delete" timing metadata and so old keys left behind in the key directory would also be considered as a possible active key. This commit fixes this and now explicitly sets the key goal to OMNIPRESENT for keys that have their "Active/Publish" timing metadata in the past, but their "Inactive/Delete" timing metadata in the future. If the "Inactive/Delete" timing metadata is also in the past, the key goal is set to HIDDEN. If the "Inactive/Delete" timing metadata is in the past, also the key states are adjusted to either UNRETENTIVE or HIDDEN, depending on how far in the past the metadata is set.
2021-01-26 11:32:24 +01:00
dst_key_setstate(key->key, DST_KEY_GOAL, goal_state);
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
}
/* Set key states for all keys that do not have them. */
INITIALIZE_STATE(key->key, DST_KEY_DNSKEY, DST_TIME_DNSKEY,
Address Coverity warnings in keymgr.c Coverity showed that the return value of `dst_key_gettime` was unchecked in INITIALIZE_STATE. If DST_TIME_CREATED was not set we would set the state to be initialized to a weird last changed time. This would normally not happen because DST_TIME_CREATED is always set. However, we would rather set the time to now (as the comment also indicates) not match the creation time. The comment on INITIALIZE_STATE also needs updating as we no longer always initialize to HIDDEN.
2020-04-06 09:59:18 +02:00
dnskey_state, now);
Migrate a single key to CSK with dnssec-policy When migrating keys to dnssec-policy, if a zone has only one key, assume it is going to be a CSK.
2021-08-16 11:12:36 +02:00
if (ksk || csk) {
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
INITIALIZE_STATE(key->key, DST_KEY_KRRSIG, DST_TIME_KRRSIG,
Address Coverity warnings in keymgr.c Coverity showed that the return value of `dst_key_gettime` was unchecked in INITIALIZE_STATE. If DST_TIME_CREATED was not set we would set the state to be initialized to a weird last changed time. This would normally not happen because DST_TIME_CREATED is always set. However, we would rather set the time to now (as the comment also indicates) not match the creation time. The comment on INITIALIZE_STATE also needs updating as we no longer always initialize to HIDDEN.
2020-04-06 09:59:18 +02:00
dnskey_state, now);
INITIALIZE_STATE(key->key, DST_KEY_DS, DST_TIME_DS, ds_state,
now);
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
}
Migrate a single key to CSK with dnssec-policy When migrating keys to dnssec-policy, if a zone has only one key, assume it is going to be a CSK.
2021-08-16 11:12:36 +02:00
if (zsk || csk) {
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
INITIALIZE_STATE(key->key, DST_KEY_ZRRSIG, DST_TIME_ZRRSIG,
Address Coverity warnings in keymgr.c Coverity showed that the return value of `dst_key_gettime` was unchecked in INITIALIZE_STATE. If DST_TIME_CREATED was not set we would set the state to be initialized to a weird last changed time. This would normally not happen because DST_TIME_CREATED is always set. However, we would rather set the time to now (as the comment also indicates) not match the creation time. The comment on INITIALIZE_STATE also needs updating as we no longer always initialize to HIDDEN.
2020-04-06 09:59:18 +02:00
zrrsig_state, now);
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
}
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
}
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
static isc_result_t
keymgr_key_rollover(dns_kasp_key_t *kaspkey, dns_dnsseckey_t *active_key,
dns_dnsseckeylist_t *keyring, dns_dnsseckeylist_t *newkeys,
const dns_name_t *origin, dns_rdataclass_t rdclass,
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
dns_kasp_t *kasp, const char *keydir, uint32_t lifetime,
bool rollover, isc_stdtime_t now, isc_stdtime_t *nexttime,
Don't roll offline keys When checking the current DNSSEC state against the policy, consider offline keys. If we didn't found an active key, check if the key is offline by checking the public key list. If there is a match in the public key list (the key data is retrieved from the .key and the .state files), treat the key as offline and don't create a successor key for it.
2021-04-12 14:40:46 +02:00
isc_mem_t *mctx) {
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
char keystr[DST_KEY_FORMATSIZE];
isc_stdtime_t retire = 0, active = 0, prepub = 0;
dns_dnsseckey_t *new_key = NULL;
dns_dnsseckey_t *candidate = NULL;
dst_key_t *dst_key = NULL;
/* Do we need to create a successor for the active key? */
if (active_key != NULL) {
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
if (isc_log_wouldlog(ISC_LOG_DEBUG(1))) {
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
dst_key_format(active_key->key, keystr, sizeof(keystr));
isc_log_write(
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
ISC_LOG_DEBUG(1),
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
"keymgr: DNSKEY %s (%s) is active in policy %s",
keystr, keymgr_keyrole(active_key->key),
dns_kasp_getname(kasp));
}
/*
* Calculate when the successor needs to be published
* in the zone.
*/
prepub = keymgr_prepublication_time(active_key, kasp, lifetime,
now);
Only log "new successor in ..." if prepub != 0 If 'prepub' is 0, this has the special meaning that no rollover is scheduled. If so, don't log "new successor in x seconds".
2022-05-10 10:25:27 +02:00
if (prepub > now) {
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
if (isc_log_wouldlog(ISC_LOG_DEBUG(1))) {
Retire predecessor when creating successor When creating the successor, the current active key (predecessor) should change its goal state to HIDDEN. Also add two useful debug logs in the keymgr_key_rollover function.
2020-05-14 15:39:57 +02:00
dst_key_format(active_key->key, keystr,
sizeof(keystr));
isc_log_write(
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
DNS_LOGCATEGORY_DNSSEC,
Retire predecessor when creating successor When creating the successor, the current active key (predecessor) should change its goal state to HIDDEN. Also add two useful debug logs in the keymgr_key_rollover function.
2020-05-14 15:39:57 +02:00
DNS_LOGMODULE_DNSSEC, ISC_LOG_DEBUG(1),
"keymgr: new successor needed for "
"DNSKEY %s (%s) (policy %s) in %u "
"seconds",
keystr, keymgr_keyrole(active_key->key),
dns_kasp_getname(kasp), (prepub - now));
}
Only log "new successor in ..." if prepub != 0 If 'prepub' is 0, this has the special meaning that no rollover is scheduled. If so, don't log "new successor in x seconds".
2022-05-10 10:25:27 +02:00
}
if (prepub == 0 || prepub > now) {
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
/* No need to start rollover now. */
if (*nexttime == 0 || prepub < *nexttime) {
*nexttime = prepub;
}
return ISC_R_SUCCESS;
}
if (keymgr_key_has_successor(active_key, keyring)) {
/* Key already has successor. */
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
if (isc_log_wouldlog(ISC_LOG_DEBUG(1))) {
Retire predecessor when creating successor When creating the successor, the current active key (predecessor) should change its goal state to HIDDEN. Also add two useful debug logs in the keymgr_key_rollover function.
2020-05-14 15:39:57 +02:00
dst_key_format(active_key->key, keystr,
sizeof(keystr));
isc_log_write(
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
DNS_LOGCATEGORY_DNSSEC,
Retire predecessor when creating successor When creating the successor, the current active key (predecessor) should change its goal state to HIDDEN. Also add two useful debug logs in the keymgr_key_rollover function.
2020-05-14 15:39:57 +02:00
DNS_LOGMODULE_DNSSEC, ISC_LOG_DEBUG(1),
"keymgr: key DNSKEY %s (%s) (policy "
"%s) already has successor",
keystr, keymgr_keyrole(active_key->key),
dns_kasp_getname(kasp));
}
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
return ISC_R_SUCCESS;
}
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
if (isc_log_wouldlog(ISC_LOG_DEBUG(1))) {
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
dst_key_format(active_key->key, keystr, sizeof(keystr));
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
DNS_LOGMODULE_DNSSEC, ISC_LOG_DEBUG(1),
"keymgr: need successor for DNSKEY %s "
"(%s) (policy %s)",
keystr, keymgr_keyrole(active_key->key),
dns_kasp_getname(kasp));
}
Fix coverity issue 331478 Move the "cannot start rollover" warning into code block that checks if 'active_key' is not NULL.
2021-05-17 14:06:46 +02:00
/*
* If rollover is not allowed, warn.
*/
if (!rollover) {
dst_key_format(active_key->key, keystr, sizeof(keystr));
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
Fix coverity issue 331478 Move the "cannot start rollover" warning into code block that checks if 'active_key' is not NULL.
2021-05-17 14:06:46 +02:00
DNS_LOGMODULE_DNSSEC, ISC_LOG_WARNING,
"keymgr: DNSKEY %s (%s) is offline in "
"policy %s, cannot start rollover",
keystr, keymgr_keyrole(active_key->key),
dns_kasp_getname(kasp));
return ISC_R_SUCCESS;
}
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
} else if (isc_log_wouldlog(ISC_LOG_DEBUG(1))) {
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
char namestr[DNS_NAME_FORMATSIZE];
dns_name_format(origin, namestr, sizeof(namestr));
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
ISC_LOG_DEBUG(1),
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
"keymgr: no active key found for %s (policy %s)",
namestr, dns_kasp_getname(kasp));
}
/* It is time to do key rollover, we need a new key. */
/*
* Check if there is a key available in pool because keys
* may have been pregenerated with dnssec-keygen.
*/
for (candidate = ISC_LIST_HEAD(*keyring); candidate != NULL;
candidate = ISC_LIST_NEXT(candidate, link))
{
Move kasp key match function to kasp header The dnssec-ksr tool needs to check if existing key files match lines in the keys section of a dnssec-policy, so make this function publicly available.
2023-08-09 14:10:32 +02:00
if (dns_kasp_key_match(kaspkey, candidate) &&
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
dst_key_is_unused(candidate->key))
{
/* Found a candidate in keyring. */
break;
}
}
if (candidate == NULL) {
/* No key available in keyring, create a new one. */
Migrate a single key to CSK with dnssec-policy When migrating keys to dnssec-policy, if a zone has only one key, assume it is going to be a CSK.
2021-08-16 11:12:36 +02:00
bool csk = (dns_kasp_key_ksk(kaspkey) &&
dns_kasp_key_zsk(kaspkey));
Better PKCS#11 label creation When using the same PKCS#11 URI for a zone that uses different DNSSEC policies, the PKCS#11 label could collide, i.e. the same label could be used for different keys. Add the policy name to the label to make it more unique. Also, the zone name could contain characters that are interpreted as special characters when parsing the PKCS#11 URI string. Mangle the zone name through 'dns_name_tofilenametext()' to make it PKCS#11 safe. Move the creation to a separate function for clarity. Furthermore, add a log message whenever a PKCS#11 object has been successfully created.
2023-11-17 10:45:05 +01:00
isc_result_t result =
keymgr_createkey(kaspkey, origin, kasp, rdclass, mctx,
keydir, keyring, newkeys, &dst_key);
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
if (result != ISC_R_SUCCESS) {
return result;
}
dst_key_setttl(dst_key, dns_kasp_dnskeyttl(kasp));
dst_key_settime(dst_key, DST_TIME_CREATED, now);
remove error handling code around dns_dnsseckey_create() this function can no longer fail, so error checking is not necessary.
2022-01-10 11:34:30 -08:00
dns_dnsseckey_create(mctx, &dst_key, &new_key);
Migrate a single key to CSK with dnssec-policy When migrating keys to dnssec-policy, if a zone has only one key, assume it is going to be a CSK.
2021-08-16 11:12:36 +02:00
keymgr_key_init(new_key, kasp, now, csk);
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
} else {
new_key = candidate;
}
dst_key_setnum(new_key->key, DST_NUM_LIFETIME, lifetime);
/* Got a key. */
if (active_key == NULL) {
/*
* If there is no active key found yet for this kasp
* key configuration, immediately make this key active.
*/
dst_key_settime(new_key->key, DST_TIME_PUBLISH, now);
dst_key_settime(new_key->key, DST_TIME_ACTIVATE, now);
dnssec-ksr keygen -o to create KSKs Add an option to dnssec-ksr keygen, -o, to create KSKs instead of ZSKs. This way, we can create a set of KSKS for a given period too. For KSKs we also need to set timing metadata, including "SyncPublish" and "SyncDelete". This functionality already exists in keymgr.c so let's make the function accessible. Replace dnssec-keygen calls with dnssec-ksr keygen for KSK in the ksr system test and check keys for created KSKs as well. This requires a slight modification of the check_keys function to take into account KSK timings and metadata.
2024-09-03 17:24:22 +02:00
dns_keymgr_settime_syncpublish(new_key->key, kasp, true);
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
active = now;
} else {
/*
* This is a successor. Mark the relationship.
*/
isc_stdtime_t created;
(void)dst_key_gettime(new_key->key, DST_TIME_CREATED, &created);
dst_key_setnum(new_key->key, DST_NUM_PREDECESSOR,
dst_key_id(active_key->key));
dst_key_setnum(active_key->key, DST_NUM_SUCCESSOR,
dst_key_id(new_key->key));
(void)dst_key_gettime(active_key->key, DST_TIME_INACTIVE,
&retire);
active = retire;
/*
* If prepublication time and/or retire time are
* in the past (before the new key was created), use
* creation time as published and active time,
* effectively immediately making the key active.
*/
if (prepub < created) {
active += (created - prepub);
prepub = created;
}
if (active < created) {
active = created;
}
dst_key_settime(new_key->key, DST_TIME_PUBLISH, prepub);
dst_key_settime(new_key->key, DST_TIME_ACTIVATE, active);
dnssec-ksr keygen -o to create KSKs Add an option to dnssec-ksr keygen, -o, to create KSKs instead of ZSKs. This way, we can create a set of KSKS for a given period too. For KSKs we also need to set timing metadata, including "SyncPublish" and "SyncDelete". This functionality already exists in keymgr.c so let's make the function accessible. Replace dnssec-keygen calls with dnssec-ksr keygen for KSK in the ksr system test and check keys for created KSKs as well. This requires a slight modification of the check_keys function to take into account KSK timings and metadata.
2024-09-03 17:24:22 +02:00
dns_keymgr_settime_syncpublish(new_key->key, kasp, false);
Retire predecessor when creating successor When creating the successor, the current active key (predecessor) should change its goal state to HIDDEN. Also add two useful debug logs in the keymgr_key_rollover function.
2020-05-14 15:39:57 +02:00
/*
* Retire predecessor.
*/
dst_key_setstate(active_key->key, DST_KEY_GOAL, HIDDEN);
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
}
/* This key wants to be present. */
dst_key_setstate(new_key->key, DST_KEY_GOAL, OMNIPRESENT);
/* Do we need to set retire time? */
if (lifetime > 0) {
Check for overflow when adding lifetime
2024-06-26 14:39:04 +10:00
uint32_t inactive;
if (ISC_OVERFLOW_ADD(active, lifetime, &inactive)) {
Log key calculation overflows
2024-06-26 14:49:51 +10:00
log_key_overflow(new_key->key, "inactive");
Check for overflow when adding lifetime
2024-06-26 14:39:04 +10:00
inactive = UINT32_MAX;
}
dst_key_settime(new_key->key, DST_TIME_INACTIVE, inactive);
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
keymgr_settime_remove(new_key, kasp);
}
/* Append dnsseckey to list of new keys. */
dns_dnssec_get_hints(new_key, now);
new_key->source = dns_keysource_repository;
INSIST(!new_key->legacy);
if (candidate == NULL) {
ISC_LIST_APPEND(*newkeys, new_key, link);
}
/* Logging. */
dst_key_format(new_key->key, keystr, sizeof(keystr));
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
ISC_LOG_INFO, "keymgr: DNSKEY %s (%s) %s for policy %s",
keystr, keymgr_keyrole(new_key->key),
(candidate != NULL) ? "selected" : "created",
dns_kasp_getname(kasp));
return ISC_R_SUCCESS;
}
Purge keys implementation On each keymgr run, we now also check if key files can be removed. The 'purge-keys' interval determines how long keys should be retained after they have become completely hidden. Key files should not be removed if it has a state that is set to something else then HIDDEN, if purge-keys is 0 (disabled), if the key goal is set to OMNIPRESENT, or if the key is unused (a key is unused if no timing metadata set, and no states are set or if set, they are set to HIDDEN). If the last changed timing metadata plus the purge-keys interval is in the past, the key files may be removed. Add a dst_key_t variable 'purge' to signal that the key file should not be written to file again.
2021-02-08 15:15:57 +01:00
static bool
keymgr_key_may_be_purged(dst_key_t *key, uint32_t after, isc_stdtime_t now) {
bool ksk = false;
bool zsk = false;
dst_key_state_t hidden[NUM_KEYSTATES] = { HIDDEN, NA, NA, NA };
isc_stdtime_t lastchange = 0;
char keystr[DST_KEY_FORMATSIZE];
dst_key_format(key, keystr, sizeof(keystr));
/* If 'purge-keys' is disabled, always retain keys. */
if (after == 0) {
return false;
}
/* Don't purge keys with goal OMNIPRESENT */
if (dst_key_goal(key) == OMNIPRESENT) {
return false;
}
/* Don't purge unused keys. */
if (dst_key_is_unused(key)) {
return false;
}
/* If this key is completely HIDDEN it may be purged. */
(void)dst_key_getbool(key, DST_BOOL_KSK, &ksk);
(void)dst_key_getbool(key, DST_BOOL_ZSK, &zsk);
if (ksk) {
hidden[DST_KEY_KRRSIG] = HIDDEN;
hidden[DST_KEY_DS] = HIDDEN;
}
if (zsk) {
hidden[DST_KEY_ZRRSIG] = HIDDEN;
}
if (!keymgr_key_match_state(key, key, 0, NA, hidden)) {
return false;
}
/*
* Check 'purge-keys' interval. If the interval has passed since
* the last key change, it may be purged.
*/
for (int i = 0; i < NUM_KEYSTATES; i++) {
isc_stdtime_t change = 0;
(void)dst_key_gettime(key, keystatetimes[i], &change);
if (change > lastchange) {
lastchange = change;
}
}
return (lastchange + after) < now;
}
static void
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
keymgr_purge_keyfile(dst_key_t *key, int type) {
Purge keys implementation On each keymgr run, we now also check if key files can be removed. The 'purge-keys' interval determines how long keys should be retained after they have become completely hidden. Key files should not be removed if it has a state that is set to something else then HIDDEN, if purge-keys is 0 (disabled), if the key goal is set to OMNIPRESENT, or if the key is unused (a key is unused if no timing metadata set, and no states are set or if set, they are set to HIDDEN). If the last changed timing metadata plus the purge-keys interval is in the past, the key files may be removed. Add a dst_key_t variable 'purge' to signal that the key file should not be written to file again.
2021-02-08 15:15:57 +01:00
isc_result_t ret;
isc_buffer_t fileb;
char filename[NAME_MAX];
/*
* Make the filename.
*/
isc_buffer_init(&fileb, filename, sizeof(filename));
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
ret = dst_key_buildfilename(key, type, dst_key_directory(key), &fileb);
Purge keys implementation On each keymgr run, we now also check if key files can be removed. The 'purge-keys' interval determines how long keys should be retained after they have become completely hidden. Key files should not be removed if it has a state that is set to something else then HIDDEN, if purge-keys is 0 (disabled), if the key goal is set to OMNIPRESENT, or if the key is unused (a key is unused if no timing metadata set, and no states are set or if set, they are set to HIDDEN). If the last changed timing metadata plus the purge-keys interval is in the past, the key files may be removed. Add a dst_key_t variable 'purge' to signal that the key file should not be written to file again.
2021-02-08 15:15:57 +01:00
if (ret != ISC_R_SUCCESS) {
char keystr[DST_KEY_FORMATSIZE];
dst_key_format(key, keystr, sizeof(keystr));
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
ISC_LOG_WARNING,
Purge keys implementation On each keymgr run, we now also check if key files can be removed. The 'purge-keys' interval determines how long keys should be retained after they have become completely hidden. Key files should not be removed if it has a state that is set to something else then HIDDEN, if purge-keys is 0 (disabled), if the key goal is set to OMNIPRESENT, or if the key is unused (a key is unused if no timing metadata set, and no states are set or if set, they are set to HIDDEN). If the last changed timing metadata plus the purge-keys interval is in the past, the key files may be removed. Add a dst_key_t variable 'purge' to signal that the key file should not be written to file again.
2021-02-08 15:15:57 +01:00
"keymgr: failed to purge DNSKEY %s (%s): cannot "
"build filename (%s)",
keystr, keymgr_keyrole(key),
isc_result_totext(ret));
return;
}
if (unlink(filename) < 0) {
char keystr[DST_KEY_FORMATSIZE];
dst_key_format(key, keystr, sizeof(keystr));
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
ISC_LOG_WARNING,
Purge keys implementation On each keymgr run, we now also check if key files can be removed. The 'purge-keys' interval determines how long keys should be retained after they have become completely hidden. Key files should not be removed if it has a state that is set to something else then HIDDEN, if purge-keys is 0 (disabled), if the key goal is set to OMNIPRESENT, or if the key is unused (a key is unused if no timing metadata set, and no states are set or if set, they are set to HIDDEN). If the last changed timing metadata plus the purge-keys interval is in the past, the key files may be removed. Add a dst_key_t variable 'purge' to signal that the key file should not be written to file again.
2021-02-08 15:15:57 +01:00
"keymgr: failed to purge DNSKEY %s (%s): unlink "
"'%s' failed",
keystr, keymgr_keyrole(key), filename);
}
}
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/*
* Examine 'keys' and match 'kasp' policy.
*
*/
isc_result_t
dns_keymgr_run(const dns_name_t *origin, dns_rdataclass_t rdclass,
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
isc_mem_t *mctx, dns_dnsseckeylist_t *keyring,
dns_dnsseckeylist_t *dnskeys, const char *keydir,
Don't roll offline keys When checking the current DNSSEC state against the policy, consider offline keys. If we didn't found an active key, check if the key is offline by checking the public key list. If there is a match in the public key list (the key data is retrieved from the .key and the .state files), treat the key as offline and don't create a successor key for it.
2021-04-12 14:40:46 +02:00
dns_kasp_t *kasp, isc_stdtime_t now, isc_stdtime_t *nexttime) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
isc_result_t result = ISC_R_SUCCESS;
dns_dnsseckeylist_t newkeys;
dns_kasp_key_t *kkey;
dns_dnsseckey_t *newkey = NULL;
Update keymgr to allow transition to insecure mode The keymgr prevented zones from going to insecure mode. If we have a policy with an empty key list this is a signal that the zone wants to go back to insecure mode. In this case allow one extra state transition to be valid when checking for DNSSEC safety.
2020-12-03 16:04:28 +01:00
bool secure_to_insecure = false;
Migrate a single key to CSK with dnssec-policy When migrating keys to dnssec-policy, if a zone has only one key, assume it is going to be a CSK.
2021-08-16 11:12:36 +02:00
int numkeys = 0;
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
int options = (DST_TYPE_PRIVATE | DST_TYPE_PUBLIC | DST_TYPE_STATE);
char keystr[DST_KEY_FORMATSIZE];
Create private keys with PKCS#11 object If there is a keystore configured with a PKCS#11 URI, zones that are using a dnssec-policy that uses such a keystore should create keys via the PKCS#11 interface. Those keys are generally stored inside an HSM. Some changes to the code are required, to store the engine reference into the keystore.
2022-02-28 11:50:43 +01:00
REQUIRE(dns_name_isvalid(origin));
REQUIRE(mctx != NULL);
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
REQUIRE(keyring != NULL);
Create private keys with PKCS#11 object If there is a keystore configured with a PKCS#11 URI, zones that are using a dnssec-policy that uses such a keystore should create keys via the PKCS#11 interface. Those keys are generally stored inside an HSM. Some changes to the code are required, to store the engine reference into the keystore.
2022-02-28 11:50:43 +01:00
REQUIRE(DNS_KASP_VALID(kasp));
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
ISC_LIST_INIT(newkeys);
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
*nexttime = 0;
/* Debug logging: what keys are available in the keyring? */
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
if (isc_log_wouldlog(ISC_LOG_DEBUG(1))) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
if (ISC_LIST_EMPTY(*keyring)) {
char namebuf[DNS_NAME_FORMATSIZE];
dns_name_format(origin, namebuf, sizeof(namebuf));
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
DNS_LOGMODULE_DNSSEC, ISC_LOG_DEBUG(1),
"keymgr: keyring empty (zone %s policy "
"%s)",
namebuf, dns_kasp_getname(kasp));
}
for (dns_dnsseckey_t *dkey = ISC_LIST_HEAD(*keyring);
dkey != NULL; dkey = ISC_LIST_NEXT(dkey, link))
{
dst_key_format(dkey->key, keystr, sizeof(keystr));
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
DNS_LOGMODULE_DNSSEC, ISC_LOG_DEBUG(1),
Don't roll offline keys When checking the current DNSSEC state against the policy, consider offline keys. If we didn't found an active key, check if the key is offline by checking the public key list. If there is a match in the public key list (the key data is retrieved from the .key and the .state files), treat the key as offline and don't create a successor key for it.
2021-04-12 14:40:46 +02:00
"keymgr: keyring: %s (policy %s)", keystr,
dns_kasp_getname(kasp));
}
for (dns_dnsseckey_t *dkey = ISC_LIST_HEAD(*dnskeys);
dkey != NULL; dkey = ISC_LIST_NEXT(dkey, link))
{
dst_key_format(dkey->key, keystr, sizeof(keystr));
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
Don't roll offline keys When checking the current DNSSEC state against the policy, consider offline keys. If we didn't found an active key, check if the key is offline by checking the public key list. If there is a match in the public key list (the key data is retrieved from the .key and the .state files), treat the key as offline and don't create a successor key for it.
2021-04-12 14:40:46 +02:00
DNS_LOGMODULE_DNSSEC, ISC_LOG_DEBUG(1),
"keymgr: dnskeys: %s (policy %s)", keystr,
dns_kasp_getname(kasp));
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
}
}
Migrate a single key to CSK with dnssec-policy When migrating keys to dnssec-policy, if a zone has only one key, assume it is going to be a CSK.
2021-08-16 11:12:36 +02:00
for (dns_dnsseckey_t *dkey = ISC_LIST_HEAD(*dnskeys); dkey != NULL;
dkey = ISC_LIST_NEXT(dkey, link))
{
numkeys++;
}
[#1624] dnssec-policy change retire unwanted keys When changing a dnssec-policy, existing keys with properties that no longer match were not being retired.
2020-02-18 16:58:56 +01:00
/* Do we need to remove keys? */
for (dns_dnsseckey_t *dkey = ISC_LIST_HEAD(*keyring); dkey != NULL;
dkey = ISC_LIST_NEXT(dkey, link))
{
bool found_match = false;
Migrate a single key to CSK with dnssec-policy When migrating keys to dnssec-policy, if a zone has only one key, assume it is going to be a CSK.
2021-08-16 11:12:36 +02:00
keymgr_key_init(dkey, kasp, now, (numkeys == 1));
[#1624] dnssec-policy change retire unwanted keys When changing a dnssec-policy, existing keys with properties that no longer match were not being retired.
2020-02-18 16:58:56 +01:00
for (kkey = ISC_LIST_HEAD(dns_kasp_keys(kasp)); kkey != NULL;
kkey = ISC_LIST_NEXT(kkey, link))
{
Move kasp key match function to kasp header The dnssec-ksr tool needs to check if existing key files match lines in the keys section of a dnssec-policy, so make this function publicly available.
2023-08-09 14:10:32 +02:00
if (dns_kasp_key_match(kkey, dkey)) {
[#1624] dnssec-policy change retire unwanted keys When changing a dnssec-policy, existing keys with properties that no longer match were not being retired.
2020-02-18 16:58:56 +01:00
found_match = true;
break;
}
}
/* No match, so retire unwanted retire key. */
if (!found_match) {
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
keymgr_key_retire(dkey, kasp, now);
[#1624] dnssec-policy change retire unwanted keys When changing a dnssec-policy, existing keys with properties that no longer match were not being retired.
2020-02-18 16:58:56 +01:00
}
Purge keys implementation On each keymgr run, we now also check if key files can be removed. The 'purge-keys' interval determines how long keys should be retained after they have become completely hidden. Key files should not be removed if it has a state that is set to something else then HIDDEN, if purge-keys is 0 (disabled), if the key goal is set to OMNIPRESENT, or if the key is unused (a key is unused if no timing metadata set, and no states are set or if set, they are set to HIDDEN). If the last changed timing metadata plus the purge-keys interval is in the past, the key files may be removed. Add a dst_key_t variable 'purge' to signal that the key file should not be written to file again.
2021-02-08 15:15:57 +01:00
/* Check purge-keys interval. */
if (keymgr_key_may_be_purged(dkey->key,
Update sources to Clang 15 formatting
2022-11-02 19:33:14 +01:00
dns_kasp_purgekeys(kasp), now))
{
Purge keys implementation On each keymgr run, we now also check if key files can be removed. The 'purge-keys' interval determines how long keys should be retained after they have become completely hidden. Key files should not be removed if it has a state that is set to something else then HIDDEN, if purge-keys is 0 (disabled), if the key goal is set to OMNIPRESENT, or if the key is unused (a key is unused if no timing metadata set, and no states are set or if set, they are set to HIDDEN). If the last changed timing metadata plus the purge-keys interval is in the past, the key files may be removed. Add a dst_key_t variable 'purge' to signal that the key file should not be written to file again.
2021-02-08 15:15:57 +01:00
dst_key_format(dkey->key, keystr, sizeof(keystr));
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
Purge keys implementation On each keymgr run, we now also check if key files can be removed. The 'purge-keys' interval determines how long keys should be retained after they have become completely hidden. Key files should not be removed if it has a state that is set to something else then HIDDEN, if purge-keys is 0 (disabled), if the key goal is set to OMNIPRESENT, or if the key is unused (a key is unused if no timing metadata set, and no states are set or if set, they are set to HIDDEN). If the last changed timing metadata plus the purge-keys interval is in the past, the key files may be removed. Add a dst_key_t variable 'purge' to signal that the key file should not be written to file again.
2021-02-08 15:15:57 +01:00
DNS_LOGMODULE_DNSSEC, ISC_LOG_INFO,
"keymgr: purge DNSKEY %s (%s) according "
"to policy %s",
keystr, keymgr_keyrole(dkey->key),
dns_kasp_getname(kasp));
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
keymgr_purge_keyfile(dkey->key, DST_TYPE_PUBLIC);
keymgr_purge_keyfile(dkey->key, DST_TYPE_PRIVATE);
keymgr_purge_keyfile(dkey->key, DST_TYPE_STATE);
Purge keys implementation On each keymgr run, we now also check if key files can be removed. The 'purge-keys' interval determines how long keys should be retained after they have become completely hidden. Key files should not be removed if it has a state that is set to something else then HIDDEN, if purge-keys is 0 (disabled), if the key goal is set to OMNIPRESENT, or if the key is unused (a key is unused if no timing metadata set, and no states are set or if set, they are set to HIDDEN). If the last changed timing metadata plus the purge-keys interval is in the past, the key files may be removed. Add a dst_key_t variable 'purge' to signal that the key file should not be written to file again.
2021-02-08 15:15:57 +01:00
dkey->purge = true;
}
[#1624] dnssec-policy change retire unwanted keys When changing a dnssec-policy, existing keys with properties that no longer match were not being retired.
2020-02-18 16:58:56 +01:00
}
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/* Create keys according to the policy, if come in short. */
Make kasp opaque
2019-11-04 16:26:39 +01:00
for (kkey = ISC_LIST_HEAD(dns_kasp_keys(kasp)); kkey != NULL;
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
kkey = ISC_LIST_NEXT(kkey, link))
{
uint32_t lifetime = dns_kasp_key_lifetime(kkey);
dns_dnsseckey_t *active_key = NULL;
Don't roll offline keys When checking the current DNSSEC state against the policy, consider offline keys. If we didn't found an active key, check if the key is offline by checking the public key list. If there is a match in the public key list (the key data is retrieved from the .key and the .state files), treat the key as offline and don't create a successor key for it.
2021-04-12 14:40:46 +02:00
bool rollover_allowed = true;
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/* Do we have keys available for this kasp key? */
for (dns_dnsseckey_t *dkey = ISC_LIST_HEAD(*keyring);
dkey != NULL; dkey = ISC_LIST_NEXT(dkey, link))
{
Move kasp key match function to kasp header The dnssec-ksr tool needs to check if existing key files match lines in the keys section of a dnssec-policy, so make this function publicly available.
2023-08-09 14:10:32 +02:00
if (dns_kasp_key_match(kkey, dkey)) {
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/* Found a match. */
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
dst_key_format(dkey->key, keystr,
sizeof(keystr));
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
DNS_LOGMODULE_DNSSEC,
ISC_LOG_DEBUG(1),
"keymgr: DNSKEY %s (%s) matches "
"policy %s",
keystr, keymgr_keyrole(dkey->key),
dns_kasp_getname(kasp));
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
Update key lifetime and metadata after reconfig If dnssec-policy is reconfigured and the key lifetime has changed, update existing keys with the new lifetime and adjust the retire and removed timing metadata accordingly. If the key has no lifetime yet, just initialize the lifetime. It may be that the retire/removed timing metadata has already been set. Skip keys which goal is not set to omnipresent. These keys are already in the progress of retiring, or still unused.
2024-06-24 15:14:16 +02:00
/* Update lifetime if changed. */
keymgr_key_update_lifetime(dkey, kasp, now,
lifetime);
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
if (active_key) {
/* We already have an active key that
* matches the kasp policy.
*/
if (!dst_key_is_unused(dkey->key) &&
(dst_key_goal(dkey->key) ==
OMNIPRESENT) &&
Update keymgr_key_is_successor() calls The previous commit changed the function definition of 'keymgr_key_is_successor()', this commit updates the code where this function is called. In 'keymgr_key_exists_with_state()' the logic is also updated slightly to become more readable. First handle the easy cases: - If the key does not match the state, continue with the next key. - If we found a key with matching state, and there is no need to check the successor relationship, return (true). - Otherwise check the successor relationship. In 'keymgr_key_has_successor()' it is enough to check if a key has a direct successor, so instead of calling 'keymgr_key_is_successor()', we can just check 'keymgr_direct_dep()'. In 'dns_keymgr_run()', we want to make sure that there is no dependency on the keys before retiring excess keys, so replace 'keymgr_key_is_successor()' with 'keymgr_dep()'.
2021-01-07 12:04:14 +01:00
!keymgr_dep(dkey->key, keyring,
NULL) &&
!keymgr_dep(active_key->key,
keyring, NULL))
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
{
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/*
* Multiple signing keys match
* the kasp key configuration.
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
* Retire excess keys in use.
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
*/
Set keytimes appropriately when using kasp While kasp relies on key states to determine when a key needs to be published or be used for signing, the keytimes are used by operators to get some expectation of key publication and usage. Update the code such that these keytimes are set appropriately. That means: - Print "PublishCDS" and "DeleteCDS" times in the state files. - The keymgr sets the "Removed" and "PublishCDS" times and derives those from the dnssec-policy. - Tweak setting of the "Retired" time, when retiring keys, only update the time to now when the retire time is not yet set, or is in the future. This also fixes a bug in "keymgr_transition_time" where we may wait too long before zone signatrues become omnipresent or hidden. Not only can we skip waiting the sign delay Dsgn if there is no predecessor, we can also skip it if there is no successor. Finally, this commit moves setting the lifetime, reducing two calls to one.
2020-04-28 15:05:43 +02:00
keymgr_key_retire(dkey, kasp,
now);
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
}
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
continue;
}
/*
* Save the matched key only if it is active
* or desires to be active.
*/
if (dst_key_goal(dkey->key) == OMNIPRESENT ||
Update sources to Clang 15 formatting
2022-11-02 19:33:14 +01:00
dst_key_is_active(dkey->key, now))
{
Fix and test migration to dnssec-policy Migrating from 'auto-dnssec maintain;' to dnssec-policy did not work properly, mainly because the legacy keys were initialized badly. Several adjustments in the keymgr are required to get it right: - Set published time on keys when we calculate prepublication time. This is not strictly necessary, but it is weird to have an active key without the published time set. - Initalize key states also before matching keys. Determine the target state by looking at existing time metadata: If the time data is set and is in the past, it is a hint that the key and its corresponding records have been published in the zone already, and the state is initialized to RUMOURED. Otherwise, initialize it as HIDDEN. This fixes migration to dnssec-policy from existing keys. - Initialize key goal on keys that match key policy to OMNIPRESENT. These may be existing legacy keys that are being migrated. - A key that has its goal to OMNIPRESENT *or* an active key can match a kasp key. The code was changed with CHANGE 5354 that was a bugfix to prevent creating new KSK keys for zones in the initial stage of signing. However, this caused problems for restarts when rollovers are in progress, because an outroducing key can still be an active key. The test for this introduces a new KEY property 'legacy'. This is used to skip tests related to .state files.
2020-03-27 10:28:22 +01:00
active_key = dkey;
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
}
}
}
Don't roll offline keys When checking the current DNSSEC state against the policy, consider offline keys. If we didn't found an active key, check if the key is offline by checking the public key list. If there is a match in the public key list (the key data is retrieved from the .key and the .state files), treat the key as offline and don't create a successor key for it.
2021-04-12 14:40:46 +02:00
if (active_key == NULL) {
/*
* We didn't found an active key, perhaps the .private
* key file is offline. If so, we don't want to create
* a successor key. Check if we have an appropriate
* state file.
*/
for (dns_dnsseckey_t *dnskey = ISC_LIST_HEAD(*dnskeys);
dnskey != NULL;
dnskey = ISC_LIST_NEXT(dnskey, link))
{
Move kasp key match function to kasp header The dnssec-ksr tool needs to check if existing key files match lines in the keys section of a dnssec-policy, so make this function publicly available.
2023-08-09 14:10:32 +02:00
if (dns_kasp_key_match(kkey, dnskey)) {
Don't roll offline keys When checking the current DNSSEC state against the policy, consider offline keys. If we didn't found an active key, check if the key is offline by checking the public key list. If there is a match in the public key list (the key data is retrieved from the .key and the .state files), treat the key as offline and don't create a successor key for it.
2021-04-12 14:40:46 +02:00
/* Found a match. */
dst_key_format(dnskey->key, keystr,
sizeof(keystr));
isc_log_write(
DNS_LOGCATEGORY_DNSSEC,
DNS_LOGMODULE_DNSSEC,
ISC_LOG_DEBUG(1),
"keymgr: DNSKEY %s (%s) "
"offline, policy %s",
keystr,
keymgr_keyrole(dnskey->key),
dns_kasp_getname(kasp));
rollover_allowed = false;
active_key = dnskey;
break;
}
}
}
Put new key rollover logic in separate function The `dns_keymgr_run()` function became quite long, put the logic that looks if a new key needs to be created (start a key rollover) in a separate function.
2020-05-14 15:34:13 +02:00
/* See if this key requires a rollover. */
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
RETERR(keymgr_key_rollover(kkey, active_key, keyring, &newkeys,
origin, rdclass, kasp, keydir,
lifetime, rollover_allowed, now,
nexttime, mctx));
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
}
/* Walked all kasp key configurations. Append new keys. */
if (!ISC_LIST_EMPTY(newkeys)) {
ISC_LIST_APPENDLIST(*keyring, newkeys, link);
}
Update keymgr to allow transition to insecure mode The keymgr prevented zones from going to insecure mode. If we have a policy with an empty key list this is a signal that the zone wants to go back to insecure mode. In this case allow one extra state transition to be valid when checking for DNSSEC safety.
2020-12-03 16:04:28 +01:00
/*
* If the policy has an empty key list, this means the zone is going
* back to unsigned.
*/
secure_to_insecure = dns_kasp_keylist_empty(kasp);
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/* Read to update key states. */
Update keymgr to allow transition to insecure mode The keymgr prevented zones from going to insecure mode. If we have a policy with an empty key list this is a signal that the zone wants to go back to insecure mode. In this case allow one extra state transition to be valid when checking for DNSSEC safety.
2020-12-03 16:04:28 +01:00
keymgr_update(keyring, kasp, now, nexttime, secure_to_insecure);
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
/* Store key states and update hints. */
for (dns_dnsseckey_t *dkey = ISC_LIST_HEAD(*keyring); dkey != NULL;
dkey = ISC_LIST_NEXT(dkey, link))
{
Write new DNSKEY TTL to key file When the current DNSKEY TTL does not match the one from the policy, write the new TTL to disk.
2023-12-22 15:08:45 +01:00
bool modified = dst_key_ismodified(dkey->key);
if (dst_key_getttl(dkey->key) != dns_kasp_dnskeyttl(kasp)) {
dst_key_setttl(dkey->key, dns_kasp_dnskeyttl(kasp));
modified = true;
}
if (modified && !dkey->purge) {
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
const char *directory = dst_key_directory(dkey->key);
if (directory == NULL) {
directory = ".";
}
Purge keys implementation On each keymgr run, we now also check if key files can be removed. The 'purge-keys' interval determines how long keys should be retained after they have become completely hidden. Key files should not be removed if it has a state that is set to something else then HIDDEN, if purge-keys is 0 (disabled), if the key goal is set to OMNIPRESENT, or if the key is unused (a key is unused if no timing metadata set, and no states are set or if set, they are set to HIDDEN). If the last changed timing metadata plus the purge-keys interval is in the past, the key files may be removed. Add a dst_key_t variable 'purge' to signal that the key file should not be written to file again.
2021-02-08 15:15:57 +01:00
dns_dnssec_get_hints(dkey, now);
RETERR(dst_key_tofile(dkey->key, options, directory));
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
dst_key_setmodified(dkey->key, false);
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
if (!isc_log_wouldlog(ISC_LOG_DEBUG(3))) {
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
continue;
}
dst_key_format(dkey->key, keystr, sizeof(keystr));
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
DNS_LOGMODULE_DNSSEC, ISC_LOG_DEBUG(3),
"keymgr: DNSKEY %s (%s) "
"saved to directory %s, policy %s",
keystr, keymgr_keyrole(dkey->key),
directory, dns_kasp_getname(kasp));
Purge keys implementation On each keymgr run, we now also check if key files can be removed. The 'purge-keys' interval determines how long keys should be retained after they have become completely hidden. Key files should not be removed if it has a state that is set to something else then HIDDEN, if purge-keys is 0 (disabled), if the key goal is set to OMNIPRESENT, or if the key is unused (a key is unused if no timing metadata set, and no states are set or if set, they are set to HIDDEN). If the last changed timing metadata plus the purge-keys interval is in the past, the key files may be removed. Add a dst_key_t variable 'purge' to signal that the key file should not be written to file again.
2021-02-08 15:15:57 +01:00
}
Write new DNSKEY TTL to key file When the current DNSKEY TTL does not match the one from the policy, write the new TTL to disk.
2023-12-22 15:08:45 +01:00
dst_key_setmodified(dkey->key, false);
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
}
result = ISC_R_SUCCESS;
failure:
if (result != ISC_R_SUCCESS) {
while ((newkey = ISC_LIST_HEAD(newkeys)) != NULL) {
ISC_LIST_UNLINK(newkeys, newkey, link);
INSIST(newkey->key != NULL);
dst_key_free(&newkey->key);
dns_dnsseckey_destroy(mctx, &newkey);
}
}
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
if (isc_log_wouldlog(ISC_LOG_DEBUG(3))) {
Check if key metadata is modified before writing Add a new parameter to the dst_key structure, mark a key modified if dst_key_(un)set[bool,num,state,time] is called. Only write out key files during a keymgr run if the metadata has changed.
2022-05-03 12:28:31 +02:00
char namebuf[DNS_NAME_FORMATSIZE];
dns_name_format(origin, namebuf, sizeof(namebuf));
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
ISC_LOG_DEBUG(3), "keymgr: %s done", namebuf);
Check if key metadata is modified before writing Add a new parameter to the dst_key structure, mark a key modified if dst_key_(un)set[bool,num,state,time] is called. Only write out key files during a keymgr run if the metadata has changed.
2022-05-03 12:28:31 +02:00
}
Introduce keymgr in named Add a key manager to named. If a 'dnssec-policy' is set, 'named' will run a key manager on the matching keys. This will do a couple of things: 1. Create keys when needed (in case of rollover for example) according to the set policy. 2. Retire keys that are in excess of the policy. 3. Maintain key states according to "Flexible and Robust Key Rollover" [1]. After key manager ran, key files will be saved to disk. [1] https://matthijsmekking.nl/static/pdf/satin2012-Schaeffer.pdf KEY GENERATION Create keys according to DNSSEC policy. Zones configured with 'dnssec-policy' will allow 'named' to create DNSSEC keys (similar to dnssec-keymgr) if not available. KEY ROLLOVER Rather than determining the desired state from timing metadata, add a key state goal. Any keys that are created or picked from the key ring and selected to be a successor has its key state goal set to OMNIPRESENT (this key wants to be signing!). At the same time, a key that is being retired has its key state goal set to HIDDEN. The keymgr state machine with the three rules will make sure no introduction or withdrawal of DNSSEC records happens too soon. KEY TIMINGS All timings are based on RFC 7583. The keymgr will return when the next action is happening so that the zone can set the proper rekey event. Prior to this change the rekey event will run every hour by default (configurable), but with kasp we can determine exactly when we need to run again. The prepublication time is derived from policy.
2019-10-17 11:19:35 +02:00
return result;
}
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
Implement 'rndc dnssec -checkds' Add a new 'rndc' command 'dnssec -checkds' that allows the user to signal named that a new DS record has been seen published in the parent, or that an existing DS record has been withdrawn from the parent. Upon the 'checkds' request, 'named' will write out the new state for the key, updating the 'DSPublish' or 'DSRemoved' timing metadata. This replaces the "parent-registration-delay" configuration option, this was unreliable because it was purely time based (if the user did not actually submit the new DS to the parent for example, this could result in an invalid DNSSEC state). Because we cannot rely on the parent registration delay for state transition, we need to replace it with a different guard. Instead, if a key wants its DS state to be moved to RUMOURED, the "DSPublish" time must be set and must not be in the future. If a key wants its DS state to be moved to UNRETENTIVE, the "DSRemoved" time must be set and must not be in the future. By default, with '-checkds' you set the time that the DS has been published or withdrawn to now, but you can set a different time with '-when'. If there is only one KSK for the zone, that key has its DS state moved to RUMOURED. If there are multiple keys for the zone, specify the right key with '-key'.
2020-07-31 08:37:51 +02:00
static isc_result_t
keymgr_checkds(dns_kasp_t *kasp, dns_dnsseckeylist_t *keyring,
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
isc_stdtime_t now, isc_stdtime_t when, bool dspublish,
dns_keytag_t id, unsigned int alg, bool check_id) {
Implement 'rndc dnssec -checkds' Add a new 'rndc' command 'dnssec -checkds' that allows the user to signal named that a new DS record has been seen published in the parent, or that an existing DS record has been withdrawn from the parent. Upon the 'checkds' request, 'named' will write out the new state for the key, updating the 'DSPublish' or 'DSRemoved' timing metadata. This replaces the "parent-registration-delay" configuration option, this was unreliable because it was purely time based (if the user did not actually submit the new DS to the parent for example, this could result in an invalid DNSSEC state). Because we cannot rely on the parent registration delay for state transition, we need to replace it with a different guard. Instead, if a key wants its DS state to be moved to RUMOURED, the "DSPublish" time must be set and must not be in the future. If a key wants its DS state to be moved to UNRETENTIVE, the "DSRemoved" time must be set and must not be in the future. By default, with '-checkds' you set the time that the DS has been published or withdrawn to now, but you can set a different time with '-when'. If there is only one KSK for the zone, that key has its DS state moved to RUMOURED. If there are multiple keys for the zone, specify the right key with '-key'.
2020-07-31 08:37:51 +02:00
int options = (DST_TYPE_PRIVATE | DST_TYPE_PUBLIC | DST_TYPE_STATE);
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
const char *directory = NULL;
Implement 'rndc dnssec -checkds' Add a new 'rndc' command 'dnssec -checkds' that allows the user to signal named that a new DS record has been seen published in the parent, or that an existing DS record has been withdrawn from the parent. Upon the 'checkds' request, 'named' will write out the new state for the key, updating the 'DSPublish' or 'DSRemoved' timing metadata. This replaces the "parent-registration-delay" configuration option, this was unreliable because it was purely time based (if the user did not actually submit the new DS to the parent for example, this could result in an invalid DNSSEC state). Because we cannot rely on the parent registration delay for state transition, we need to replace it with a different guard. Instead, if a key wants its DS state to be moved to RUMOURED, the "DSPublish" time must be set and must not be in the future. If a key wants its DS state to be moved to UNRETENTIVE, the "DSRemoved" time must be set and must not be in the future. By default, with '-checkds' you set the time that the DS has been published or withdrawn to now, but you can set a different time with '-when'. If there is only one KSK for the zone, that key has its DS state moved to RUMOURED. If there are multiple keys for the zone, specify the right key with '-key'.
2020-07-31 08:37:51 +02:00
isc_result_t result;
dns_dnsseckey_t *ksk_key = NULL;
REQUIRE(DNS_KASP_VALID(kasp));
REQUIRE(keyring != NULL);
for (dns_dnsseckey_t *dkey = ISC_LIST_HEAD(*keyring); dkey != NULL;
dkey = ISC_LIST_NEXT(dkey, link))
{
isc_result_t ret;
bool ksk = false;
ret = dst_key_getbool(dkey->key, DST_BOOL_KSK, &ksk);
if (ret == ISC_R_SUCCESS && ksk) {
if (check_id && dst_key_id(dkey->key) != id) {
continue;
}
rndc dnssec -checkds set algorithm In the rare case that you have multiple keys acting as KSK and that have the same keytag, you can now set the algorithm when calling '-checkds'.
2020-08-04 10:33:19 +02:00
if (alg > 0 && dst_key_alg(dkey->key) != alg) {
continue;
}
Implement 'rndc dnssec -checkds' Add a new 'rndc' command 'dnssec -checkds' that allows the user to signal named that a new DS record has been seen published in the parent, or that an existing DS record has been withdrawn from the parent. Upon the 'checkds' request, 'named' will write out the new state for the key, updating the 'DSPublish' or 'DSRemoved' timing metadata. This replaces the "parent-registration-delay" configuration option, this was unreliable because it was purely time based (if the user did not actually submit the new DS to the parent for example, this could result in an invalid DNSSEC state). Because we cannot rely on the parent registration delay for state transition, we need to replace it with a different guard. Instead, if a key wants its DS state to be moved to RUMOURED, the "DSPublish" time must be set and must not be in the future. If a key wants its DS state to be moved to UNRETENTIVE, the "DSRemoved" time must be set and must not be in the future. By default, with '-checkds' you set the time that the DS has been published or withdrawn to now, but you can set a different time with '-when'. If there is only one KSK for the zone, that key has its DS state moved to RUMOURED. If there are multiple keys for the zone, specify the right key with '-key'.
2020-07-31 08:37:51 +02:00
if (ksk_key != NULL) {
/*
* Only checkds for one key at a time.
*/
Use explicit result codes for 'rndc dnssec' cmd It is better to add new result codes than to overload existing codes.
2020-09-04 11:42:52 +02:00
return DNS_R_TOOMANYKEYS;
Implement 'rndc dnssec -checkds' Add a new 'rndc' command 'dnssec -checkds' that allows the user to signal named that a new DS record has been seen published in the parent, or that an existing DS record has been withdrawn from the parent. Upon the 'checkds' request, 'named' will write out the new state for the key, updating the 'DSPublish' or 'DSRemoved' timing metadata. This replaces the "parent-registration-delay" configuration option, this was unreliable because it was purely time based (if the user did not actually submit the new DS to the parent for example, this could result in an invalid DNSSEC state). Because we cannot rely on the parent registration delay for state transition, we need to replace it with a different guard. Instead, if a key wants its DS state to be moved to RUMOURED, the "DSPublish" time must be set and must not be in the future. If a key wants its DS state to be moved to UNRETENTIVE, the "DSRemoved" time must be set and must not be in the future. By default, with '-checkds' you set the time that the DS has been published or withdrawn to now, but you can set a different time with '-when'. If there is only one KSK for the zone, that key has its DS state moved to RUMOURED. If there are multiple keys for the zone, specify the right key with '-key'.
2020-07-31 08:37:51 +02:00
}
ksk_key = dkey;
}
}
if (ksk_key == NULL) {
Use explicit result codes for 'rndc dnssec' cmd It is better to add new result codes than to overload existing codes.
2020-09-04 11:42:52 +02:00
return DNS_R_NOKEYMATCH;
Implement 'rndc dnssec -checkds' Add a new 'rndc' command 'dnssec -checkds' that allows the user to signal named that a new DS record has been seen published in the parent, or that an existing DS record has been withdrawn from the parent. Upon the 'checkds' request, 'named' will write out the new state for the key, updating the 'DSPublish' or 'DSRemoved' timing metadata. This replaces the "parent-registration-delay" configuration option, this was unreliable because it was purely time based (if the user did not actually submit the new DS to the parent for example, this could result in an invalid DNSSEC state). Because we cannot rely on the parent registration delay for state transition, we need to replace it with a different guard. Instead, if a key wants its DS state to be moved to RUMOURED, the "DSPublish" time must be set and must not be in the future. If a key wants its DS state to be moved to UNRETENTIVE, the "DSRemoved" time must be set and must not be in the future. By default, with '-checkds' you set the time that the DS has been published or withdrawn to now, but you can set a different time with '-when'. If there is only one KSK for the zone, that key has its DS state moved to RUMOURED. If there are multiple keys for the zone, specify the right key with '-key'.
2020-07-31 08:37:51 +02:00
}
if (dspublish) {
Force set DS state after 'rndc dnssec -checkds' Set the DS state after issuing 'rndc dnssec -checkds'. If the DS was published, it should go in RUMOURED state, regardless whether it is already safe to do so according to the state machine. Leaving it in HIDDEN (or if it was magically already in OMNIPRESENT or UNRETENTIVE) would allow for easy shoot in the foot situations. Similar, if the DS was withdrawn, the state should be set to UNRETENTIVE. Leaving it in OMNIPRESENT (or RUMOURED/HIDDEN) would also allow for easy shoot in the foot situations.
2023-01-25 16:36:48 +01:00
dst_key_state_t s;
Various rndc dnssec -checkds fixes While working on 'rndc dnssec -rollover' I noticed the following (small) issues: - The key files where updated with hints set to "-when" and that should always be "now. - The kasp system test did not properly update the test number when calling 'rndc dnssec -checkds' (and ensuring that works). - There was a missing ']' in the rndc.c help output.
2020-08-24 10:05:28 +02:00
dst_key_settime(ksk_key->key, DST_TIME_DSPUBLISH, when);
Force set DS state after 'rndc dnssec -checkds' Set the DS state after issuing 'rndc dnssec -checkds'. If the DS was published, it should go in RUMOURED state, regardless whether it is already safe to do so according to the state machine. Leaving it in HIDDEN (or if it was magically already in OMNIPRESENT or UNRETENTIVE) would allow for easy shoot in the foot situations. Similar, if the DS was withdrawn, the state should be set to UNRETENTIVE. Leaving it in OMNIPRESENT (or RUMOURED/HIDDEN) would also allow for easy shoot in the foot situations.
2023-01-25 16:36:48 +01:00
result = dst_key_getstate(ksk_key->key, DST_KEY_DS, &s);
if (result != ISC_R_SUCCESS || s != RUMOURED) {
dst_key_setstate(ksk_key->key, DST_KEY_DS, RUMOURED);
}
Implement 'rndc dnssec -checkds' Add a new 'rndc' command 'dnssec -checkds' that allows the user to signal named that a new DS record has been seen published in the parent, or that an existing DS record has been withdrawn from the parent. Upon the 'checkds' request, 'named' will write out the new state for the key, updating the 'DSPublish' or 'DSRemoved' timing metadata. This replaces the "parent-registration-delay" configuration option, this was unreliable because it was purely time based (if the user did not actually submit the new DS to the parent for example, this could result in an invalid DNSSEC state). Because we cannot rely on the parent registration delay for state transition, we need to replace it with a different guard. Instead, if a key wants its DS state to be moved to RUMOURED, the "DSPublish" time must be set and must not be in the future. If a key wants its DS state to be moved to UNRETENTIVE, the "DSRemoved" time must be set and must not be in the future. By default, with '-checkds' you set the time that the DS has been published or withdrawn to now, but you can set a different time with '-when'. If there is only one KSK for the zone, that key has its DS state moved to RUMOURED. If there are multiple keys for the zone, specify the right key with '-key'.
2020-07-31 08:37:51 +02:00
} else {
Force set DS state after 'rndc dnssec -checkds' Set the DS state after issuing 'rndc dnssec -checkds'. If the DS was published, it should go in RUMOURED state, regardless whether it is already safe to do so according to the state machine. Leaving it in HIDDEN (or if it was magically already in OMNIPRESENT or UNRETENTIVE) would allow for easy shoot in the foot situations. Similar, if the DS was withdrawn, the state should be set to UNRETENTIVE. Leaving it in OMNIPRESENT (or RUMOURED/HIDDEN) would also allow for easy shoot in the foot situations.
2023-01-25 16:36:48 +01:00
dst_key_state_t s;
Various rndc dnssec -checkds fixes While working on 'rndc dnssec -rollover' I noticed the following (small) issues: - The key files where updated with hints set to "-when" and that should always be "now. - The kasp system test did not properly update the test number when calling 'rndc dnssec -checkds' (and ensuring that works). - There was a missing ']' in the rndc.c help output.
2020-08-24 10:05:28 +02:00
dst_key_settime(ksk_key->key, DST_TIME_DSDELETE, when);
Force set DS state after 'rndc dnssec -checkds' Set the DS state after issuing 'rndc dnssec -checkds'. If the DS was published, it should go in RUMOURED state, regardless whether it is already safe to do so according to the state machine. Leaving it in HIDDEN (or if it was magically already in OMNIPRESENT or UNRETENTIVE) would allow for easy shoot in the foot situations. Similar, if the DS was withdrawn, the state should be set to UNRETENTIVE. Leaving it in OMNIPRESENT (or RUMOURED/HIDDEN) would also allow for easy shoot in the foot situations.
2023-01-25 16:36:48 +01:00
result = dst_key_getstate(ksk_key->key, DST_KEY_DS, &s);
if (result != ISC_R_SUCCESS || s != UNRETENTIVE) {
dst_key_setstate(ksk_key->key, DST_KEY_DS, UNRETENTIVE);
}
Implement 'rndc dnssec -checkds' Add a new 'rndc' command 'dnssec -checkds' that allows the user to signal named that a new DS record has been seen published in the parent, or that an existing DS record has been withdrawn from the parent. Upon the 'checkds' request, 'named' will write out the new state for the key, updating the 'DSPublish' or 'DSRemoved' timing metadata. This replaces the "parent-registration-delay" configuration option, this was unreliable because it was purely time based (if the user did not actually submit the new DS to the parent for example, this could result in an invalid DNSSEC state). Because we cannot rely on the parent registration delay for state transition, we need to replace it with a different guard. Instead, if a key wants its DS state to be moved to RUMOURED, the "DSPublish" time must be set and must not be in the future. If a key wants its DS state to be moved to UNRETENTIVE, the "DSRemoved" time must be set and must not be in the future. By default, with '-checkds' you set the time that the DS has been published or withdrawn to now, but you can set a different time with '-when'. If there is only one KSK for the zone, that key has its DS state moved to RUMOURED. If there are multiple keys for the zone, specify the right key with '-key'.
2020-07-31 08:37:51 +02:00
}
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
if (isc_log_wouldlog(ISC_LOG_NOTICE)) {
Add checkds log notice When the checkds published/withdrawn is activated, log a notice. Can be used for testing, but also operationally useful.
2021-06-24 16:26:06 +02:00
char keystr[DST_KEY_FORMATSIZE];
char timestr[26]; /* Minimal buf as per ctime_r() spec. */
dst_key_format(ksk_key->key, keystr, sizeof(keystr));
isc_stdtime_tostring(when, timestr, sizeof(timestr));
Remove logging context (isc_log_t) from the public namespace Now that the logging uses single global context, remove the isc_log_t from the public namespace.
2024-08-13 18:20:26 +02:00
isc_log_write(DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
ISC_LOG_NOTICE,
Add checkds log notice When the checkds published/withdrawn is activated, log a notice. Can be used for testing, but also operationally useful.
2021-06-24 16:26:06 +02:00
"keymgr: checkds DS for key %s seen %s at %s",
keystr, dspublish ? "published" : "withdrawn",
timestr);
}
Implement 'rndc dnssec -checkds' Add a new 'rndc' command 'dnssec -checkds' that allows the user to signal named that a new DS record has been seen published in the parent, or that an existing DS record has been withdrawn from the parent. Upon the 'checkds' request, 'named' will write out the new state for the key, updating the 'DSPublish' or 'DSRemoved' timing metadata. This replaces the "parent-registration-delay" configuration option, this was unreliable because it was purely time based (if the user did not actually submit the new DS to the parent for example, this could result in an invalid DNSSEC state). Because we cannot rely on the parent registration delay for state transition, we need to replace it with a different guard. Instead, if a key wants its DS state to be moved to RUMOURED, the "DSPublish" time must be set and must not be in the future. If a key wants its DS state to be moved to UNRETENTIVE, the "DSRemoved" time must be set and must not be in the future. By default, with '-checkds' you set the time that the DS has been published or withdrawn to now, but you can set a different time with '-when'. If there is only one KSK for the zone, that key has its DS state moved to RUMOURED. If there are multiple keys for the zone, specify the right key with '-key'.
2020-07-31 08:37:51 +02:00
/* Store key state and update hints. */
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
directory = dst_key_directory(ksk_key->key);
Implement 'rndc dnssec -checkds' Add a new 'rndc' command 'dnssec -checkds' that allows the user to signal named that a new DS record has been seen published in the parent, or that an existing DS record has been withdrawn from the parent. Upon the 'checkds' request, 'named' will write out the new state for the key, updating the 'DSPublish' or 'DSRemoved' timing metadata. This replaces the "parent-registration-delay" configuration option, this was unreliable because it was purely time based (if the user did not actually submit the new DS to the parent for example, this could result in an invalid DNSSEC state). Because we cannot rely on the parent registration delay for state transition, we need to replace it with a different guard. Instead, if a key wants its DS state to be moved to RUMOURED, the "DSPublish" time must be set and must not be in the future. If a key wants its DS state to be moved to UNRETENTIVE, the "DSRemoved" time must be set and must not be in the future. By default, with '-checkds' you set the time that the DS has been published or withdrawn to now, but you can set a different time with '-when'. If there is only one KSK for the zone, that key has its DS state moved to RUMOURED. If there are multiple keys for the zone, specify the right key with '-key'.
2020-07-31 08:37:51 +02:00
if (directory == NULL) {
directory = ".";
}
dns_dnssec_get_hints(ksk_key, now);
result = dst_key_tofile(ksk_key->key, options, directory);
Check if key metadata is modified before writing Add a new parameter to the dst_key structure, mark a key modified if dst_key_(un)set[bool,num,state,time] is called. Only write out key files during a keymgr run if the metadata has changed.
2022-05-03 12:28:31 +02:00
if (result == ISC_R_SUCCESS) {
dst_key_setmodified(ksk_key->key, false);
}
Implement 'rndc dnssec -checkds' Add a new 'rndc' command 'dnssec -checkds' that allows the user to signal named that a new DS record has been seen published in the parent, or that an existing DS record has been withdrawn from the parent. Upon the 'checkds' request, 'named' will write out the new state for the key, updating the 'DSPublish' or 'DSRemoved' timing metadata. This replaces the "parent-registration-delay" configuration option, this was unreliable because it was purely time based (if the user did not actually submit the new DS to the parent for example, this could result in an invalid DNSSEC state). Because we cannot rely on the parent registration delay for state transition, we need to replace it with a different guard. Instead, if a key wants its DS state to be moved to RUMOURED, the "DSPublish" time must be set and must not be in the future. If a key wants its DS state to be moved to UNRETENTIVE, the "DSRemoved" time must be set and must not be in the future. By default, with '-checkds' you set the time that the DS has been published or withdrawn to now, but you can set a different time with '-when'. If there is only one KSK for the zone, that key has its DS state moved to RUMOURED. If there are multiple keys for the zone, specify the right key with '-key'.
2020-07-31 08:37:51 +02:00
return result;
}
isc_result_t
dns_keymgr_checkds(dns_kasp_t *kasp, dns_dnsseckeylist_t *keyring,
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
isc_stdtime_t now, isc_stdtime_t when, bool dspublish) {
return keymgr_checkds(kasp, keyring, now, when, dspublish, 0, 0, false);
Implement 'rndc dnssec -checkds' Add a new 'rndc' command 'dnssec -checkds' that allows the user to signal named that a new DS record has been seen published in the parent, or that an existing DS record has been withdrawn from the parent. Upon the 'checkds' request, 'named' will write out the new state for the key, updating the 'DSPublish' or 'DSRemoved' timing metadata. This replaces the "parent-registration-delay" configuration option, this was unreliable because it was purely time based (if the user did not actually submit the new DS to the parent for example, this could result in an invalid DNSSEC state). Because we cannot rely on the parent registration delay for state transition, we need to replace it with a different guard. Instead, if a key wants its DS state to be moved to RUMOURED, the "DSPublish" time must be set and must not be in the future. If a key wants its DS state to be moved to UNRETENTIVE, the "DSRemoved" time must be set and must not be in the future. By default, with '-checkds' you set the time that the DS has been published or withdrawn to now, but you can set a different time with '-when'. If there is only one KSK for the zone, that key has its DS state moved to RUMOURED. If there are multiple keys for the zone, specify the right key with '-key'.
2020-07-31 08:37:51 +02:00
}
isc_result_t
dns_keymgr_checkds_id(dns_kasp_t *kasp, dns_dnsseckeylist_t *keyring,
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
isc_stdtime_t now, isc_stdtime_t when, bool dspublish,
dns_keytag_t id, unsigned int alg) {
return keymgr_checkds(kasp, keyring, now, when, dspublish, id, alg,
true);
Implement 'rndc dnssec -checkds' Add a new 'rndc' command 'dnssec -checkds' that allows the user to signal named that a new DS record has been seen published in the parent, or that an existing DS record has been withdrawn from the parent. Upon the 'checkds' request, 'named' will write out the new state for the key, updating the 'DSPublish' or 'DSRemoved' timing metadata. This replaces the "parent-registration-delay" configuration option, this was unreliable because it was purely time based (if the user did not actually submit the new DS to the parent for example, this could result in an invalid DNSSEC state). Because we cannot rely on the parent registration delay for state transition, we need to replace it with a different guard. Instead, if a key wants its DS state to be moved to RUMOURED, the "DSPublish" time must be set and must not be in the future. If a key wants its DS state to be moved to UNRETENTIVE, the "DSRemoved" time must be set and must not be in the future. By default, with '-checkds' you set the time that the DS has been published or withdrawn to now, but you can set a different time with '-when'. If there is only one KSK for the zone, that key has its DS state moved to RUMOURED. If there are multiple keys for the zone, specify the right key with '-key'.
2020-07-31 08:37:51 +02:00
}
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
static isc_result_t
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
keytime_status(dst_key_t *key, isc_stdtime_t now, isc_buffer_t *buf,
const char *pre, int ks, int kt) {
char timestr[26]; /* Minimal buf as per ctime_r() spec. */
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
isc_result_t result = ISC_R_SUCCESS;
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
isc_stdtime_t when = 0;
Cleanup keymgr.c Three small cleanups: 1. Remove an unused keystr/dst_key_format. 2. Initialize a dst_key_state_t state with NA. 3. Update false comment about local policy (local policy only adds barrier on transitions to the RUMOURED state, not the UNRETENTIVE state).
2021-01-07 12:26:53 +01:00
dst_key_state_t state = NA;
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(buf, "%s", pre));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
(void)dst_key_getstate(key, ks, &state);
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
isc_result_t r = dst_key_gettime(key, kt, &when);
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
if (state == RUMOURED || state == OMNIPRESENT) {
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(buf, "yes - since "));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
} else if (now < when) {
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(buf, "no - scheduled "));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
} else {
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
return isc_buffer_printf(buf, "no\n");
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
}
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
if (r == ISC_R_SUCCESS) {
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
isc_stdtime_tostring(when, timestr, sizeof(timestr));
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(buf, "%s\n", timestr));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
}
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
failure:
return result;
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
}
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
static isc_result_t
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
rollover_status(dns_dnsseckey_t *dkey, dns_kasp_t *kasp, isc_stdtime_t now,
isc_buffer_t *buf, bool zsk) {
char timestr[26]; /* Minimal buf as per ctime_r() spec. */
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
isc_result_t result = ISC_R_SUCCESS;
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
isc_stdtime_t active_time = 0;
dst_key_state_t state = NA, goal = NA;
int rrsig, active, retire;
dst_key_t *key = dkey->key;
if (zsk) {
rrsig = DST_KEY_ZRRSIG;
active = DST_TIME_ACTIVATE;
retire = DST_TIME_INACTIVE;
} else {
rrsig = DST_KEY_KRRSIG;
active = DST_TIME_PUBLISH;
retire = DST_TIME_DELETE;
}
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(buf, "\n"));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
(void)dst_key_getstate(key, DST_KEY_GOAL, &goal);
(void)dst_key_getstate(key, rrsig, &state);
(void)dst_key_gettime(key, active, &active_time);
if (active_time == 0) {
// only interested in keys that were once active.
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
return ISC_R_SUCCESS;
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
}
if (goal == HIDDEN && (state == UNRETENTIVE || state == HIDDEN)) {
isc_stdtime_t remove_time = 0;
// is the key removed yet?
state = NA;
(void)dst_key_getstate(key, DST_KEY_DNSKEY, &state);
if (state == RUMOURED || state == OMNIPRESENT) {
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
result = dst_key_gettime(key, DST_TIME_DELETE,
&remove_time);
if (result == ISC_R_SUCCESS) {
RETERR(isc_buffer_printf(
buf, " Key is retired, will be "
"removed on "));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
isc_stdtime_tostring(remove_time, timestr,
sizeof(timestr));
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(buf, "%s", timestr));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
}
} else {
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(buf, " Key has been removed "
"from the zone"));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
}
} else {
isc_stdtime_t retire_time = 0;
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
result = dst_key_gettime(key, retire, &retire_time);
if (result == ISC_R_SUCCESS) {
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
if (now < retire_time) {
if (goal == OMNIPRESENT) {
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(
buf, " Next rollover "
"scheduled on "));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
retire_time = keymgr_prepublication_time(
No longer update key lifetime if key is retired The key lifetime should no longer be adjusted if the key is being retired earlier, for example because a manual rollover was started. This would falsely be seen as a dnssec-policy lifetime reconfiguration, and would adjust the retire/removed time again. This also means we should update the status output, and the next rollover scheduled is now calculated using (retire-active) instead of key lifetime.
2024-06-24 15:18:40 +02:00
dkey, kasp,
(retire_time - active_time),
now);
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
} else {
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(
buf, " Key will retire on "));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
}
} else {
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(buf, " Rollover is "
"due since "));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
}
isc_stdtime_tostring(retire_time, timestr,
sizeof(timestr));
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(buf, "%s", timestr));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
} else {
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(buf,
" No rollover scheduled"));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
}
}
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(buf, "\n"));
failure:
return result;
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
}
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
static isc_result_t
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
keystate_status(dst_key_t *key, isc_buffer_t *buf, const char *pre, int ks) {
dst_key_state_t state = NA;
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
isc_result_t result = ISC_R_SUCCESS;
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
(void)dst_key_getstate(key, ks, &state);
switch (state) {
case HIDDEN:
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(buf, " - %shidden\n", pre));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
break;
case RUMOURED:
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(buf, " - %srumoured\n", pre));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
break;
case OMNIPRESENT:
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(buf, " - %somnipresent\n", pre));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
break;
case UNRETENTIVE:
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(buf, " - %sunretentive\n", pre));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
break;
case NA:
default:
/* print nothing */
break;
}
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
failure:
return result;
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
}
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
isc_result_t
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
dns_keymgr_status(dns_kasp_t *kasp, dns_dnsseckeylist_t *keyring,
isc_stdtime_t now, char *out, size_t out_len) {
isc_buffer_t buf;
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
isc_result_t result = ISC_R_SUCCESS;
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
char timestr[26]; /* Minimal buf as per ctime_r() spec. */
REQUIRE(DNS_KASP_VALID(kasp));
REQUIRE(keyring != NULL);
REQUIRE(out != NULL);
isc_buffer_init(&buf, out, out_len);
// policy name
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(&buf, "dnssec-policy: %s\n",
dns_kasp_getname(kasp)));
RETERR(isc_buffer_printf(&buf, "current time: "));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
isc_stdtime_tostring(now, timestr, sizeof(timestr));
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(&buf, "%s\n", timestr));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
for (dns_dnsseckey_t *dkey = ISC_LIST_HEAD(*keyring); dkey != NULL;
dkey = ISC_LIST_NEXT(dkey, link))
{
char algstr[DNS_NAME_FORMATSIZE];
bool ksk = false, zsk = false;
if (dst_key_is_unused(dkey->key)) {
continue;
}
// key data
dns_secalg_format((dns_secalg_t)dst_key_alg(dkey->key), algstr,
sizeof(algstr));
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(isc_buffer_printf(&buf, "\nkey: %d (%s), %s\n",
dst_key_id(dkey->key), algstr,
keymgr_keyrole(dkey->key)));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
// publish status
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(keytime_status(dkey->key, now, &buf,
" published: ", DST_KEY_DNSKEY,
DST_TIME_PUBLISH));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
// signing status
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
result = dst_key_getbool(dkey->key, DST_BOOL_KSK, &ksk);
if (result == ISC_R_SUCCESS && ksk) {
RETERR(keytime_status(
dkey->key, now, &buf, " key signing: ",
DST_KEY_KRRSIG, DST_TIME_PUBLISH));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
}
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
result = dst_key_getbool(dkey->key, DST_BOOL_ZSK, &zsk);
if (result == ISC_R_SUCCESS && zsk) {
RETERR(keytime_status(
dkey->key, now, &buf, " zone signing: ",
DST_KEY_ZRRSIG, DST_TIME_ACTIVATE));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
}
// rollover status
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(rollover_status(dkey, kasp, now, &buf, zsk));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
// key states
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
RETERR(keystate_status(dkey->key, &buf,
"goal: ", DST_KEY_GOAL));
RETERR(keystate_status(dkey->key, &buf,
"dnskey: ", DST_KEY_DNSKEY));
RETERR(keystate_status(dkey->key, &buf,
"ds: ", DST_KEY_DS));
RETERR(keystate_status(dkey->key, &buf,
"zone rrsig: ", DST_KEY_ZRRSIG));
RETERR(keystate_status(dkey->key, &buf,
"key rrsig: ", DST_KEY_KRRSIG));
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
}
Fix possible truncation in dns_keymgr_status() If the generated status output exceeds 4096 it was silently truncated, now we output that the status was truncated.
2024-12-12 14:40:43 +01:00
failure:
return result;
Output rndc dnssec -status Implement the 'rndc dnssec -status' command that will output some information about the key states, such as which policy is used for the zone, what keys are in use, and when rollover is scheduled. Add loose testing in the kasp system test, the actual times are already tested via key file inspection.
2020-06-18 17:07:52 +02:00
}
Add manual key rollover logic Add to the keymgr a function that will schedule a rollover. This basically means setting the time when the key needs to retire, and updating the key lifetime, then update the state file. The next time that named runs the keymgr the new lifetime will be taken into account.
2020-08-21 15:31:57 +02:00
isc_result_t
dns_keymgr_rollover(dns_kasp_t *kasp, dns_dnsseckeylist_t *keyring,
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
isc_stdtime_t now, isc_stdtime_t when, dns_keytag_t id,
Add manual key rollover logic Add to the keymgr a function that will schedule a rollover. This basically means setting the time when the key needs to retire, and updating the key lifetime, then update the state file. The next time that named runs the keymgr the new lifetime will be taken into account.
2020-08-21 15:31:57 +02:00
unsigned int algorithm) {
int options = (DST_TYPE_PRIVATE | DST_TYPE_PUBLIC | DST_TYPE_STATE);
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
const char *directory = NULL;
Add manual key rollover logic Add to the keymgr a function that will schedule a rollover. This basically means setting the time when the key needs to retire, and updating the key lifetime, then update the state file. The next time that named runs the keymgr the new lifetime will be taken into account.
2020-08-21 15:31:57 +02:00
isc_result_t result;
dns_dnsseckey_t *key = NULL;
isc_stdtime_t active, retire, prepub;
REQUIRE(DNS_KASP_VALID(kasp));
REQUIRE(keyring != NULL);
for (dns_dnsseckey_t *dkey = ISC_LIST_HEAD(*keyring); dkey != NULL;
dkey = ISC_LIST_NEXT(dkey, link))
{
if (dst_key_id(dkey->key) != id) {
continue;
}
if (algorithm > 0 && dst_key_alg(dkey->key) != algorithm) {
continue;
}
if (key != NULL) {
/*
* Only rollover for one key at a time.
*/
Use explicit result codes for 'rndc dnssec' cmd It is better to add new result codes than to overload existing codes.
2020-09-04 11:42:52 +02:00
return DNS_R_TOOMANYKEYS;
Add manual key rollover logic Add to the keymgr a function that will schedule a rollover. This basically means setting the time when the key needs to retire, and updating the key lifetime, then update the state file. The next time that named runs the keymgr the new lifetime will be taken into account.
2020-08-21 15:31:57 +02:00
}
key = dkey;
}
if (key == NULL) {
Use explicit result codes for 'rndc dnssec' cmd It is better to add new result codes than to overload existing codes.
2020-09-04 11:42:52 +02:00
return DNS_R_NOKEYMATCH;
Add manual key rollover logic Add to the keymgr a function that will schedule a rollover. This basically means setting the time when the key needs to retire, and updating the key lifetime, then update the state file. The next time that named runs the keymgr the new lifetime will be taken into account.
2020-08-21 15:31:57 +02:00
}
result = dst_key_gettime(key->key, DST_TIME_ACTIVATE, &active);
Test rndc rollover inactive key When users (accidentally) try to roll an inactive key, throw an error.
2020-08-24 10:03:02 +02:00
if (result != ISC_R_SUCCESS || active > now) {
Use explicit result codes for 'rndc dnssec' cmd It is better to add new result codes than to overload existing codes.
2020-09-04 11:42:52 +02:00
return DNS_R_KEYNOTACTIVE;
Add manual key rollover logic Add to the keymgr a function that will schedule a rollover. This basically means setting the time when the key needs to retire, and updating the key lifetime, then update the state file. The next time that named runs the keymgr the new lifetime will be taken into account.
2020-08-21 15:31:57 +02:00
}
result = dst_key_gettime(key->key, DST_TIME_INACTIVE, &retire);
if (result != ISC_R_SUCCESS) {
/**
* Default to as if this key was not scheduled to
* become retired, as if it had unlimited lifetime.
*/
retire = 0;
}
/**
* Usually when is set to now, which is before the scheduled
* prepublication time, meaning we reduce the lifetime of the
* key. But in some cases, the lifetime can also be extended.
* We accept it, but we can return an error here if that
* turns out to be unintuitive behavior.
*/
prepub = dst_key_getttl(key->key) + dns_kasp_publishsafety(kasp) +
dns_kasp_zonepropagationdelay(kasp);
retire = when + prepub;
dst_key_settime(key->key, DST_TIME_INACTIVE, retire);
/* Store key state and update hints. */
Use dst_key's directory when writing key files When writing key files to disk, use the internally stored directory. Add an access function 'dst_key_directory()'. Most calls to keymgr functions no longer need to provide the key-directory value. Only 'dns_keymgr_run' still needs access to the zone's key-directory in case the key-store is set to the built-in key-directory.
2022-03-09 11:33:03 +01:00
directory = dst_key_directory(key->key);
Add manual key rollover logic Add to the keymgr a function that will schedule a rollover. This basically means setting the time when the key needs to retire, and updating the key lifetime, then update the state file. The next time that named runs the keymgr the new lifetime will be taken into account.
2020-08-21 15:31:57 +02:00
if (directory == NULL) {
directory = ".";
}
dns_dnssec_get_hints(key, now);
result = dst_key_tofile(key->key, options, directory);
Check if key metadata is modified before writing Add a new parameter to the dst_key structure, mark a key modified if dst_key_(un)set[bool,num,state,time] is called. Only write out key files during a keymgr run if the metadata has changed.
2022-05-03 12:28:31 +02:00
if (result == ISC_R_SUCCESS) {
dst_key_setmodified(key->key, false);
}
Add manual key rollover logic Add to the keymgr a function that will schedule a rollover. This basically means setting the time when the key needs to retire, and updating the key lifetime, then update the state file. The next time that named runs the keymgr the new lifetime will be taken into account.
2020-08-21 15:31:57 +02:00
return result;
}
Update key states in offline-ksk mode With offline-ksk enabled, we don't run the keymgr because the key timings are determined by the SKR. We do update the key states but we derive them from the timing metadata. Then, we can skip a other tasks in offline-ksk mode, like DS checking at the parent and CDS synchronization, because the CDS and CDNSKEY RRsets also come from the SKR.
2024-06-19 13:41:07 +02:00
isc_result_t
dns_keymgr_offline(const dns_name_t *origin, dns_dnsseckeylist_t *keyring,
dns_kasp_t *kasp, isc_stdtime_t now,
isc_stdtime_t *nexttime) {
isc_result_t result = ISC_R_SUCCESS;
int options = (DST_TYPE_PRIVATE | DST_TYPE_PUBLIC | DST_TYPE_STATE);
char keystr[DST_KEY_FORMATSIZE];
*nexttime = 0;
/* Store key states and update hints. */
for (dns_dnsseckey_t *dkey = ISC_LIST_HEAD(*keyring); dkey != NULL;
dkey = ISC_LIST_NEXT(dkey, link))
{
bool modified;
bool ksk = false, zsk = false;
isc_stdtime_t active = 0, published = 0, inactive = 0,
remove = 0;
isc_stdtime_t lastchange = 0, nextchange = 0;
dst_key_state_t dnskey_state = HIDDEN, zrrsig_state = HIDDEN,
goal_state = HIDDEN;
Fix bug in dns_keymgr_offline If the ZSK has lifetime unlimited, the timing metadata "Inactive" and "Delete" cannot be found and is treated as an error. Fix by allowing these metadata to not exist.
2024-09-03 11:52:19 +02:00
dst_key_state_t current_dnskey = HIDDEN,
current_zrrsig = HIDDEN, current_goal = HIDDEN;
Update key states in offline-ksk mode With offline-ksk enabled, we don't run the keymgr because the key timings are determined by the SKR. We do update the key states but we derive them from the timing metadata. Then, we can skip a other tasks in offline-ksk mode, like DS checking at the parent and CDS synchronization, because the CDS and CDNSKEY RRsets also come from the SKR.
2024-06-19 13:41:07 +02:00
(void)dst_key_role(dkey->key, &ksk, &zsk);
if (ksk || !zsk) {
continue;
}
keymgr_key_init(dkey, kasp, now, false);
/* Get current metadata */
RETERR(dst_key_getstate(dkey->key, DST_KEY_DNSKEY,
&current_dnskey));
RETERR(dst_key_getstate(dkey->key, DST_KEY_ZRRSIG,
&current_zrrsig));
RETERR(dst_key_getstate(dkey->key, DST_KEY_GOAL,
&current_goal));
RETERR(dst_key_gettime(dkey->key, DST_TIME_PUBLISH,
&published));
RETERR(dst_key_gettime(dkey->key, DST_TIME_ACTIVATE, &active));
Fix bug in dns_keymgr_offline If the ZSK has lifetime unlimited, the timing metadata "Inactive" and "Delete" cannot be found and is treated as an error. Fix by allowing these metadata to not exist.
2024-09-03 11:52:19 +02:00
(void)dst_key_gettime(dkey->key, DST_TIME_INACTIVE, &inactive);
(void)dst_key_gettime(dkey->key, DST_TIME_DELETE, &remove);
Update key states in offline-ksk mode With offline-ksk enabled, we don't run the keymgr because the key timings are determined by the SKR. We do update the key states but we derive them from the timing metadata. Then, we can skip a other tasks in offline-ksk mode, like DS checking at the parent and CDS synchronization, because the CDS and CDNSKEY RRsets also come from the SKR.
2024-06-19 13:41:07 +02:00
/* Determine key states from the metadata. */
if (active <= now) {
dns_ttl_t ttlsig = dns_kasp_zonemaxttl(kasp, true);
ttlsig += dns_kasp_zonepropagationdelay(kasp);
if ((active + ttlsig) <= now) {
zrrsig_state = OMNIPRESENT;
} else {
zrrsig_state = RUMOURED;
(void)dst_key_gettime(dkey->key,
DST_TIME_ZRRSIG,
&lastchange);
nextchange = lastchange + ttlsig +
dns_kasp_retiresafety(kasp);
}
goal_state = OMNIPRESENT;
}
if (published <= now) {
dns_ttl_t key_ttl = dst_key_getttl(dkey->key);
key_ttl += dns_kasp_zonepropagationdelay(kasp);
if ((published + key_ttl) <= now) {
dnskey_state = OMNIPRESENT;
} else {
dnskey_state = RUMOURED;
(void)dst_key_gettime(dkey->key,
DST_TIME_DNSKEY,
&lastchange);
nextchange = lastchange + key_ttl +
dns_kasp_publishsafety(kasp);
}
goal_state = OMNIPRESENT;
}
Fix bug in dns_keymgr_offline If the ZSK has lifetime unlimited, the timing metadata "Inactive" and "Delete" cannot be found and is treated as an error. Fix by allowing these metadata to not exist.
2024-09-03 11:52:19 +02:00
if (inactive > 0 && inactive <= now) {
Update key states in offline-ksk mode With offline-ksk enabled, we don't run the keymgr because the key timings are determined by the SKR. We do update the key states but we derive them from the timing metadata. Then, we can skip a other tasks in offline-ksk mode, like DS checking at the parent and CDS synchronization, because the CDS and CDNSKEY RRsets also come from the SKR.
2024-06-19 13:41:07 +02:00
dns_ttl_t ttlsig = dns_kasp_zonemaxttl(kasp, true);
ttlsig += dns_kasp_zonepropagationdelay(kasp);
if ((inactive + ttlsig) <= now) {
zrrsig_state = HIDDEN;
} else {
zrrsig_state = UNRETENTIVE;
(void)dst_key_gettime(dkey->key,
DST_TIME_ZRRSIG,
&lastchange);
nextchange = lastchange + ttlsig +
dns_kasp_retiresafety(kasp);
}
goal_state = HIDDEN;
}
Fix bug in dns_keymgr_offline If the ZSK has lifetime unlimited, the timing metadata "Inactive" and "Delete" cannot be found and is treated as an error. Fix by allowing these metadata to not exist.
2024-09-03 11:52:19 +02:00
if (remove > 0 && remove <= now) {
Update key states in offline-ksk mode With offline-ksk enabled, we don't run the keymgr because the key timings are determined by the SKR. We do update the key states but we derive them from the timing metadata. Then, we can skip a other tasks in offline-ksk mode, like DS checking at the parent and CDS synchronization, because the CDS and CDNSKEY RRsets also come from the SKR.
2024-06-19 13:41:07 +02:00
dns_ttl_t key_ttl = dst_key_getttl(dkey->key);
key_ttl += dns_kasp_zonepropagationdelay(kasp);
if ((remove + key_ttl) <= now) {
dnskey_state = HIDDEN;
} else {
dnskey_state = UNRETENTIVE;
(void)dst_key_gettime(dkey->key,
DST_TIME_DNSKEY,
&lastchange);
nextchange =
lastchange + key_ttl +
dns_kasp_zonepropagationdelay(kasp);
}
zrrsig_state = HIDDEN;
goal_state = HIDDEN;
}
if ((*nexttime == 0 || *nexttime > nextchange) &&
nextchange > 0)
{
*nexttime = nextchange;
}
/* Update key states if necessary. */
if (goal_state != current_goal) {
dst_key_setstate(dkey->key, DST_KEY_GOAL, goal_state);
}
if (dnskey_state != current_dnskey) {
dst_key_setstate(dkey->key, DST_KEY_DNSKEY,
dnskey_state);
dst_key_settime(dkey->key, DST_TIME_DNSKEY, now);
}
if (zrrsig_state != current_zrrsig) {
dst_key_setstate(dkey->key, DST_KEY_ZRRSIG,
zrrsig_state);
dst_key_settime(dkey->key, DST_TIME_ZRRSIG, now);
if (zrrsig_state == RUMOURED) {
dkey->first_sign = true;
}
}
modified = dst_key_ismodified(dkey->key);
if (modified) {
const char *directory = dst_key_directory(dkey->key);
if (directory == NULL) {
directory = ".";
}
dns_dnssec_get_hints(dkey, now);
RETERR(dst_key_tofile(dkey->key, options, directory));
dst_key_setmodified(dkey->key, false);
if (!isc_log_wouldlog(ISC_LOG_DEBUG(3))) {
continue;
}
dst_key_format(dkey->key, keystr, sizeof(keystr));
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
DNS_LOGMODULE_DNSSEC, ISC_LOG_DEBUG(3),
"keymgr: DNSKEY %s (%s) "
"saved to directory %s, policy %s",
keystr, keymgr_keyrole(dkey->key),
directory, dns_kasp_getname(kasp));
}
dst_key_setmodified(dkey->key, false);
}
result = ISC_R_SUCCESS;
failure:
if (isc_log_wouldlog(ISC_LOG_DEBUG(3))) {
char namebuf[DNS_NAME_FORMATSIZE];
dns_name_format(origin, namebuf, sizeof(namebuf));
isc_log_write(DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
ISC_LOG_DEBUG(3), "keymgr: %s (offline-ksk) done",
namebuf);
}
return result;
}
Reference in New Issue Copy Permalink