"Havard Eidnes" schreef in bericht news:20141031.172405.489878262...@uninett.no...

It seems that the problem is that the SOA version number used in
the IXFR request is totally "off the wall"; I'm seeing
3180924024, which is way bigger than what's in the .xfrd-state
file (2014091709), but still "bigger" according to the serial
number arithmetic used for SOA version numbers.

Ding, found the bug which caused toe odd-looking SOA serial
number.  Someone has been running on autopilot...

xfrd_recover() in signer/src/wire/xfrd.c which restores the data
for a zone from the .xfrd-state file contains this piece of code:

               /* all ok */
...
               xfrd->soa.ttl = htonl(soa_ttl);
               xfrd->soa.serial = htonl(soa_serial);
               xfrd->soa.refresh = htonl(soa_refresh);
               xfrd->soa.retry = htonl(soa_retry);
               xfrd->soa.expire = htonl(soa_expire);
               xfrd->soa.minimum = htonl(soa_minimum);
...

Um, why the htonl() invocations?!?  This is data written to and
read from a local file, so on a little-endian machine, a byte-
swap should not be needed.

Byte-swapping the "strange" serial number:

% dc
3180924024 16op
BD990C78
q
% dc
16i
780C99BDp
2014091709
q
%

gives us back what it should have been in the first place.

And of course when I fix this bug, the byte-swapped version of
the SOA serial has already been written to the *.xfrd-state
files, forcing me to stop OpenDNSSEC, remove all the *.xfrd-state
files, and restart it.

Hopefully *that* should fix the problem permanently.

Well...

It seems that some other files in my /var/opendnssec/tmp/ also
needed removing (ixfr state files messed up?), so I stopped
OpenDNSSEC, renamed the dir and re-created it and then restarted
OpenDNSSEC.  Things seem to be back on track again.

Now I just need to write that monitoring script so that I can be
alerted if this should ever happen again -- hopefully it won't.

This might explain why we see this problem more often then others. We have a cron job that once a day stops OpenDNSSEC, makes a backup of the softhsm and opendnssec directories and databases and then restarts OpenDNSSEC. This means that each day the serial gets corrupted in our case. Sites that do not shutdown OpenDNSSEC daily, won´t see the problem that often.

_______________________________________________
Opendnssec-user mailing list
Opendnssec-user@lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user

Reply via email to