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

[Havard Eidnes]

Hi,

I'm now taking a closer look at some of the issues I reported earlier.

> 4) When I tried restarting ods-signerd and left behind the tmp/
>    directory, ods-sginerd complained about "bad ixfr journal:
>    trailing RRs after final SOA" for a lot of the journal files.
>    I've done nothing "special" -- I assume this should not happen
>    under any circumstances?

It turns out that there are *.ixfr files lying around in the old now
moved-away tmp/ directory, but that they all appear to start with no
less than *two* identical SOA records.  The second of these is, I
presume, being interpreted as the terminating SOA of a zone transfer,
and the entire zone content which follows subsequently is deemed to be
"trailing RRs after final SOA".

At the end there is also a final copy of the SOA record.

I'm guessing I'm not the only one with this lurking problem...

> 5) When I raised the FD resource limit, it then came to checking
>    the zone expirations, and it seems there's a missing
>    conversion from "relative time" (as in the SOA expire field)
>    to absolute time, as it complained e.g.:
>
>    Jul 10 15:08:52 hugin ods-signerd: [axfr] zone 39.128.in-addr.arpa expired at 3600000, and it is now 1436533732: not serving soa
>
>    One is absolute (the last one), the other is a relative
>    timestamp, and the two can't be directly compared, as appears
>    to happen here.

It looks like the tmp/ directory does not (anymore?) contain any
.xfrd-state files, therefore the "serial_xfr_acquired" used in
this computation:

    /* zone not expired? */
    if (q->zone->xfrd) {
        expire = q->zone->xfrd->serial_xfr_acquired;
        expire += ldns_rdf2native_int32(ldns_rr_rdf(rr, SE_SOA_RDATA_EXPIRE));

returns just the expire value from the SOA RR, since the other one is
zero.  Isn't the .xfrd-state files supposed to be ... "persistent"?  I
didn't do anything special to remove them, other than possibly trying
to start OpenDNSSEC a couple of times.

> 7) I moved OpenDNSSEC's tmp/ directory away, raised the FD
>    resource limit, and restarted the process pair (enforcer and
>    signer), and they're finally up and running again.

However...

4 days later, one of the zones' RRSIG validity dropped down below our
monitoring system's checking threshold, which is 2 days lower than the
configured <Refresh> period, and I had to manually intervene with

ods-signer
ods> sign --all

and the problem has not re-surfaced (so far).

Regards,

- Håvard