>> 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 _______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
