> 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.
Best regards,
- Håvard
_______________________________________________
Opendnssec-user mailing list
Opendnssec-user@lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
