BIND 10 #1279: IXFR to AXFR fallback

[BIND 10 Development]

#1279: IXFR to AXFR fallback
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  UnAssigned
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20111025
                  Component:  xfrin  |            Resolution:
                   Keywords:         |             Sensitive:  0
            Defect Severity:  N/A    |           Sub-Project:  DNS
Feature Depending on Ticket:         |  Estimated Difficulty:  5
        Add Hours to Ticket:  0      |           Total Hours:  0
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => UnAssigned
 * status:  accepted => reviewing


Comment:

 Hello

 While I see the differences between the various ways to fallback, I
 believe it's OK to implement just one.

 I've chosen the one with creating a new connection immediately. I believe
 we need a new connection, as some server might just close the connection
 after answer for IXFR (I think BIND10 does that) and some servers might
 get confused if they don't know the IXFR. And I don't see any reason to
 wait and it would only complicate matters, as we would need to keep the
 state somewhere.

 But the change contains a controversial topic. I don't care how or why the
 IXFR failed, if it failed, I just retry with AXFR. I do it for two reason.
 One is simplicity ‒ there's no need to write bunch of tests and handle a
 lot of different failure cases. Another one is, IXFR could fail in an
 unpredictable way (I've seen a bug in a server yesterday that returned
 SERVFAIL if it didn't have the differences stored). In many such cases,
 the AXFR could help, so I think it's worth at last trying (because if the
 AXFR fails as well, we wasted only few packets over one TCP connection).

 As for the zone that is not known, I think it will fall back to AXFR after
 trying to initialize the IXFR and failing even before sending anything
 out. That isn't the most elegant way to do it, but I guess it's OK, as the
 external functionality is the same, except for little logging.

 Anyway, one unrelated note. The process_xfrin function should perform some
 actions no matter if the transfer succeeds or fails (eg. decrementing the
 number of active transfers, notifying zone manager, etc), but if there's
 an unexpected exception, it does not. I think it should be put into some
 try-finally block. Should it be done right now when the code is being
 modified, or a new ticket created?

 Thanks

-- 
Ticket URL: <http://bind10.isc.org/ticket/1279#comment:5>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development