BIND 10 #1262: AXFR-style IXFR-in protocol handling

BIND 10 Development do-not-reply at isc.org
Wed Oct 5 11:31:21 UTC 2011


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

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


Comment:

 Hello

 Replying to [comment:1 jinmei]:
 > What would have to be done is to update _handle_xfrin_responses()
 > so that after calling handle_rr() if the new state is XfrinAXFR
 > switch to the existing sqlite3-specific AXFR code (which will have
 > to be adjusted a bit to support the both cases).  Of course,
 > this is intended to be a short term workaround, and the AXFR
 > part should also be integrated to the new code.  (Or if it's
 > deemed to be easy at this point, we may be able to complete that
 > part within this sprint).

 I went the new path, because it seemed less work than trying to persuade
 the generator to steal the connection in some way. It indeed turned out to
 be quite easy (after understanding the surrounding code, the new one is
 nice and easy to read, but the old one needs a cleanup).

 However, I did not modify the original AXFR code to use this new one. I'd
 like to merge this as soon as possible so we see if IXFR-in really works
 and have time to fix problems before release. If there's time, I'm not
 against doing the change in a follow-up ticket (or keeping this open after
 the merge), of course.

 Replying to [comment:3 jinmei]:
 > Assuming this is relatively an easy and small task, I'd suggest
 > adding one small feature: deciding AXFR vs IXFR.

 I'd postpone this to a follow-up ticket for the same reasons as well. That
 might be nice feature, but better have something than not having time to
 merge a whole larger branch.

 Thanks

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


More information about the bind10-tickets mailing list