> On 03/22/2018 03:13 PM, Havard Eidnes wrote: >> recently our ods-signerd crashed due to me removing a zone from >> our setup -- the crash happened 5-10 minutes later, and has been >> reported as a bug. (We're on OpenDNSSEC 1.4.13, with zone >> transfers in and out.) >> >> Following this crash I had to remove our /var/opendnssec/tmp >> directory to "start from a clean slate" (actually, I saved the >> old dir after a false start, where I saw in the log e.g. > > The tmp directory contains some vital information regarding the > current SOA serial. Unfortunate its naming is tmp still in 1.4, > but it is actually a working directory. > Because of the crash you might have had no other option to > remove its content, but this might be the cause of a subsequent > problems.
Mm, OK, I sort of guessed it; good to have it confirmed. > A future major release will actually seperate out primary SOA > serial information from the more volatile signature "tmp" > storage. OK, good. But that's not in 2.x yet, I presume? Because ... >> Mar 14 14:58:02 tilfeldigvis ods-signerd: [axfr] zone 60.39.128.in-addr.arpa >> expired at 1518409250, and it is now 1521035882: not serving soa >> (serial_xfr_acquired=1517804450, expire=604800) This sort of log entry is what scared me to move away the tmp/ contents. Not serving the zone to downstream name servers despite there not being any problems whatsoever is raising a big red flag in my view. OpenDNSSEC is severely mis-calculating the expiry of the zone file, but perhaps this is transient and is considered "normal" during startup? (I would say it's nothing but normal behaviour for a DNS name server under any circumstance.) Regards, - Håvard _______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
