[Opendnssec-user] The signer's expiry handling

[Havard Eidnes]

>> my signer managed to hit the dreaded "soamin not set" assertion 
>> sometime yesterday.
>
> My analysis so far points to that this assertion is not caused by by
> the state in tmp on disk. (Although something seems not quite right in
> the *.ixfr files you send me. I'm looking at that separately.)

That's strange, because the assertion goes away when I wipe the
contents of /var/opendnssec/tmp/ and start "from scratch".

> I can image one scenario that would cause this assertion to hit,
> though I'm not sure if it is at all possible.
>
> - The zone on the hidden master changes (e.g. a record is added) but
>   the SOA record's serial is not incremented.

That's unlikely to happen.  We have a setup which automates the
maintenance of the SOA version numbers before the name server is
signalled to reload the zone.

So if this is a precondition to your theory, I suspect it doesn't
apply in our case.

> - The signer does a XFR from the hidden master anyway. (maybe it is
>   somehow forced by the user? This is the unknown part)

1) I don't know how to signal to ods-signerd that it should do a
   zone transfer by interacting with the signer.  I only know to
   do it via "rndc notify <zonename>" on the hidden master.

2) OpenDNSSEC should behave like any slave name server: if the SOA
   version number hasn't changed, it should NEVER initiate a zone
   transfer, and at least not an incremental zone transfer.  That is,
   if it has a copy of the zone.  It should not be possible for
   OpenDNSSEC to know the old SOA version number and *not* have a copy
   of the zone(?)

> - The signer figures out the differences with the zone on disk and
>   writes this to the ixfr structure. But this diff does not contain the
>   SOA since it had not been updated. Causing soamin not to be set.
> - Later when writing the .ixfr file the assertion fires.

Also known as "lack of robustness", possibly caused by bad choices
performed earlier (initiating a zone transfer even though the SOA was
not updated).

> Do you reckon a similar scenario would apply to your situation?

I don't understand how it can.

>> So why does the signer think the zone has expired, when it was OK 
>> yesterday?  1814400 is the "relative expire time" from the SOA 
>> record, while here it's apparently used as an absolute value, which
>> is just entirely Wrong.
>
> That looks bad! We'll look in to it.

Thanks!  I suspect this has something to do with one of the files it
uses to offset the expire value is missing.  In steady-state I see
three files per zone: .axfr, .backup2, and .ixfr.  None of these
appear to be a copy of the incoming zone, all of them already contain
DNSSEC data added by OpenDNSSEC.


I think the entire "takeaway" from this set of experiences is that the
problems I'm experiencing more or less all have to do with the mode I
chose to run OpenDNSSEC in: "zone transfer in, zone transfer out",
that it's newish functionality in OpenDNSSEC (new in 1.4?), and that
it's ... not quite fully baked yet -- it appears to need a lot more
testing, bugfixing, integration, stabilization and attention.


Regards,

- Håvard