BIND 10 #1372: IXFR-out protocol handling: AXFR style IXFR
BIND 10 Development
do-not-reply at isc.org
Sat Nov 19 16:58:33 UTC 2011
#1372: IXFR-out protocol handling: AXFR style IXFR
-------------------------------------+-------------------------------------
Reporter: | Owner: jinmei
jinmei | Status: reviewing
Type: task | Milestone:
Priority: major | Sprint-20111122
Component: | Resolution:
xfrout | Sensitive: 0
Keywords: | Sub-Project: DNS
Defect Severity: N/A | Estimated Difficulty: 4
Feature Depending on Ticket: | Total Hours: 0
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by vorner):
* owner: UnAssigned => jinmei
Comment:
Hello
I have few notes about it:
* The `find_zone` in tests, the docstring is wrong. I don't see it
returning PARTIALMATCH anywhere.
* In the `find` method in tests, what is the different between the first
if case and the else case?
* About the tests generally, I noticed quite some code from them was
removed. Is it OK to do? Did the functionality tested disappear or did the
tests move somewhere else?
* Is it right the sign-every-nth message is gone and everything is signed
now? I'd guess so by reading the changes, is that true? If so, what was
the reason? Is it OK to do in this branch?
* This thing:
{{{#!python
# Make sure the question is valid. This should be ensured by
# the auth server, but since it's far from xfrout itself, we check
# it by ourselves. A viloation would be an internal bug, so we
# raise and stop here rather than returning a FORMERR or SERVFAIL.
}}}
Will anything at all be returned to the client, or will we just drop
the connection in such case? I believe even an internal bug requires a
SERVFAIL, doesn't it?
* You call the xfrout a „daemon“ in the log message descriptions. I
believe this might be misleading a little bit, for bind10 itself can run
in foreground and xfrout is only part of the system anyway.
* Is it OK to convert a general std::exception (like std::bad_alloc) to
isc.datasrc.Error? Shouldn't it be a generic Exception, then?
* Should it really throw in case of no diffs table? Shouldn't it say
NotImplemented or pretend there are no diffs? Who creates the table
anyway? If it's xfrin, it might mean that no diffs were stored yet just.
What will happen in this case anyway? Will it fallback to AXFR-like?
Thank you
--
Ticket URL: <http://bind10.isc.org/ticket/1372#comment:7>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list