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