Hi Siôn, Thank you very much for the reply. One small detail I missed in my initial post is that I have manual rollover configured for the KSKs for that policy. Does it change anything, I mean is that key still marked as compromised? It should be just regular rollover (and not emergency rollover) in that case.
Anyway I can share the configuration for that policy in a private message to help you reproduce the issue. I'm also trying to reproduce it myself and helpfully understand what exactly happened. I'm particularly interested in using Stand-by KSK for that zone for one simple reason. As a TLD zone it takes up to 48 hours to update the DS records for that zone in the root and having the the hashes for additional (Stand-by) key already in the root zone can significantly speed up the process of taking care of certain operational problems. Emil On Thu, May 22, 2014 at 10:45 AM, Siôn Lloyd <[email protected]> wrote: > Hi Emil, > > When a key is marked as compromised (i.e. you ask for an out-of-sequence > rollover) the enforcer tries to get a new key in as quickly as possible. I > would hazard a guess that because the time to get the standby ready and the > time to get a brand new key ready are the same it got confused and tried to > do both? (I'll see if I can reproduce the behaviour you saw.) > > The reason it is marked as experimental is two-fold. Firstly it gets less > testing than other code paths (sorry). Mainly though because the standby > key will be held in the same HSM as the active key we would have to assume > that a compromise of one is a compromise of both. So we felt that the > current implementation of standby keys was not really providing the extra > security that it could. > > Sion > > > On 20/05/14 15:16, Emil Natan wrote: > > Hello, > > I'm testing the KSK rollover process and got into something I fail to > understand. For my zone I have one stand-by KSK. Before starting the > rollover here is how my keys list looked: > > ods-ksmutil key list --keytype ksk -v 2> /dev/null > Keys: > Zone: Keytype: State: Date of next > transition (to): Size: Algorithm: CKA_ID: > Repository: Keytag: > tld KSK active 2015-06-07 > 18:59:50 (retire) 2048 8 a2b2155affee6c67ec546222443bb35c > Keyper 62557 > tld KSK dsready When required > (keypub) 2048 8 a0ad6883be22eb83506f6eed1ad01ab1 Keyper > 58075 > > Then I used "ods-ksmutil key rollover --zone tld --keytype KSK" to start > the KSK rollover process. Here is the keys list after that step: > > ods-ksmutil key list --keytype ksk -v 2> /dev/null > Keys: > Zone: Keytype: State: Date of next > transition (to): Size: Algorithm: CKA_ID: > Repository: Keytag: > tld KSK publish 2014-05-20 > 19:18:53 (ready) 2048 8 336a0d8ebb714fe38eff8abc3fcd9c98 > Keyper 39757 > tld KSK active 2014-05-20 > 15:13:53 (retire) 2048 8 a2b2155affee6c67ec546222443bb35c > Keyper 62557 > tld KSK keypublish 2014-05-20 > 19:18:53 (active) 2048 8 a0ad6883be22eb83506f6eed1ad01ab1 > Keyper 58075 > > Because I'm still testing and try various options, I have restarted the > ods-enforcerd process and that introduced additional KSK for that zone: > > ods-ksmutil key list --keytype ksk --zone tld -v 2> /dev/null > Keys: > Zone: Keytype: State: Date of next > transition (to): Size: Algorithm: CKA_ID: > Repository: Keytag: > tld KSK keypublish 2014-05-20 > 19:18:53 (active) 2048 8 a0ad6883be22eb83506f6eed1ad01ab1 > Keyper 58075 > tld KSK publish 2014-05-20 > 19:18:53 (ready) 2048 8 336a0d8ebb714fe38eff8abc3fcd9c98 > Keyper 39757 > tld KSK active 2014-05-20 > 15:13:53 (retire) 2048 8 a2b2155affee6c67ec546222443bb35c > Keyper 62557 > tld KSK dssub waiting for > ds-seen (dspub) 2048 8 997358542f04e0f34dcf70d47a5dc22a > Keyper 18944 > > What I do not understand is why the key with Keytag 39757 was introduced > for that zone and why with state "publish"? It looks more like a stand-by > ZSK which are introduced in "publish" state. When signing the zone 3 KSKs > are added to the DNSKEY record (62557, 58075, 39757). When creating the DS > record for that zone, hashes for the following 3 keys are created > - 62557, 18944, 58075, which actually makes sense. Just for the record, I > also have stand-by ZSK set in kasp.xml. > > The logfile first says: > May 20 15:26:02 catwoman ods-enforcerd: 1 zone(s) found on policy "TLD" > May 20 15:26:02 catwoman ods-enforcerd: No new KSKs need to be created. > May 20 15:26:02 catwoman ods-enforcerd: No new ZSKs need to be created. > May 20 15:26:02 catwoman ods-enforcerd: Purging keys... > > and then: > May 20 15:26:02 catwoman ods-enforcerd: zonelist filename set to > /usr/local/ods/etc/opendnssec/zonelist.xml. > May 20 15:26:02 catwoman ods-enforcerd: Zone tld found. > May 20 15:26:02 catwoman ods-enforcerd: Policy for tld set to TLD. > May 20 15:26:02 catwoman ods-enforcerd: Policy TLD found in DB. > May 20 15:26:02 catwoman ods-enforcerd: Config will be output to > /usr/local/ods/var/opendnssec/signconf/tld.xml. > May 20 15:26:02 catwoman ods-enforcerd: KSK key allocation for zone tld: 1 > key(s) allocated > May 20 15:26:02 catwoman ods-enforcerd: WARNING: KSK rollover for zone > 'tld' not completed as there are no keys in the 'ready' state; > ods-enforcerd will try again when it runs next > May 20 15:26:02 catwoman ods-enforcerd: No change to: > /usr/local/ods/var/opendnssec/signconf/tld.xml > May 20 15:26:02 catwoman ods-enforcerd: DSChanged > ... > > ods-ksmutil --version > opendnssec version 1.4.5 > > Any ideas what went wrong or what I'm missing? > > A comment in the configuration file states that the Stand-by feature is > experimental? Does it mean it should not be used in production environments? > > Thanks. > Emil > > > _______________________________________________ > Opendnssec-user mailing > [email protected]https://lists.opendnssec.org/mailman/listinfo/opendnssec-user > > > > _______________________________________________ > Opendnssec-user mailing list > [email protected] > https://lists.opendnssec.org/mailman/listinfo/opendnssec-user > >
_______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
