> This is a very peculiar one. Data corruption in OpenDNSSEC > isn't something one experiences, but this is one. I'm very > much wondering how this come to bear. Had you a crash that > caused this one or something?
There is a slight time-correlation with me upgrading the installed package of OpenDNSSEC at the time, using a new binary: -opendnssec2-2.1.13nb3 OSS for a fast and easy DNSSEC deployment +opendnssec2-2.1.13nb4 OSS for a fast and easy DNSSEC deployment (And I've of course since re-built it from source with that patch I posted earlier.) I think that at the same time, the softhsm package was re-installed (version 2.6.1nb17, and yes, that "nb<num>" suffix is from the packaging system I'm using). The OS itself has not crashed, and this host has an, uhm, 338 days uptime at the time of writing. (Which indicates that it's probably time to re-fresh the base OS.) > This is an orphaned key, but still attached to a zone, just > that the zone is gone. So I can only see this happening when a > zone deletion had a very strange thing going on. You probably > can't find the cause back, so I'll contact you by e-mail how to > resolve this. As keys have some connections to zones that also > need cleaning, and this isn't something for the list. There's > no way a normal command line will resolve this and some DB > queries are needed. Thanks a lot, I see that other message, and just need to "man up" to doing the operation. At least I found a patch / workaround to OpenDNSSEC which allowed it to continue working even with this orphaned key present. Best regards, - Håvard _______________________________________________ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
