Forced refresh fix

Fixes #303 (closed)

Sweet. Could you change the "server has newer zone" line in ixfr.c as well? Since we asked the master with a SOA query first, it must have either:

a) sent a differences that we didn't ask for (since the final SOA is older than our current) => transfer is bogus

b) very very long history (unreal) => we need to tell OP to retransfer over AXFR or do it ourselves

c) AXFR, which should be caught earlier on

If the master simply had an older zone, it would have replied with AXFR, so the log line representing a) + b) is confusing. My preference is to ignore a) (we need to check the final SOA against our current SOA), and fallback to AXFR with b). But probably anything is fine, if we log it as warning, so the OP notices.

@mvavrusa We decided not to change the way IXFR behaves in 1.6. I've already made a change to the behaviour in branch ixfr-single-soa. Please have a look at that. As for this MR, I can at least change the log message, I agree with that. But I think the check you're referring to, covers only the a) variant. I don't think b) can happen. Why would then the first SOA be older?

What should be the log message? And should it be a warning?

(I will try to simulate this by hand to find out what is the actual behaviour.)

OK, changing just the log message is fine. I'm not sure, the check is only for the starting SOA? b) could happen if the slave is down for a long time and the serial increases by more than a half of the 2^32 interval. But when I think about it, it's more of a master problem - what does it send, when the slave declares an (apparently) "newer" SOA SERIAL? I think it would only send back its SOA, and the client would falsely think its zone is newer. This problem is however indistinguishable from a decremented master SOA SERIAL. In both cases, I think it would be the better to resync over AXFR than to serve an old zone and wait for expiration.

I think the line should be a warning and maybe something like "mismatching opening SOA SERIAL (X, expected Y)" ?

Yes, the check is only for the first SOA. I just tried what it does: if Knot receives such IXFR (in which first SOA has serial lower than the one Knot has), it just ignores the transfer and DOES NOT retry with AXFR.

I will change the log message, but there's no way to tell what serial was expected.

The code in ixfr-single-soa branch takes care of this and such transfer is considered malformed, resulting in retrying with AXFR.