Hi Fred, We are currently in the process of finding out why the retired ZSK after the migration gets unpublished to fast. It seems an issue in the migration script. Working on it.
This issue seems unrelated. Judging from the output the old ZSK DNSKEY is still being published in the DNSKEY set. At least what the enforcer is concerned: > Zone: Key role: DS: DNSKEY: > RRSIGDNSKEY: RRSIG: Pub: Act: Id: > KVI.nl ZSK NA hidden NA > hidden 0 0 d5104974928d9d3b962efe9cdb0d423c > KVI.nl ZSK NA omnipresent NA > unretentive 1 0 63b58e329df2a6bfa09671425146b72d > KVI.nl ZSK NA omnipresent NA > rumoured 1 1 0ef4982714ed47c4cf84c87e62c38890 > Zone: Keytype: State: Date of next transition: > Size: Algorithm: CKA_ID: Repository: KeyTag: > KVI.nl ZSK retire 2016-10-05 00:29:43 1024 > 8 d5104974928d9d3b962efe9cdb0d423c SoftHSM 30271 > KVI.nl ZSK retire 2016-10-05 00:29:43 1024 > 8 63b58e329df2a6bfa09671425146b72d SoftHSM 20904 > KVI.nl ZSK ready 2016-10-05 00:29:43 1024 > 8 0ef4982714ed47c4cf84c87e62c38890 SoftHSM 13143 Notice the "Pub" flag on key 63b58e329df2a6bfa09671425146b72d and 0ef4982714ed47c4cf84c87e62c38890. The signer should include both keys in the set. 2 things could be happening: 1) A bug in the enforcer where it outputs the wrong signconf. Please check the entry for the 63b58e329df2a6bfa09671425146b72d key in the signconf. it should have a <ZSK/> element. 2) A bug in the signer where it fails to include the DNSKEY. I find this unlikely. Since it is explicitly told to do so and this code did not see many changes for quite a while. (3) I almost don't dare to mention it: The DNSKEY is overlooked in the signed file. It looks like the above mentioned problem of the faulty migration and having no key in the 'active' is confusing? //Yuri
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
