[Opendnssec-user] ods-signerd: robustness & resource demands?

[Havard Eidnes]

Hi,

today we observed another problem in our OpenDNSSEC installation.  As
mentioned earlier, we run with an "axfr in, axfr out" configuration.

For our signed zones, we add a "_original-serial" TXT record, which
contains the serial number from the SOA record from the hidden master,
and we periodically run a check that what is published by our
publishing master (the name server "after" OpenDNSSEC) is publishing
the same _original-serial record which our hidden master is doing.
This thus monitors that zone data is propagating properly through our
OpenDNSSEC installation.

Today this check fired for three of our zones.  Re-updating the zone
on the hidden master (+ which automatically bumps the SOA serial and
sends a notify to OpenDNSSEC) did apparently *not* cause the updated
zone to be transferred to OpenDNSSEC, though the update was noted in
the log file, the zone which came out at the other end still had the
old _original-serial TXT record.

And then when I came to restart OpenDNSSEC the old problem with it
being unable to restart, the signer falls down over an assertion:

Oct 15 15:35:43 hugin ods-signerd: [xfrd] zone fyrkat.no request tcp/ixfr=2015101306 to 158.38.130.4
Oct 15 15:35:43 hugin ods-signerd: [xfrd] zone fyrkat.no transfer done [notify acquired 0, serial on disk 2015101500, notify serial 0]
Oct 15 15:35:50 hugin ods-signerd: signer/ixfr.c:230: part_print: assertion part->soamin failed

and I ended up having to move away all the tmp/ files in OpenDNSSEC
before it could again be successfully started.

Am I alone in having problems restarting OpenDNSSEC when it's used in
the "axfr in, axfr out" mode?

I have a copy of the old tmp/* directory contents.  Anything else I
should collect as point for information for narrowing down this
problem?  We're still running OpenDNSSEC 1.4.7.

Regards,

- Håvard