IXFR special cases proper handling
The current processing of incoming IXFR transfer (slave mode) is not completely correct. There are 3 corner-cases, distinguished by the type of response the slave receives, that I would like to discuss the correct behaviour for:
1. Single-SOA response with serial lower or equal than the one slave has.
Such response should indicate that the master has older zone than what the slave requested.
- Current behaviour: slave interprets it as malformed IXFR (less than 2 records) and falls back to AXFR
- Proposed behaviour: take it as a sign that slave's zone is up-to-date, resulting in no action.
Such response is definitely not malformed, it's proper answer in the aforementioned case (See RFC 1995, Section 2, §4). Question is what to do in such case. But I think no-action is safer. Master may have some issue, resulting in lower serial. If someone wants to update slave to a lower serial, he should do it by forced refresh.
2. Single-SOA response with serial higher than the serial of slave.
This response is not special in any way. I guess the IXFR transfer may be sent one-RR-per-message, so this may be precisely this case.
- Current behaviour: slave interprets it as malformed IXFR (less than 2 records) and falls back to AXFR.
- Proposed behaviour: take it as a first RR of the transfer, and wait for more. If timeout is reached, only then fall back to AXFR.
3. Normal IXFR transfer, but with first SOA having lower serial than slave has.
I think this is definitely a malformed response, because the slave sent its serial to the master. If it replied by a IXFR changes leading to an older serial, there is something wrong with the master.
- Current behaviour: slave interprets it as indication that its zone is up-to-date and ignores the transfer.
- Proposed behaviour: take it as a malformed transfer and fallback to AXFR.
The proposed solution is implemented in branch ixfr-single-soa, it's a quite simple patch.
Well, what do you say? Please comment. @jvcelak @jkadlec @dsalzman @mvavrusa