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