2019-10-17 11:19:35 +02:00
|
|
|
/*
|
|
|
|
* Copyright (C) Internet Systems Consortium, Inc. ("ISC")
|
|
|
|
*
|
|
|
|
* SPDX-License-Identifier: MPL-2.0
|
2021-06-03 08:37:05 +02:00
|
|
|
*
|
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>
|
2021-02-08 15:15:57 +01:00
|
|
|
#include <unistd.h>
|
2019-10-17 11:19:35 +02:00
|
|
|
|
|
|
|
#include <isc/buffer.h>
|
|
|
|
#include <isc/dir.h>
|
2024-08-14 13:25:50 +02:00
|
|
|
#include <isc/log.h>
|
2019-10-17 11:19:35 +02:00
|
|
|
#include <isc/mem.h>
|
2021-10-04 17:14:53 +02:00
|
|
|
#include <isc/result.h>
|
2019-10-17 11:19:35 +02:00
|
|
|
#include <isc/string.h>
|
2022-02-28 11:50:43 +01:00
|
|
|
#include <isc/time.h>
|
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)
|
|
|
|
|
|
|
|
/*
|
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.
|
2019-10-17 11:19:35 +02:00
|
|
|
*/
|
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); \
|
|
|
|
\
|
2024-08-13 18:20:26 +02:00
|
|
|
if (isc_log_wouldlog(ISC_LOG_DEBUG(1))) { \
|
2023-01-06 12:39:10 +01:00
|
|
|
dst_key_format((key), keystr, sizeof(keystr)); \
|
|
|
|
isc_log_write( \
|
2024-08-13 18:20:26 +02:00
|
|
|
DNS_LOGCATEGORY_DNSSEC, \
|
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)", \
|
2024-12-12 14:40:43 +01:00
|
|
|
keystr, keymgr_keyrole(key), \
|
2023-01-06 12:39:10 +01:00
|
|
|
keystatetags[state], \
|
|
|
|
keystatestrings[target], \
|
|
|
|
dns_kasp_getname(kasp)); \
|
|
|
|
} \
|
|
|
|
} \
|
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" };
|
|
|
|
|
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));
|
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);
|
2024-06-26 14:49:51 +10:00
|
|
|
}
|
|
|
|
|
2019-10-17 11:19:35 +02:00
|
|
|
/*
|
|
|
|
* Print key role.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
static const char *
|
|
|
|
keymgr_keyrole(dst_key_t *key) {
|
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";
|
|
|
|
}
|
2019-10-17 11:19:35 +02:00
|
|
|
if (ksk && zsk) {
|
|
|
|
return "CSK";
|
|
|
|
} else if (ksk) {
|
|
|
|
return "KSK";
|
2020-02-05 16:04:09 +11:00
|
|
|
} else if (zsk) {
|
2019-10-17 11:19:35 +02:00
|
|
|
return "ZSK";
|
|
|
|
}
|
|
|
|
return "NOSIGN";
|
|
|
|
}
|
|
|
|
|
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) {
|
2023-07-26 11:50:57 +02:00
|
|
|
dns_ttl_t ttlsig = dns_kasp_zonemaxttl(kasp, true);
|
2020-04-28 15:05:43 +02:00
|
|
|
/* ZSK: Iret = Dsgn + Dprp + TTLsig */
|
2023-07-26 11:50:57 +02:00
|
|
|
zsk_remove =
|
|
|
|
retire + ttlsig + dns_kasp_zonepropagationdelay(kasp) +
|
|
|
|
dns_kasp_retiresafety(kasp) + dns_kasp_signdelay(kasp);
|
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);
|
|
|
|
}
|
2020-05-11 15:12:32 +02:00
|
|
|
|
2022-06-21 12:45:54 +02:00
|
|
|
remove = ISC_MAX(ksk_remove, zsk_remove);
|
2020-04-28 15:05:43 +02:00
|
|
|
dst_key_settime(key->key, DST_TIME_DELETE, remove);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2022-06-21 12:45:54 +02:00
|
|
|
* Set the SyncPublish time (when the DS may be submitted to the parent).
|
2020-04-28 15:05:43 +02:00
|
|
|
*
|
|
|
|
*/
|
2024-09-03 17:24:22 +02:00
|
|
|
void
|
|
|
|
dns_keymgr_settime_syncpublish(dst_key_t *key, dns_kasp_t *kasp, bool first) {
|
2020-04-28 15:05:43 +02:00
|
|
|
isc_stdtime_t published, syncpublish;
|
|
|
|
bool ksk = false;
|
|
|
|
isc_result_t ret;
|
|
|
|
|
|
|
|
REQUIRE(key != NULL);
|
|
|
|
|
2024-09-03 17:24:22 +02:00
|
|
|
ret = dst_key_gettime(key, DST_TIME_PUBLISH, &published);
|
2020-04-28 15:05:43 +02:00
|
|
|
if (ret != ISC_R_SUCCESS) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2024-09-03 17:24:22 +02:00
|
|
|
ret = dst_key_getbool(key, DST_BOOL_KSK, &ksk);
|
2020-04-28 15:05:43 +02:00
|
|
|
if (ret != ISC_R_SUCCESS || !ksk) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2024-09-03 17:24:22 +02:00
|
|
|
syncpublish = published + dst_key_getttl(key) +
|
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;
|
2023-07-26 11:50:57 +02:00
|
|
|
dns_ttl_t ttlsig = dns_kasp_zonemaxttl(kasp, true);
|
|
|
|
zrrsig_present = published + ttlsig +
|
2025-03-03 12:07:03 +01:00
|
|
|
dns_kasp_zonepropagationdelay(kasp);
|
2020-04-28 15:05:43 +02:00
|
|
|
if (zrrsig_present > syncpublish) {
|
|
|
|
syncpublish = zrrsig_present;
|
|
|
|
}
|
|
|
|
}
|
2024-09-03 17:24:22 +02:00
|
|
|
dst_key_settime(key, DST_TIME_SYNCPUBLISH, syncpublish);
|
2025-03-04 17:14:33 +01:00
|
|
|
|
|
|
|
uint32_t lifetime = 0;
|
|
|
|
ret = dst_key_getnum(key, DST_NUM_LIFETIME, &lifetime);
|
|
|
|
if (ret == ISC_R_SUCCESS && lifetime > 0) {
|
|
|
|
dst_key_settime(key, DST_TIME_SYNCDELETE,
|
|
|
|
syncpublish + lifetime);
|
|
|
|
}
|
2020-04-28 15:05:43 +02:00
|
|
|
}
|
|
|
|
|
2019-10-17 11:19:35 +02:00
|
|
|
/*
|
|
|
|
* Calculate prepublication time of a successor key of 'key'.
|
|
|
|
* This function can have side effects:
|
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.
|
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.
|
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;
|
2020-03-27 10:28:22 +01:00
|
|
|
isc_stdtime_t active, retire, pub, prepub;
|
2020-05-11 15:12:32 +02:00
|
|
|
bool zsk = false, ksk = false;
|
2019-10-17 11:19:35 +02:00
|
|
|
|
|
|
|
REQUIRE(key != NULL);
|
|
|
|
REQUIRE(key->key != NULL);
|
|
|
|
|
|
|
|
active = 0;
|
2020-04-30 13:22:23 +02:00
|
|
|
pub = 0;
|
2019-10-17 11:19:35 +02:00
|
|
|
retire = 0;
|
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;
|
|
|
|
}
|
|
|
|
|
2025-03-04 17:14:33 +01:00
|
|
|
/*
|
|
|
|
* To calculate phase out times ("Retired", "Removed", ...),
|
|
|
|
* the key lifetime is required.
|
|
|
|
*/
|
|
|
|
uint32_t klifetime = 0;
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2020-04-30 13:22:23 +02:00
|
|
|
/*
|
|
|
|
* Calculate prepublication time.
|
|
|
|
*/
|
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) {
|
2020-04-30 13:22:23 +02:00
|
|
|
isc_stdtime_t syncpub;
|
2019-10-17 11:19:35 +02:00
|
|
|
|
|
|
|
/*
|
2020-04-30 13:22:23 +02:00
|
|
|
* Set PublishCDS if not set.
|
2019-10-17 11:19:35 +02:00
|
|
|
*/
|
2020-04-30 13:22:23 +02:00
|
|
|
ret = dst_key_gettime(key->key, DST_TIME_SYNCPUBLISH, &syncpub);
|
2019-10-17 11:19:35 +02:00
|
|
|
if (ret != ISC_R_SUCCESS) {
|
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.
|
|
|
|
*/
|
2023-07-26 11:50:57 +02:00
|
|
|
dns_ttl_t ttlsig = dns_kasp_zonemaxttl(kasp,
|
|
|
|
true);
|
|
|
|
syncpub2 = pub + ttlsig +
|
2020-04-30 13:22:23 +02:00
|
|
|
dns_kasp_zonepropagationdelay(kasp);
|
|
|
|
}
|
|
|
|
|
2022-06-21 12:45:54 +02:00
|
|
|
syncpub = ISC_MAX(syncpub1, syncpub2);
|
2020-04-30 13:22:23 +02:00
|
|
|
dst_key_settime(key->key, DST_TIME_SYNCPUBLISH,
|
|
|
|
syncpub);
|
2025-03-04 17:14:33 +01:00
|
|
|
if (klifetime > 0) {
|
|
|
|
dst_key_settime(key->key, DST_TIME_SYNCDELETE,
|
|
|
|
syncpub + klifetime);
|
|
|
|
}
|
2020-03-27 10:28:22 +01:00
|
|
|
}
|
2020-05-11 15:12:32 +02:00
|
|
|
}
|
2020-05-04 12:30:40 +02:00
|
|
|
|
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.
|
|
|
|
*/
|
2020-05-11 15:12:32 +02:00
|
|
|
(void)dst_key_getbool(key->key, DST_BOOL_ZSK, &zsk);
|
2020-04-30 13:22:23 +02:00
|
|
|
|
|
|
|
ret = dst_key_gettime(key->key, DST_TIME_INACTIVE, &retire);
|
|
|
|
if (ret != ISC_R_SUCCESS) {
|
2019-10-17 11:19:35 +02:00
|
|
|
if (klifetime == 0) {
|
|
|
|
/*
|
|
|
|
* No inactive time and no lifetime,
|
|
|
|
* so no need to start a rollover.
|
|
|
|
*/
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2024-06-26 14:39:04 +10:00
|
|
|
if (ISC_OVERFLOW_ADD(active, klifetime, &retire)) {
|
2024-06-26 14:49:51 +10:00
|
|
|
log_key_overflow(key->key, "retire");
|
2024-06-26 14:39:04 +10:00
|
|
|
retire = UINT32_MAX;
|
|
|
|
}
|
2019-10-17 11:19:35 +02:00
|
|
|
dst_key_settime(key->key, DST_TIME_INACTIVE, retire);
|
|
|
|
}
|
|
|
|
|
2020-04-28 15:05:43 +02:00
|
|
|
/*
|
|
|
|
* Update remove time.
|
|
|
|
*/
|
|
|
|
keymgr_settime_remove(key, kasp);
|
|
|
|
|
2019-10-17 11:19:35 +02:00
|
|
|
/*
|
|
|
|
* Publish successor 'prepub' time before the 'retire' time of 'key'.
|
|
|
|
*/
|
2020-05-14 15:36:13 +02:00
|
|
|
if (prepub > retire) {
|
|
|
|
/* We should have already prepublished the new key. */
|
|
|
|
return now;
|
|
|
|
}
|
2019-10-17 11:19:35 +02:00
|
|
|
return retire - prepub;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2025-03-19 17:10:25 +01:00
|
|
|
keymgr_key_retire(dns_dnsseckey_t *key, dns_kasp_t *kasp, uint8_t opts,
|
|
|
|
isc_stdtime_t now) {
|
2019-10-17 11:19:35 +02:00
|
|
|
char keystr[DST_KEY_FORMATSIZE];
|
2020-04-28 15:05:43 +02:00
|
|
|
isc_result_t ret;
|
|
|
|
isc_stdtime_t retire;
|
2019-10-17 11:19:35 +02:00
|
|
|
dst_key_state_t s;
|
2020-07-06 12:07:24 +02:00
|
|
|
bool ksk = false, zsk = false;
|
2019-10-17 11:19:35 +02:00
|
|
|
|
|
|
|
REQUIRE(key != NULL);
|
|
|
|
REQUIRE(key->key != NULL);
|
|
|
|
|
2025-03-19 17:10:25 +01:00
|
|
|
dst_key_format(key->key, keystr, sizeof(keystr));
|
|
|
|
|
|
|
|
ret = dst_key_getstate(key->key, DST_KEY_GOAL, &s);
|
|
|
|
INSIST(ret == ISC_R_SUCCESS);
|
|
|
|
|
|
|
|
if (dns_kasp_manualmode(kasp) &&
|
|
|
|
(opts & DNS_KEYMGRATTR_FORCESTEP) == 0 && s != HIDDEN)
|
|
|
|
{
|
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
|
|
|
|
ISC_LOG_INFO,
|
|
|
|
"keymgr-manual-mode: block retire DNSKEY "
|
|
|
|
"%s (%s)",
|
|
|
|
keystr, keymgr_keyrole(key->key));
|
|
|
|
return;
|
|
|
|
} else {
|
|
|
|
/* This key wants to retire and hide in a corner. */
|
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
|
|
|
|
ISC_LOG_INFO, "keymgr: retire DNSKEY %s (%s)",
|
|
|
|
keystr, keymgr_keyrole(key->key));
|
|
|
|
|
|
|
|
dst_key_setstate(key->key, DST_KEY_GOAL, HIDDEN);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This key may not have key states set yet. Pretend as if they are
|
|
|
|
* in the OMNIPRESENT state.
|
|
|
|
*/
|
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);
|
|
|
|
}
|
|
|
|
keymgr_settime_remove(key, kasp);
|
2019-10-17 11:19:35 +02:00
|
|
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2020-07-06 12:07:24 +02:00
|
|
|
ret = dst_key_getbool(key->key, DST_BOOL_KSK, &ksk);
|
|
|
|
if (ret == ISC_R_SUCCESS && ksk) {
|
2019-10-17 11:19:35 +02:00
|
|
|
if (dst_key_getstate(key->key, DST_KEY_KRRSIG, &s) !=
|
2022-11-02 19:33:14 +01:00
|
|
|
ISC_R_SUCCESS)
|
|
|
|
{
|
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);
|
|
|
|
}
|
|
|
|
}
|
2020-07-06 12:07:24 +02:00
|
|
|
ret = dst_key_getbool(key->key, DST_BOOL_ZSK, &zsk);
|
|
|
|
if (ret == ISC_R_SUCCESS && zsk) {
|
2019-10-17 11:19:35 +02:00
|
|
|
if (dst_key_getstate(key->key, DST_KEY_ZRRSIG, &s) !=
|
2022-11-02 19:33:14 +01:00
|
|
|
ISC_R_SUCCESS)
|
|
|
|
{
|
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);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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);
|
2025-03-18 12:23:34 +01:00
|
|
|
l = lifetime - 1;
|
2024-06-24 15:14:16 +02:00
|
|
|
}
|
|
|
|
/* 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;
|
2024-06-26 14:39:04 +10:00
|
|
|
uint32_t inactive;
|
2024-06-24 15:14:16 +02:00
|
|
|
(void)dst_key_gettime(key->key, DST_TIME_ACTIVATE, &a);
|
2024-06-26 14:39:04 +10:00
|
|
|
if (ISC_OVERFLOW_ADD(a, lifetime, &inactive)) {
|
2024-06-26 14:49:51 +10:00
|
|
|
log_key_overflow(key->key, "inactive");
|
2024-06-26 14:39:04 +10:00
|
|
|
inactive = UINT32_MAX;
|
|
|
|
}
|
|
|
|
dst_key_settime(key->key, DST_TIME_INACTIVE, inactive);
|
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);
|
2025-03-04 17:14:33 +01:00
|
|
|
dst_key_unsettime(key->key, DST_TIME_SYNCDELETE);
|
2024-06-24 15:14:16 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-04-12 16:22:00 +02:00
|
|
|
static bool
|
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) {
|
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);
|
|
|
|
|
2024-08-06 14:41:50 +10:00
|
|
|
if (id < min || id > max) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (rid < min || rid > max) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*keys, dkey, link) {
|
2021-04-12 16:22:00 +02:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
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,
|
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) {
|
2019-10-17 11:19:35 +02:00
|
|
|
isc_result_t result = ISC_R_SUCCESS;
|
2022-02-28 11:50:43 +01:00
|
|
|
bool conflict = false;
|
|
|
|
int flags = DNS_KEYOWNER_ZONE;
|
2019-10-17 11:19:35 +02:00
|
|
|
dst_key_t *newkey = NULL;
|
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);
|
2023-11-17 17:09:00 +01:00
|
|
|
const char *dir = NULL;
|
2022-02-28 11:50:43 +01:00
|
|
|
int size = dns_kasp_key_size(kkey);
|
2019-10-17 11:19:35 +02:00
|
|
|
|
2022-02-28 11:50:43 +01:00
|
|
|
if (dns_kasp_key_ksk(kkey)) {
|
|
|
|
flags |= DNS_KEYFLAG_KSK;
|
|
|
|
}
|
2019-10-17 11:19:35 +02:00
|
|
|
|
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 {
|
2023-11-17 10:45:05 +01:00
|
|
|
RETERR(dns_keystore_keygen(
|
|
|
|
keystore, origin, dns_kasp_getname(kasp),
|
|
|
|
rdclass, mctx, alg, size, flags, &newkey));
|
2019-10-17 11:19:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Key collision? */
|
2024-08-06 14:41:50 +10:00
|
|
|
conflict = keymgr_keyid_conflict(newkey, kkey->tag_min,
|
|
|
|
kkey->tag_max, keylist);
|
2021-04-12 16:22:00 +02:00
|
|
|
if (!conflict) {
|
2024-08-06 14:41:50 +10:00
|
|
|
conflict = keymgr_keyid_conflict(
|
|
|
|
newkey, kkey->tag_min, kkey->tag_max, newkeys);
|
2021-04-12 16:22:00 +02:00
|
|
|
}
|
|
|
|
if (conflict) {
|
|
|
|
/* Try again. */
|
2024-08-13 18:20:26 +02:00
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
|
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);
|
2019-10-17 11:19:35 +02:00
|
|
|
}
|
2020-03-30 13:47:58 -07:00
|
|
|
} while (conflict);
|
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));
|
2022-03-09 11:33:03 +01:00
|
|
|
|
2023-11-17 17:09:00 +01:00
|
|
|
dir = dns_keystore_directory(keystore, keydir);
|
|
|
|
if (dir != NULL) {
|
|
|
|
dst_key_setdirectory(newkey, dir);
|
2022-03-09 11:33:03 +01:00
|
|
|
}
|
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
|
2025-05-22 11:23:48 +02:00
|
|
|
keymgr_key_match_state(const dst_key_t *key, const dst_key_t *subject, int type,
|
2021-02-01 09:40:44 +01:00
|
|
|
dst_key_state_t next_state,
|
|
|
|
dst_key_state_t states[NUM_KEYSTATES]) {
|
2019-10-17 11:19:35 +02:00
|
|
|
REQUIRE(key != NULL);
|
|
|
|
|
2021-02-01 09:40:44 +01:00
|
|
|
for (int i = 0; i < NUM_KEYSTATES; i++) {
|
2019-10-17 11:19:35 +02:00
|
|
|
dst_key_state_t state;
|
|
|
|
if (states[i] == NA) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (next_state != NA && i == type &&
|
2024-08-21 17:14:48 +02:00
|
|
|
dst_key_alg(key) == dst_key_alg(subject) &&
|
2022-11-02 19:33:14 +01:00
|
|
|
dst_key_id(key) == dst_key_id(subject))
|
|
|
|
{
|
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) {
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*keyring, d, link) {
|
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
|
|
|
/*
|
|
|
|
* Check if k is a direct successor of d, e.g. d depends on k.
|
|
|
|
*/
|
|
|
|
if (keymgr_direct_dep(d->key, k)) {
|
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".
|
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)) {
|
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)) {
|
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.
|
|
|
|
*/
|
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;
|
|
|
|
}
|
|
|
|
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*keyring, y, link) {
|
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 (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;
|
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,
|
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) {
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*keyring, dkey, link) {
|
2019-10-17 11:19:35 +02:00
|
|
|
if (match_algorithms &&
|
2022-11-02 19:33:14 +01:00
|
|
|
(dst_key_alg(dkey->key) != dst_key_alg(key->key)))
|
|
|
|
{
|
2019-10-17 11:19:35 +02:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2021-01-07 12:04:14 +01:00
|
|
|
if (!keymgr_key_match_state(dkey->key, key->key, type,
|
2022-11-02 19:33:14 +01:00
|
|
|
next_state, states))
|
|
|
|
{
|
2021-01-07 12:04:14 +01:00
|
|
|
continue;
|
|
|
|
}
|
2019-10-17 11:19:35 +02:00
|
|
|
|
2021-01-07 12:04:14 +01:00
|
|
|
/* Found a match. */
|
|
|
|
if (!check_successor) {
|
|
|
|
return true;
|
2019-10-17 11:19:35 +02:00
|
|
|
}
|
|
|
|
|
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.
|
|
|
|
*/
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*keyring, skey, link) {
|
2021-01-07 12:04:14 +01:00
|
|
|
if (skey == dkey) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!keymgr_key_match_state(skey->key, key->key, type,
|
2022-11-02 19:33:14 +01:00
|
|
|
next_state, states2))
|
|
|
|
{
|
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;
|
|
|
|
}
|
2019-10-17 11:19:35 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
/* No match. */
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if a key has a successor.
|
|
|
|
*/
|
|
|
|
static bool
|
2020-05-14 15:06:54 +02:00
|
|
|
keymgr_key_has_successor(dns_dnsseckey_t *predecessor,
|
|
|
|
dns_dnsseckeylist_t *keyring) {
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*keyring, successor, link) {
|
2021-01-07 12:04:14 +01:00
|
|
|
if (keymgr_direct_dep(predecessor->key, successor->key)) {
|
2020-05-14 15:06:54 +02:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return false;
|
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) {
|
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 };
|
2019-10-17 11:19:35 +02:00
|
|
|
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*keyring, dkey, link) {
|
2019-10-17 11:19:35 +02:00
|
|
|
if (match_algorithms &&
|
2022-11-02 19:33:14 +01:00
|
|
|
(dst_key_alg(dkey->key) != dst_key_alg(key->key)))
|
|
|
|
{
|
2019-10-17 11:19:35 +02:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (keymgr_key_match_state(dkey->key, key->key, type,
|
2022-11-02 19:33:14 +01:00
|
|
|
next_state, ds_hidden))
|
|
|
|
{
|
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))
|
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) {
|
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 };
|
2019-10-17 11:19:35 +02:00
|
|
|
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*keyring, dkey, link) {
|
2019-10-17 11:19:35 +02:00
|
|
|
if (match_algorithms &&
|
2022-11-02 19:33:14 +01:00
|
|
|
(dst_key_alg(dkey->key) != dst_key_alg(key->key)))
|
|
|
|
{
|
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]);
|
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))
|
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,
|
2025-03-19 17:10:25 +01:00
|
|
|
dst_key_state_t next_state, uint8_t opts) {
|
2021-02-01 09:40:44 +01:00
|
|
|
/* (3a) */
|
|
|
|
dst_key_state_t states[2][NUM_KEYSTATES] = {
|
2019-10-17 11:19:35 +02:00
|
|
|
/* DNSKEY, ZRRSIG, KRRSIG, DS */
|
|
|
|
{ NA, NA, NA, OMNIPRESENT }, /* DS present */
|
|
|
|
{ NA, NA, NA, RUMOURED } /* DS introducing */
|
|
|
|
};
|
2021-02-01 09:40:44 +01:00
|
|
|
/* successor n/a */
|
|
|
|
dst_key_state_t na[NUM_KEYSTATES] = { NA, NA, NA, NA };
|
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,
|
2020-12-03 16:04:28 +01:00
|
|
|
states[1], na, false, false) ||
|
2025-03-19 17:10:25 +01:00
|
|
|
((opts & DNS_KEYMGRATTR_S2I) != 0 &&
|
2020-12-03 16:04:28 +01:00
|
|
|
keymgr_key_exists_with_state(keyring, key, type, next_state, na,
|
|
|
|
na, false, false));
|
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) {
|
2021-02-01 09:40:44 +01:00
|
|
|
dst_key_state_t states[9][NUM_KEYSTATES] = {
|
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 */
|
|
|
|
};
|
2021-02-01 09:40:44 +01:00
|
|
|
/* successor n/a */
|
|
|
|
dst_key_state_t na[NUM_KEYSTATES] = { NA, NA, NA, NA };
|
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) {
|
2021-02-01 09:40:44 +01:00
|
|
|
dst_key_state_t states[11][NUM_KEYSTATES] = {
|
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 */
|
|
|
|
};
|
2021-02-01 09:40:44 +01:00
|
|
|
/* successor n/a */
|
|
|
|
dst_key_state_t na[NUM_KEYSTATES] = { NA, NA, NA, NA };
|
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,
|
2020-08-27 14:24:50 +02:00
|
|
|
int type, dst_key_state_t next) {
|
2019-10-17 11:19:35 +02:00
|
|
|
dst_key_state_t dnskeystate = HIDDEN;
|
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 };
|
2019-10-17 11:19:35 +02:00
|
|
|
|
2020-08-27 14:24:50 +02:00
|
|
|
if (next != RUMOURED) {
|
2019-10-17 11:19:35 +02:00
|
|
|
/*
|
|
|
|
* Local policy only adds an extra barrier on transitions to
|
2021-01-07 12:26:53 +01:00
|
|
|
* the RUMOURED state.
|
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:
|
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;
|
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,
|
2025-03-19 17:10:25 +01:00
|
|
|
int type, dst_key_state_t next_state, uint8_t opts) {
|
2019-10-17 11:19:35 +02:00
|
|
|
/* Debug logging. */
|
2024-08-13 18:20:26 +02:00
|
|
|
if (isc_log_wouldlog(ISC_LOG_DEBUG(1))) {
|
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));
|
2025-03-19 17:10:25 +01:00
|
|
|
rule1a = keymgr_have_ds(keyring, key, type, NA, opts);
|
|
|
|
rule1b = keymgr_have_ds(keyring, key, type, next_state, opts);
|
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(
|
2024-08-13 18:20:26 +02:00
|
|
|
DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
|
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.
|
|
|
|
*/
|
2025-03-19 17:10:25 +01:00
|
|
|
(!keymgr_have_ds(keyring, key, type, NA, opts) ||
|
|
|
|
keymgr_have_ds(keyring, key, type, next_state, opts)) &&
|
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;
|
2020-08-27 14:24:50 +02:00
|
|
|
isc_stdtime_t lastchange, dstime, nexttime = now;
|
2023-07-26 11:50:57 +02:00
|
|
|
dns_ttl_t ttlsig = dns_kasp_zonemaxttl(kasp, true);
|
2025-03-03 12:07:03 +01:00
|
|
|
uint32_t dsstate;
|
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:
|
|
|
|
*
|
2020-02-18 16:57:37 +01:00
|
|
|
* Dsgn + zone-propagation-delay + max-zone-ttl.
|
2019-10-17 11:19:35 +02:00
|
|
|
*/
|
2023-07-26 11:50:57 +02:00
|
|
|
nexttime = lastchange + ttlsig +
|
2025-03-03 12:07:03 +01:00
|
|
|
dns_kasp_zonepropagationdelay(kasp);
|
2020-02-18 16:57:37 +01:00
|
|
|
/*
|
2025-03-03 12:07:03 +01:00
|
|
|
* Only add the sign delay Dsgn and retire-safety if
|
|
|
|
* there is an actual predecessor or successor key.
|
2020-02-18 16:57:37 +01:00
|
|
|
*/
|
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) {
|
2025-03-03 12:07:03 +01:00
|
|
|
nexttime += dns_kasp_signdelay(kasp) +
|
|
|
|
dns_kasp_retiresafety(kasp);
|
2020-02-18 16:57:37 +01:00
|
|
|
}
|
2019-10-17 11:19:35 +02:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
nexttime = now;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case DST_KEY_DS:
|
|
|
|
switch (next_state) {
|
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.
|
|
|
|
*/
|
2019-10-17 11:19:35 +02:00
|
|
|
case OMNIPRESENT:
|
|
|
|
case HIDDEN:
|
2025-03-03 12:07:03 +01:00
|
|
|
/* Make sure DS has been seen in/withdrawn from the
|
|
|
|
* parent. */
|
|
|
|
dsstate = next_state == HIDDEN ? DST_TIME_DSDELETE
|
|
|
|
: DST_TIME_DSPUBLISH;
|
|
|
|
ret = dst_key_gettime(key->key, dsstate, &dstime);
|
2020-08-27 14:24:50 +02:00
|
|
|
if (ret != ISC_R_SUCCESS || dstime > now) {
|
|
|
|
/* Not yet, try again in an hour. */
|
|
|
|
nexttime = now + 3600;
|
|
|
|
} else {
|
|
|
|
nexttime =
|
|
|
|
dstime + dns_kasp_dsttl(kasp) +
|
2025-03-03 12:07:03 +01:00
|
|
|
dns_kasp_parentpropagationdelay(kasp);
|
|
|
|
/*
|
|
|
|
* Only add the retire-safety if there is an
|
|
|
|
* actual predecessor or successor key.
|
|
|
|
*/
|
|
|
|
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) {
|
|
|
|
nexttime += dns_kasp_retiresafety(kasp);
|
|
|
|
}
|
2020-08-27 14:24:50 +02:00
|
|
|
}
|
2019-10-17 11:19:35 +02:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
nexttime = now;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
2021-10-11 12:50:17 +02:00
|
|
|
UNREACHABLE();
|
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,
|
2025-03-19 17:10:25 +01:00
|
|
|
isc_stdtime_t *nexttime, uint8_t opts) {
|
2025-07-24 11:14:16 +02:00
|
|
|
isc_result_t result = DNS_R_UNCHANGED;
|
2019-10-17 11:19:35 +02:00
|
|
|
bool changed;
|
2025-03-19 17:10:25 +01:00
|
|
|
bool force = ((opts & DNS_KEYMGRATTR_FORCESTEP) != 0);
|
2019-10-17 11:19:35 +02:00
|
|
|
|
|
|
|
/* Repeat until nothing changed. */
|
|
|
|
transition:
|
|
|
|
changed = false;
|
|
|
|
|
|
|
|
/* For all keys in the zone. */
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*keyring, dkey, link) {
|
2019-10-17 11:19:35 +02:00
|
|
|
char keystr[DST_KEY_FORMATSIZE];
|
|
|
|
dst_key_format(dkey->key, keystr, sizeof(keystr));
|
|
|
|
|
2024-08-19 09:49:21 +02:00
|
|
|
if (dkey->purge) {
|
|
|
|
/* Skip purged keys. */
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2024-08-13 18:20:26 +02:00
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
|
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.
|
|
|
|
*/
|
2024-08-13 18:20:26 +02:00
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
|
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;
|
|
|
|
}
|
|
|
|
|
2024-08-13 18:20:26 +02:00
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
|
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,
|
2022-11-02 19:33:14 +01:00
|
|
|
next_state))
|
|
|
|
{
|
2019-10-17 11:19:35 +02:00
|
|
|
/* No, please respect rollover methods. */
|
|
|
|
isc_log_write(
|
2024-08-13 18:20:26 +02:00
|
|
|
DNS_LOGCATEGORY_DNSSEC,
|
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,
|
2025-03-19 17:10:25 +01:00
|
|
|
next_state, opts))
|
2020-12-03 16:04:28 +01:00
|
|
|
{
|
2019-10-17 11:19:35 +02:00
|
|
|
/* No, this would make the zone bogus. */
|
|
|
|
isc_log_write(
|
2024-08-13 18:20:26 +02:00
|
|
|
DNS_LOGCATEGORY_DNSSEC,
|
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(
|
2024-08-13 18:20:26 +02:00
|
|
|
DNS_LOGCATEGORY_DNSSEC,
|
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;
|
|
|
|
}
|
|
|
|
|
2025-03-19 17:10:25 +01:00
|
|
|
/*
|
|
|
|
* Are we allowed to make the transition automatically?
|
|
|
|
*/
|
|
|
|
if (next_state != OMNIPRESENT && next_state != HIDDEN) {
|
|
|
|
if (dns_kasp_manualmode(kasp) && !force) {
|
|
|
|
isc_log_write(
|
|
|
|
DNS_LOGCATEGORY_DNSSEC,
|
|
|
|
DNS_LOGMODULE_DNSSEC,
|
|
|
|
ISC_LOG_INFO,
|
|
|
|
"keymgr-manual-mode: block "
|
|
|
|
"transition "
|
|
|
|
"%s %s type %s "
|
|
|
|
"state %s to state %s",
|
|
|
|
keymgr_keyrole(dkey->key),
|
|
|
|
keystr, keystatetags[i],
|
|
|
|
keystatestrings[state],
|
|
|
|
keystatestrings[next_state]);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* It is safe to make the transition. */
|
2024-08-13 18:20:26 +02:00
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
|
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]);
|
|
|
|
|
|
|
|
dst_key_setstate(dkey->key, i, next_state);
|
|
|
|
dst_key_settime(dkey->key, keystatetimes[i], now);
|
2022-05-03 12:28:31 +02:00
|
|
|
INSIST(dst_key_ismodified(dkey->key));
|
2019-10-17 11:19:35 +02:00
|
|
|
changed = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We changed something, continue processing. */
|
|
|
|
if (changed) {
|
2025-07-24 11:14:16 +02:00
|
|
|
result = ISC_R_SUCCESS;
|
2025-03-19 17:10:25 +01:00
|
|
|
/* No longer force for the next run */
|
|
|
|
force = false;
|
2019-10-17 11:19:35 +02:00
|
|
|
goto transition;
|
|
|
|
}
|
|
|
|
|
2025-07-24 11:14:16 +02:00
|
|
|
return result;
|
2019-10-17 11:19:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
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.
|
2019-10-17 11:19:35 +02:00
|
|
|
*
|
|
|
|
*/
|
|
|
|
static void
|
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) {
|
2019-10-17 11:19:35 +02:00
|
|
|
bool ksk, zsk;
|
|
|
|
isc_result_t ret;
|
2021-01-26 11:32:24 +01:00
|
|
|
isc_stdtime_t active = 0, pub = 0, syncpub = 0, retire = 0, remove = 0;
|
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;
|
2021-01-26 11:32:24 +01:00
|
|
|
dst_key_state_t goal_state = HIDDEN;
|
2019-10-17 11:19:35 +02:00
|
|
|
|
|
|
|
REQUIRE(key != NULL);
|
|
|
|
REQUIRE(key->key != NULL);
|
|
|
|
|
2020-03-27 10:28:22 +01:00
|
|
|
/* Initialize role. */
|
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);
|
2021-08-16 11:12:36 +02:00
|
|
|
dst_key_setbool(key->key, DST_BOOL_KSK, ksk || csk);
|
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);
|
2021-08-16 11:12:36 +02:00
|
|
|
dst_key_setbool(key->key, DST_BOOL_ZSK, zsk || csk);
|
2019-10-17 11:19:35 +02:00
|
|
|
}
|
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) {
|
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) {
|
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 {
|
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
|
|
|
}
|
2021-01-26 11:32:24 +01:00
|
|
|
goal_state = OMNIPRESENT;
|
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) {
|
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 {
|
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
|
|
|
}
|
2021-01-26 11:32:24 +01:00
|
|
|
goal_state = OMNIPRESENT;
|
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;
|
|
|
|
}
|
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) {
|
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) {
|
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) !=
|
2022-11-02 19:33:14 +01:00
|
|
|
ISC_R_SUCCESS)
|
|
|
|
{
|
2021-01-26 11:32:24 +01:00
|
|
|
dst_key_setstate(key->key, DST_KEY_GOAL, goal_state);
|
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,
|
2020-04-06 09:59:18 +02:00
|
|
|
dnskey_state, now);
|
2021-08-16 11:12:36 +02:00
|
|
|
if (ksk || csk) {
|
2020-03-27 10:28:22 +01:00
|
|
|
INITIALIZE_STATE(key->key, DST_KEY_KRRSIG, DST_TIME_KRRSIG,
|
2020-04-06 09:59:18 +02:00
|
|
|
dnskey_state, now);
|
|
|
|
INITIALIZE_STATE(key->key, DST_KEY_DS, DST_TIME_DS, ds_state,
|
|
|
|
now);
|
2020-03-27 10:28:22 +01:00
|
|
|
}
|
2021-08-16 11:12:36 +02:00
|
|
|
if (zsk || csk) {
|
2020-03-27 10:28:22 +01:00
|
|
|
INITIALIZE_STATE(key->key, DST_KEY_ZRRSIG, DST_TIME_ZRRSIG,
|
2020-04-06 09:59:18 +02:00
|
|
|
zrrsig_state, now);
|
2020-03-27 10:28:22 +01:00
|
|
|
}
|
2019-10-17 11:19:35 +02:00
|
|
|
}
|
|
|
|
|
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,
|
2022-03-09 11:33:03 +01:00
|
|
|
dns_kasp_t *kasp, const char *keydir, uint32_t lifetime,
|
2025-03-19 17:10:25 +01:00
|
|
|
uint8_t opts, isc_stdtime_t now, isc_stdtime_t *nexttime,
|
2021-04-12 14:40:46 +02:00
|
|
|
isc_mem_t *mctx) {
|
2020-05-14 15:34:13 +02:00
|
|
|
char keystr[DST_KEY_FORMATSIZE];
|
2025-03-19 17:10:25 +01:00
|
|
|
char namestr[DNS_NAME_FORMATSIZE];
|
2020-05-14 15:34:13 +02:00
|
|
|
isc_stdtime_t retire = 0, active = 0, prepub = 0;
|
|
|
|
dns_dnsseckey_t *new_key = NULL;
|
|
|
|
dst_key_t *dst_key = NULL;
|
2025-03-20 22:25:56 -07:00
|
|
|
bool keycreated = false;
|
2020-05-14 15:34:13 +02:00
|
|
|
|
|
|
|
/* Do we need to create a successor for the active key? */
|
|
|
|
if (active_key != NULL) {
|
2024-08-13 18:20:26 +02:00
|
|
|
if (isc_log_wouldlog(ISC_LOG_DEBUG(1))) {
|
2020-05-14 15:34:13 +02:00
|
|
|
dst_key_format(active_key->key, keystr, sizeof(keystr));
|
|
|
|
isc_log_write(
|
2024-08-13 18:20:26 +02:00
|
|
|
DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
|
|
|
|
ISC_LOG_DEBUG(1),
|
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);
|
2022-05-10 10:25:27 +02:00
|
|
|
if (prepub > now) {
|
2024-08-13 18:20:26 +02:00
|
|
|
if (isc_log_wouldlog(ISC_LOG_DEBUG(1))) {
|
2020-05-14 15:39:57 +02:00
|
|
|
dst_key_format(active_key->key, keystr,
|
|
|
|
sizeof(keystr));
|
|
|
|
isc_log_write(
|
2024-08-13 18:20:26 +02:00
|
|
|
DNS_LOGCATEGORY_DNSSEC,
|
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);
|
|
|
|
}
|
2022-05-10 10:25:27 +02:00
|
|
|
}
|
|
|
|
if (prepub == 0 || prepub > now) {
|
2020-05-14 15:34:13 +02:00
|
|
|
/* No need to start rollover now. */
|
|
|
|
if (*nexttime == 0 || prepub < *nexttime) {
|
2025-03-04 17:18:36 +01:00
|
|
|
if (prepub > 0) {
|
|
|
|
*nexttime = prepub;
|
|
|
|
}
|
2020-05-14 15:34:13 +02:00
|
|
|
}
|
|
|
|
return ISC_R_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (keymgr_key_has_successor(active_key, keyring)) {
|
|
|
|
/* Key already has successor. */
|
2024-08-13 18:20:26 +02:00
|
|
|
if (isc_log_wouldlog(ISC_LOG_DEBUG(1))) {
|
2020-05-14 15:39:57 +02:00
|
|
|
dst_key_format(active_key->key, keystr,
|
|
|
|
sizeof(keystr));
|
|
|
|
isc_log_write(
|
2024-08-13 18:20:26 +02:00
|
|
|
DNS_LOGCATEGORY_DNSSEC,
|
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));
|
|
|
|
}
|
2020-05-14 15:34:13 +02:00
|
|
|
return ISC_R_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2024-08-13 18:20:26 +02:00
|
|
|
if (isc_log_wouldlog(ISC_LOG_DEBUG(1))) {
|
2020-05-14 15:34:13 +02:00
|
|
|
dst_key_format(active_key->key, keystr, sizeof(keystr));
|
2024-08-13 18:20:26 +02:00
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
|
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));
|
|
|
|
}
|
2021-05-17 14:06:46 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If rollover is not allowed, warn.
|
|
|
|
*/
|
2025-03-19 17:10:25 +01:00
|
|
|
if ((opts & DNS_KEYMGRATTR_NOROLL) != 0) {
|
2021-05-17 14:06:46 +02:00
|
|
|
dst_key_format(active_key->key, keystr, sizeof(keystr));
|
2024-08-13 18:20:26 +02:00
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
|
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;
|
|
|
|
}
|
2024-08-13 18:20:26 +02:00
|
|
|
} else if (isc_log_wouldlog(ISC_LOG_DEBUG(1))) {
|
2020-05-14 15:34:13 +02:00
|
|
|
dns_name_format(origin, namestr, sizeof(namestr));
|
2024-08-13 18:20:26 +02:00
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
|
|
|
|
ISC_LOG_DEBUG(1),
|
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.
|
|
|
|
*/
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*keyring, candidate, link) {
|
2023-08-09 14:10:32 +02:00
|
|
|
if (dns_kasp_key_match(kaspkey, candidate) &&
|
2020-05-14 15:34:13 +02:00
|
|
|
dst_key_is_unused(candidate->key))
|
|
|
|
{
|
|
|
|
/* Found a candidate in keyring. */
|
2025-03-20 22:25:56 -07:00
|
|
|
new_key = candidate;
|
2020-05-14 15:34:13 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2025-03-19 17:10:25 +01:00
|
|
|
if (dns_kasp_manualmode(kasp) && (opts & DNS_KEYMGRATTR_FORCESTEP) == 0)
|
|
|
|
{
|
|
|
|
if (active_key != NULL && new_key != NULL) {
|
|
|
|
char keystr2[DST_KEY_FORMATSIZE];
|
|
|
|
dst_key_format(active_key->key, keystr, sizeof(keystr));
|
|
|
|
dst_key_format(new_key->key, keystr2, sizeof(keystr2));
|
|
|
|
dns_name_format(origin, namestr, sizeof(namestr));
|
|
|
|
isc_log_write(
|
|
|
|
DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
|
|
|
|
ISC_LOG_INFO,
|
|
|
|
"keymgr-manual-mode: block %s rollover for key "
|
|
|
|
"%s to key %s (policy %s)",
|
|
|
|
keymgr_keyrole(active_key->key), keystr,
|
|
|
|
keystr2, dns_kasp_getname(kasp));
|
|
|
|
} else if (active_key != NULL) {
|
|
|
|
dst_key_format(active_key->key, keystr, sizeof(keystr));
|
|
|
|
dns_name_format(origin, namestr, sizeof(namestr));
|
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
|
|
|
|
DNS_LOGMODULE_DNSSEC, ISC_LOG_INFO,
|
|
|
|
"keymgr-manual-mode: block %s rollover "
|
|
|
|
"for key %s (policy %s)",
|
|
|
|
keymgr_keyrole(active_key->key), keystr,
|
|
|
|
dns_kasp_getname(kasp));
|
|
|
|
} else if (new_key != NULL) {
|
|
|
|
dst_key_format(new_key->key, keystr, sizeof(keystr));
|
|
|
|
dns_name_format(origin, namestr, sizeof(namestr));
|
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
|
|
|
|
DNS_LOGMODULE_DNSSEC, ISC_LOG_INFO,
|
|
|
|
"keymgr-manual-mode: block %s "
|
|
|
|
"introduction %s (policy %s)",
|
|
|
|
keymgr_keyrole(new_key->key), keystr,
|
|
|
|
dns_kasp_getname(kasp));
|
|
|
|
} else {
|
|
|
|
dns_name_format(origin, namestr, sizeof(namestr));
|
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
|
|
|
|
DNS_LOGMODULE_DNSSEC, ISC_LOG_INFO,
|
|
|
|
"keymgr-manual-mode: block new key "
|
|
|
|
"generation for zone %s (policy %s)",
|
|
|
|
namestr, dns_kasp_getname(kasp));
|
|
|
|
}
|
|
|
|
return ISC_R_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2025-03-20 22:25:56 -07:00
|
|
|
if (new_key == NULL) {
|
2020-05-14 15:34:13 +02:00
|
|
|
/* No key available in keyring, create a new one. */
|
2021-08-16 11:12:36 +02:00
|
|
|
bool csk = (dns_kasp_key_ksk(kaspkey) &&
|
|
|
|
dns_kasp_key_zsk(kaspkey));
|
|
|
|
|
2023-11-17 10:45:05 +01:00
|
|
|
isc_result_t result =
|
|
|
|
keymgr_createkey(kaspkey, origin, kasp, rdclass, mctx,
|
|
|
|
keydir, keyring, newkeys, &dst_key);
|
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);
|
2022-01-10 11:34:30 -08:00
|
|
|
dns_dnsseckey_create(mctx, &dst_key, &new_key);
|
2021-08-16 11:12:36 +02:00
|
|
|
keymgr_key_init(new_key, kasp, now, csk);
|
2025-03-20 22:25:56 -07:00
|
|
|
keycreated = true;
|
2020-05-14 15:34:13 +02:00
|
|
|
}
|
|
|
|
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);
|
2024-09-03 17:24:22 +02:00
|
|
|
dns_keymgr_settime_syncpublish(new_key->key, kasp, true);
|
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);
|
2024-09-03 17:24:22 +02:00
|
|
|
dns_keymgr_settime_syncpublish(new_key->key, kasp, false);
|
2020-05-14 15:39:57 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Retire predecessor.
|
|
|
|
*/
|
|
|
|
dst_key_setstate(active_key->key, DST_KEY_GOAL, HIDDEN);
|
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) {
|
2024-06-26 14:39:04 +10:00
|
|
|
uint32_t inactive;
|
|
|
|
|
|
|
|
if (ISC_OVERFLOW_ADD(active, lifetime, &inactive)) {
|
2024-06-26 14:49:51 +10:00
|
|
|
log_key_overflow(new_key->key, "inactive");
|
2024-06-26 14:39:04 +10:00
|
|
|
inactive = UINT32_MAX;
|
|
|
|
}
|
|
|
|
dst_key_settime(new_key->key, DST_TIME_INACTIVE, inactive);
|
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);
|
2025-03-20 22:25:56 -07:00
|
|
|
if (keycreated) {
|
2020-05-14 15:34:13 +02:00
|
|
|
ISC_LIST_APPEND(*newkeys, new_key, link);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Logging. */
|
|
|
|
dst_key_format(new_key->key, keystr, sizeof(keystr));
|
2024-08-13 18:20:26 +02:00
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
|
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),
|
2025-03-20 22:25:56 -07:00
|
|
|
keycreated ? "created" : "selected",
|
2020-05-14 15:34:13 +02:00
|
|
|
dns_kasp_getname(kasp));
|
|
|
|
return ISC_R_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2025-05-22 11:23:48 +02:00
|
|
|
bool
|
|
|
|
dns_keymgr_key_may_be_purged(const dst_key_t *key, uint32_t after,
|
|
|
|
isc_stdtime_t now) {
|
2021-02-08 15:15:57 +01:00
|
|
|
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
|
2022-03-09 11:33:03 +01:00
|
|
|
keymgr_purge_keyfile(dst_key_t *key, int type) {
|
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));
|
2022-03-09 11:33:03 +01:00
|
|
|
ret = dst_key_buildfilename(key, type, dst_key_directory(key), &fileb);
|
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));
|
2024-08-13 18:20:26 +02:00
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
|
|
|
|
ISC_LOG_WARNING,
|
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));
|
2024-08-13 18:20:26 +02:00
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
|
|
|
|
ISC_LOG_WARNING,
|
2021-02-08 15:15:57 +01:00
|
|
|
"keymgr: failed to purge DNSKEY %s (%s): unlink "
|
|
|
|
"'%s' failed",
|
|
|
|
keystr, keymgr_keyrole(key), filename);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2025-02-25 08:40:33 +01:00
|
|
|
static bool
|
|
|
|
dst_key_doublematch(dns_dnsseckey_t *key, dns_kasp_t *kasp) {
|
|
|
|
int matches = 0;
|
|
|
|
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(dns_kasp_keys(kasp), kkey, link) {
|
2025-02-25 08:40:33 +01:00
|
|
|
if (dns_kasp_key_match(kkey, key)) {
|
|
|
|
matches++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return matches > 1;
|
|
|
|
}
|
|
|
|
|
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,
|
2022-03-09 11:33:03 +01:00
|
|
|
isc_mem_t *mctx, dns_dnsseckeylist_t *keyring,
|
|
|
|
dns_dnsseckeylist_t *dnskeys, const char *keydir,
|
2025-03-19 17:10:25 +01:00
|
|
|
dns_kasp_t *kasp, uint8_t opts, isc_stdtime_t now,
|
|
|
|
isc_stdtime_t *nexttime) {
|
2025-07-24 11:14:16 +02:00
|
|
|
isc_result_t result = DNS_R_UNCHANGED;
|
2019-10-17 11:19:35 +02:00
|
|
|
dns_dnsseckeylist_t newkeys;
|
2021-08-16 11:12:36 +02:00
|
|
|
int numkeys = 0;
|
2019-10-17 11:19:35 +02:00
|
|
|
int options = (DST_TYPE_PRIVATE | DST_TYPE_PUBLIC | DST_TYPE_STATE);
|
|
|
|
char keystr[DST_KEY_FORMATSIZE];
|
|
|
|
|
2022-02-28 11:50:43 +01:00
|
|
|
REQUIRE(dns_name_isvalid(origin));
|
|
|
|
REQUIRE(mctx != NULL);
|
2019-10-17 11:19:35 +02:00
|
|
|
REQUIRE(keyring != NULL);
|
2022-02-28 11:50:43 +01:00
|
|
|
REQUIRE(DNS_KASP_VALID(kasp));
|
2019-10-17 11:19:35 +02:00
|
|
|
|
|
|
|
ISC_LIST_INIT(newkeys);
|
2020-05-14 15:34:13 +02:00
|
|
|
|
2019-10-17 11:19:35 +02:00
|
|
|
*nexttime = 0;
|
|
|
|
|
|
|
|
/* Debug logging: what keys are available in the keyring? */
|
2024-08-13 18:20:26 +02:00
|
|
|
if (isc_log_wouldlog(ISC_LOG_DEBUG(1))) {
|
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));
|
2024-08-13 18:20:26 +02:00
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
|
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));
|
|
|
|
}
|
|
|
|
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*keyring, dkey, link) {
|
2019-10-17 11:19:35 +02:00
|
|
|
dst_key_format(dkey->key, keystr, sizeof(keystr));
|
2024-08-13 18:20:26 +02:00
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
|
2019-10-17 11:19:35 +02:00
|
|
|
DNS_LOGMODULE_DNSSEC, ISC_LOG_DEBUG(1),
|
2021-04-12 14:40:46 +02:00
|
|
|
"keymgr: keyring: %s (policy %s)", keystr,
|
|
|
|
dns_kasp_getname(kasp));
|
|
|
|
}
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*dnskeys, dkey, link) {
|
2021-04-12 14:40:46 +02:00
|
|
|
dst_key_format(dkey->key, keystr, sizeof(keystr));
|
2024-08-13 18:20:26 +02:00
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
|
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));
|
2019-10-17 11:19:35 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*dnskeys, dkey, link) {
|
2021-08-16 11:12:36 +02:00
|
|
|
numkeys++;
|
|
|
|
}
|
|
|
|
|
2020-02-18 16:58:56 +01:00
|
|
|
/* Do we need to remove keys? */
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*keyring, dkey, link) {
|
2020-02-18 16:58:56 +01:00
|
|
|
bool found_match = false;
|
|
|
|
|
2021-08-16 11:12:36 +02:00
|
|
|
keymgr_key_init(dkey, kasp, now, numkeys == 1);
|
2020-02-18 16:58:56 +01:00
|
|
|
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(dns_kasp_keys(kasp), kkey, link) {
|
2023-08-09 14:10:32 +02:00
|
|
|
if (dns_kasp_key_match(kkey, dkey)) {
|
2020-02-18 16:58:56 +01:00
|
|
|
found_match = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* No match, so retire unwanted retire key. */
|
|
|
|
if (!found_match) {
|
2025-03-19 17:10:25 +01:00
|
|
|
keymgr_key_retire(dkey, kasp, opts, now);
|
2020-02-18 16:58:56 +01:00
|
|
|
}
|
2021-02-08 15:15:57 +01:00
|
|
|
|
|
|
|
/* Check purge-keys interval. */
|
2025-05-22 11:23:48 +02:00
|
|
|
if (dns_keymgr_key_may_be_purged(dkey->key,
|
|
|
|
dns_kasp_purgekeys(kasp), now))
|
2022-11-02 19:33:14 +01:00
|
|
|
{
|
2021-02-08 15:15:57 +01:00
|
|
|
dst_key_format(dkey->key, keystr, sizeof(keystr));
|
2024-08-13 18:20:26 +02:00
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
|
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));
|
|
|
|
|
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);
|
2021-02-08 15:15:57 +01:00
|
|
|
dkey->purge = true;
|
|
|
|
}
|
2020-02-18 16:58:56 +01:00
|
|
|
}
|
|
|
|
|
2019-10-17 11:19:35 +02:00
|
|
|
/* Create keys according to the policy, if come in short. */
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(dns_kasp_keys(kasp), kkey, link) {
|
2019-10-17 11:19:35 +02:00
|
|
|
uint32_t lifetime = dns_kasp_key_lifetime(kkey);
|
|
|
|
dns_dnsseckey_t *active_key = NULL;
|
|
|
|
|
|
|
|
/* Do we have keys available for this kasp key? */
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*keyring, dkey, link) {
|
2023-08-09 14:10:32 +02:00
|
|
|
if (dns_kasp_key_match(kkey, dkey)) {
|
2019-10-17 11:19:35 +02:00
|
|
|
/* Found a match. */
|
2020-03-27 10:28:22 +01:00
|
|
|
dst_key_format(dkey->key, keystr,
|
|
|
|
sizeof(keystr));
|
2024-08-13 18:20:26 +02:00
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
|
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));
|
2019-10-17 11:19:35 +02:00
|
|
|
|
2024-06-24 15:14:16 +02:00
|
|
|
/* Update lifetime if changed. */
|
|
|
|
keymgr_key_update_lifetime(dkey, kasp, now,
|
|
|
|
lifetime);
|
2019-10-17 11:19:35 +02:00
|
|
|
|
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) &&
|
2025-02-25 08:40:33 +01:00
|
|
|
!dst_key_doublematch(dkey, kasp) &&
|
2020-03-27 10:28:22 +01:00
|
|
|
(dst_key_goal(dkey->key) ==
|
|
|
|
OMNIPRESENT) &&
|
2021-01-07 12:04:14 +01:00
|
|
|
!keymgr_dep(dkey->key, keyring,
|
|
|
|
NULL) &&
|
|
|
|
!keymgr_dep(active_key->key,
|
|
|
|
keyring, NULL))
|
2020-03-27 10:28:22 +01:00
|
|
|
{
|
2019-10-17 11:19:35 +02:00
|
|
|
/*
|
|
|
|
* Multiple signing keys match
|
|
|
|
* the kasp key configuration.
|
2020-03-27 10:28:22 +01:00
|
|
|
* Retire excess keys in use.
|
2019-10-17 11:19:35 +02:00
|
|
|
*/
|
2020-04-28 15:05:43 +02:00
|
|
|
keymgr_key_retire(dkey, kasp,
|
2025-03-19 17:10:25 +01:00
|
|
|
opts, now);
|
2019-10-17 11:19:35 +02:00
|
|
|
}
|
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 ||
|
2022-11-02 19:33:14 +01:00
|
|
|
dst_key_is_active(dkey->key, now))
|
|
|
|
{
|
2020-03-27 10:28:22 +01:00
|
|
|
active_key = dkey;
|
2019-10-17 11:19:35 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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.
|
|
|
|
*/
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*dnskeys, dnskey, link) {
|
2023-08-09 14:10:32 +02:00
|
|
|
if (dns_kasp_key_match(kkey, dnskey)) {
|
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));
|
2025-03-19 17:10:25 +01:00
|
|
|
opts |= DNS_KEYMGRATTR_NOROLL;
|
2021-04-12 14:40:46 +02:00
|
|
|
active_key = dnskey;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-05-14 15:34:13 +02:00
|
|
|
/* See if this key requires a rollover. */
|
2025-03-19 17:10:25 +01:00
|
|
|
RETERR(keymgr_key_rollover(
|
|
|
|
kkey, active_key, keyring, &newkeys, origin, rdclass,
|
|
|
|
kasp, keydir, lifetime, opts, now, nexttime, mctx));
|
|
|
|
|
|
|
|
opts &= ~DNS_KEYMGRATTR_NOROLL;
|
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);
|
|
|
|
}
|
|
|
|
|
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.
|
|
|
|
*/
|
2025-03-19 17:10:25 +01:00
|
|
|
if (dns_kasp_keylist_empty(kasp)) {
|
|
|
|
opts |= DNS_KEYMGRATTR_S2I;
|
|
|
|
}
|
2020-12-03 16:04:28 +01:00
|
|
|
|
2019-10-17 11:19:35 +02:00
|
|
|
/* Read to update key states. */
|
2025-07-24 11:14:16 +02:00
|
|
|
isc_result_t retval = keymgr_update(keyring, kasp, now, nexttime, opts);
|
2019-10-17 11:19:35 +02:00
|
|
|
|
|
|
|
/* Store key states and update hints. */
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*keyring, dkey, link) {
|
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;
|
2025-07-24 11:14:16 +02:00
|
|
|
retval = ISC_R_SUCCESS;
|
2023-12-22 15:08:45 +01:00
|
|
|
}
|
|
|
|
if (modified && !dkey->purge) {
|
2022-03-09 11:33:03 +01:00
|
|
|
const char *directory = dst_key_directory(dkey->key);
|
|
|
|
if (directory == NULL) {
|
|
|
|
directory = ".";
|
|
|
|
}
|
|
|
|
|
2021-02-08 15:15:57 +01:00
|
|
|
dns_dnssec_get_hints(dkey, now);
|
|
|
|
RETERR(dst_key_tofile(dkey->key, options, directory));
|
2022-03-09 11:33:03 +01:00
|
|
|
dst_key_setmodified(dkey->key, false);
|
|
|
|
|
2024-08-13 18:20:26 +02:00
|
|
|
if (!isc_log_wouldlog(ISC_LOG_DEBUG(3))) {
|
2022-03-09 11:33:03 +01:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
dst_key_format(dkey->key, keystr, sizeof(keystr));
|
2024-08-13 18:20:26 +02:00
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC,
|
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));
|
2021-02-08 15:15:57 +01:00
|
|
|
}
|
2023-12-22 15:08:45 +01:00
|
|
|
dst_key_setmodified(dkey->key, false);
|
2019-10-17 11:19:35 +02:00
|
|
|
}
|
|
|
|
|
2025-07-24 11:14:16 +02:00
|
|
|
result = retval;
|
2019-10-17 11:19:35 +02:00
|
|
|
failure:
|
2025-07-24 11:14:16 +02:00
|
|
|
if (result != ISC_R_SUCCESS && result != DNS_R_UNCHANGED) {
|
2025-05-23 13:02:22 -07:00
|
|
|
ISC_LIST_FOREACH(newkeys, newkey, link) {
|
2019-10-17 11:19:35 +02:00
|
|
|
ISC_LIST_UNLINK(newkeys, newkey, link);
|
|
|
|
INSIST(newkey->key != NULL);
|
|
|
|
dst_key_free(&newkey->key);
|
|
|
|
dns_dnsseckey_destroy(mctx, &newkey);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-08-13 18:20:26 +02:00
|
|
|
if (isc_log_wouldlog(ISC_LOG_DEBUG(3))) {
|
2022-05-03 12:28:31 +02:00
|
|
|
char namebuf[DNS_NAME_FORMATSIZE];
|
|
|
|
dns_name_format(origin, namebuf, sizeof(namebuf));
|
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);
|
2022-05-03 12:28:31 +02:00
|
|
|
}
|
2019-10-17 11:19:35 +02:00
|
|
|
return result;
|
|
|
|
}
|
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,
|
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);
|
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);
|
|
|
|
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*keyring, dkey, link) {
|
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 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;
|
|
|
|
}
|
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.
|
|
|
|
*/
|
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) {
|
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) {
|
2023-01-25 16:36:48 +01:00
|
|
|
dst_key_state_t s;
|
2020-08-24 10:05:28 +02:00
|
|
|
dst_key_settime(ksk_key->key, DST_TIME_DSPUBLISH, when);
|
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 {
|
2023-01-25 16:36:48 +01:00
|
|
|
dst_key_state_t s;
|
2020-08-24 10:05:28 +02:00
|
|
|
dst_key_settime(ksk_key->key, DST_TIME_DSDELETE, when);
|
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
|
|
|
}
|
|
|
|
|
2024-08-13 18:20:26 +02:00
|
|
|
if (isc_log_wouldlog(ISC_LOG_NOTICE)) {
|
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));
|
2024-08-13 18:20:26 +02:00
|
|
|
isc_log_write(DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_DNSSEC,
|
|
|
|
ISC_LOG_NOTICE,
|
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. */
|
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);
|
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,
|
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,
|
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
|
|
|
}
|
|
|
|
|
2024-12-12 14:40:43 +01:00
|
|
|
static isc_result_t
|
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. */
|
2024-12-12 14:40:43 +01:00
|
|
|
isc_result_t result = ISC_R_SUCCESS;
|
2020-06-18 17:07:52 +02:00
|
|
|
isc_stdtime_t when = 0;
|
2021-01-07 12:26:53 +01:00
|
|
|
dst_key_state_t state = NA;
|
2020-06-18 17:07:52 +02:00
|
|
|
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(isc_buffer_printf(buf, "%s", pre));
|
2020-06-18 17:07:52 +02:00
|
|
|
(void)dst_key_getstate(key, ks, &state);
|
2024-12-12 14:40:43 +01:00
|
|
|
isc_result_t r = dst_key_gettime(key, kt, &when);
|
2020-06-18 17:07:52 +02:00
|
|
|
if (state == RUMOURED || state == OMNIPRESENT) {
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(isc_buffer_printf(buf, "yes - since "));
|
2020-06-18 17:07:52 +02:00
|
|
|
} else if (now < when) {
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(isc_buffer_printf(buf, "no - scheduled "));
|
2020-06-18 17:07:52 +02:00
|
|
|
} else {
|
2024-12-12 14:40:43 +01:00
|
|
|
return isc_buffer_printf(buf, "no\n");
|
2020-06-18 17:07:52 +02:00
|
|
|
}
|
2024-12-12 14:40:43 +01:00
|
|
|
if (r == ISC_R_SUCCESS) {
|
2020-06-18 17:07:52 +02:00
|
|
|
isc_stdtime_tostring(when, timestr, sizeof(timestr));
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(isc_buffer_printf(buf, "%s\n", timestr));
|
2020-06-18 17:07:52 +02:00
|
|
|
}
|
2024-12-12 14:40:43 +01:00
|
|
|
|
|
|
|
failure:
|
|
|
|
return result;
|
2020-06-18 17:07:52 +02:00
|
|
|
}
|
|
|
|
|
2024-12-12 14:40:43 +01:00
|
|
|
static isc_result_t
|
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. */
|
2024-12-12 14:40:43 +01:00
|
|
|
isc_result_t result = ISC_R_SUCCESS;
|
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;
|
|
|
|
}
|
|
|
|
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(isc_buffer_printf(buf, "\n"));
|
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.
|
2024-12-12 14:40:43 +01:00
|
|
|
return ISC_R_SUCCESS;
|
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) {
|
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 "));
|
2020-06-18 17:07:52 +02:00
|
|
|
isc_stdtime_tostring(remove_time, timestr,
|
|
|
|
sizeof(timestr));
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(isc_buffer_printf(buf, "%s", timestr));
|
2020-06-18 17:07:52 +02:00
|
|
|
}
|
|
|
|
} else {
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(isc_buffer_printf(buf, " Key has been removed "
|
|
|
|
"from the zone"));
|
2020-06-18 17:07:52 +02:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
isc_stdtime_t retire_time = 0;
|
2024-12-12 14:40:43 +01:00
|
|
|
result = dst_key_gettime(key, retire, &retire_time);
|
|
|
|
if (result == ISC_R_SUCCESS) {
|
2020-06-18 17:07:52 +02:00
|
|
|
if (now < retire_time) {
|
|
|
|
if (goal == OMNIPRESENT) {
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(isc_buffer_printf(
|
|
|
|
buf, " Next rollover "
|
|
|
|
"scheduled on "));
|
2020-06-18 17:07:52 +02:00
|
|
|
retire_time = keymgr_prepublication_time(
|
2024-06-24 15:18:40 +02:00
|
|
|
dkey, kasp,
|
|
|
|
retire_time - active_time, now);
|
2020-06-18 17:07:52 +02:00
|
|
|
} else {
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(isc_buffer_printf(
|
|
|
|
buf, " Key will retire on "));
|
2020-06-18 17:07:52 +02:00
|
|
|
}
|
|
|
|
} else {
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(isc_buffer_printf(buf, " Rollover is "
|
|
|
|
"due since "));
|
2020-06-18 17:07:52 +02:00
|
|
|
}
|
|
|
|
isc_stdtime_tostring(retire_time, timestr,
|
|
|
|
sizeof(timestr));
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(isc_buffer_printf(buf, "%s", timestr));
|
2020-06-18 17:07:52 +02:00
|
|
|
} else {
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(isc_buffer_printf(buf,
|
|
|
|
" No rollover scheduled"));
|
2020-06-18 17:07:52 +02:00
|
|
|
}
|
|
|
|
}
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(isc_buffer_printf(buf, "\n"));
|
|
|
|
|
|
|
|
failure:
|
|
|
|
return result;
|
2020-06-18 17:07:52 +02:00
|
|
|
}
|
|
|
|
|
2024-12-12 14:40:43 +01:00
|
|
|
static isc_result_t
|
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;
|
2024-12-12 14:40:43 +01:00
|
|
|
isc_result_t result = ISC_R_SUCCESS;
|
2020-06-18 17:07:52 +02:00
|
|
|
|
|
|
|
(void)dst_key_getstate(key, ks, &state);
|
|
|
|
switch (state) {
|
|
|
|
case HIDDEN:
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(isc_buffer_printf(buf, " - %shidden\n", pre));
|
2020-06-18 17:07:52 +02:00
|
|
|
break;
|
|
|
|
case RUMOURED:
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(isc_buffer_printf(buf, " - %srumoured\n", pre));
|
2020-06-18 17:07:52 +02:00
|
|
|
break;
|
|
|
|
case OMNIPRESENT:
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(isc_buffer_printf(buf, " - %somnipresent\n", pre));
|
2020-06-18 17:07:52 +02:00
|
|
|
break;
|
|
|
|
case UNRETENTIVE:
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(isc_buffer_printf(buf, " - %sunretentive\n", pre));
|
2020-06-18 17:07:52 +02:00
|
|
|
break;
|
|
|
|
case NA:
|
|
|
|
default:
|
|
|
|
/* print nothing */
|
|
|
|
break;
|
|
|
|
}
|
2024-12-12 14:40:43 +01:00
|
|
|
|
|
|
|
failure:
|
|
|
|
return result;
|
2020-06-18 17:07:52 +02:00
|
|
|
}
|
|
|
|
|
2024-12-12 14:40:43 +01:00
|
|
|
isc_result_t
|
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;
|
2024-12-12 14:40:43 +01:00
|
|
|
isc_result_t result = ISC_R_SUCCESS;
|
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
|
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: "));
|
2020-06-18 17:07:52 +02:00
|
|
|
isc_stdtime_tostring(now, timestr, sizeof(timestr));
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(isc_buffer_printf(&buf, "%s\n", timestr));
|
2020-06-18 17:07:52 +02:00
|
|
|
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*keyring, dkey, link) {
|
2020-06-18 17:07:52 +02:00
|
|
|
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));
|
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)));
|
2020-06-18 17:07:52 +02:00
|
|
|
|
|
|
|
// publish status
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(keytime_status(dkey->key, now, &buf,
|
|
|
|
" published: ", DST_KEY_DNSKEY,
|
|
|
|
DST_TIME_PUBLISH));
|
2020-06-18 17:07:52 +02:00
|
|
|
|
|
|
|
// signing status
|
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));
|
2020-06-18 17:07:52 +02:00
|
|
|
}
|
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));
|
2020-06-18 17:07:52 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// rollover status
|
2024-12-12 14:40:43 +01:00
|
|
|
RETERR(rollover_status(dkey, kasp, now, &buf, zsk));
|
2020-06-18 17:07:52 +02:00
|
|
|
|
|
|
|
// key states
|
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));
|
2020-06-18 17:07:52 +02:00
|
|
|
}
|
2024-12-12 14:40:43 +01:00
|
|
|
|
|
|
|
failure:
|
|
|
|
|
|
|
|
return result;
|
2020-06-18 17:07:52 +02:00
|
|
|
}
|
2020-08-21 15:31:57 +02:00
|
|
|
|
|
|
|
isc_result_t
|
|
|
|
dns_keymgr_rollover(dns_kasp_t *kasp, dns_dnsseckeylist_t *keyring,
|
2022-03-09 11:33:03 +01:00
|
|
|
isc_stdtime_t now, isc_stdtime_t when, dns_keytag_t id,
|
2020-08-21 15:31:57 +02:00
|
|
|
unsigned int algorithm) {
|
|
|
|
int options = (DST_TYPE_PRIVATE | DST_TYPE_PUBLIC | DST_TYPE_STATE);
|
2022-03-09 11:33:03 +01:00
|
|
|
const char *directory = NULL;
|
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);
|
|
|
|
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*keyring, dkey, link) {
|
2020-08-21 15:31:57 +02:00
|
|
|
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.
|
|
|
|
*/
|
2020-09-04 11:42:52 +02:00
|
|
|
return DNS_R_TOOMANYKEYS;
|
2020-08-21 15:31:57 +02:00
|
|
|
}
|
|
|
|
key = dkey;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (key == NULL) {
|
2020-09-04 11:42:52 +02:00
|
|
|
return DNS_R_NOKEYMATCH;
|
2020-08-21 15:31:57 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
result = dst_key_gettime(key->key, DST_TIME_ACTIVATE, &active);
|
2020-08-24 10:03:02 +02:00
|
|
|
if (result != ISC_R_SUCCESS || active > now) {
|
2020-09-04 11:42:52 +02:00
|
|
|
return DNS_R_KEYNOTACTIVE;
|
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. */
|
2022-03-09 11:33:03 +01:00
|
|
|
directory = dst_key_directory(key->key);
|
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);
|
2022-05-03 12:28:31 +02:00
|
|
|
if (result == ISC_R_SUCCESS) {
|
|
|
|
dst_key_setmodified(key->key, false);
|
|
|
|
}
|
2020-08-21 15:31:57 +02:00
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
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. */
|
2025-03-20 22:25:56 -07:00
|
|
|
ISC_LIST_FOREACH(*keyring, dkey, link) {
|
2024-06-19 13:41:07 +02:00
|
|
|
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;
|
2024-09-03 11:52:19 +02:00
|
|
|
dst_key_state_t current_dnskey = HIDDEN,
|
|
|
|
current_zrrsig = HIDDEN, current_goal = HIDDEN;
|
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,
|
|
|
|
¤t_dnskey));
|
|
|
|
RETERR(dst_key_getstate(dkey->key, DST_KEY_ZRRSIG,
|
|
|
|
¤t_zrrsig));
|
|
|
|
RETERR(dst_key_getstate(dkey->key, DST_KEY_GOAL,
|
|
|
|
¤t_goal));
|
|
|
|
RETERR(dst_key_gettime(dkey->key, DST_TIME_PUBLISH,
|
|
|
|
&published));
|
|
|
|
RETERR(dst_key_gettime(dkey->key, DST_TIME_ACTIVATE, &active));
|
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);
|
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;
|
|
|
|
}
|
|
|
|
|
2024-09-03 11:52:19 +02:00
|
|
|
if (inactive > 0 && inactive <= now) {
|
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;
|
|
|
|
}
|
|
|
|
|
2024-09-03 11:52:19 +02:00
|
|
|
if (remove > 0 && remove <= now) {
|
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;
|
|
|
|
}
|