[Opendnssec-user] The signer's expiry handling
he at uninett.no
Sat Dec 19 12:49:12 UTC 2015
>> 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
> 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.
Opendnssec-user mailing list
Opendnssec-user at lists.opendnssec.org
More information about the Opendnssec-user