BIND 10 #1372: IXFR-out protocol handling: AXFR style IXFR

[BIND 10 Development]

#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      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:10 vorner]:

 > > Actually, I thought in this case there is even *no client* as long as
 > > the auth server does the right thing, so this bug should be a more
 > > serious thing.  That's why I thought it would make more sense to do
 > > nothing for this case (and the case of unexpected request type).  In
 > > general, I agree an internal error would result in SERVFAIL.
 > >
 > > But in this specific case I'm also okay with following the general
 > > practice if you prefer it.
 >
 > Well, what I think is, if such bad request gets to the xfrout, the auth
 server already didn't do the right thing, it handed the connection. If
 there's no client, then the answer would end up in a black hole. But if
 there's and the server forgot to inform it about the bad request (which we
 can probably expect, as it gave the handed the connection over), the
 client should be told at last something. In such case, I believe we should
 give it a SERVFAIL, as that one might mean a server bug as well as
 anything else and a server bug is exactly what happened.
 >
 > Or, is there something I don't see in this?

 Not necessarily, but I simply couldn't think of a case where these
 things happen, except, of course, due to a very stupid bug in
 b10-auth, and I thought that we should rather drop any state and
 continue (or if it's lightweight even kill it and restart) should this
 happen than trying to do anything more especially with someone via
 a network.

 In general, I personally think we shouldn't try to do too much if the
 code identifies our internal bug, while we should return SERVFAIl if
 it's a system error such as resource shortage or bad data in database
 source.

 Maybe we should discuss this as a general policy project-wide.
 For this particular case, I'd rather close this ticket faster than
 continuing the discussion (after all, this event shouldn't happen and
 wouldn't matter much in practice, until/unless we really introduce a
 bug in b10-auth).  I've created a diff to change the behavior to
 returning SERVFAIL (attaching to the ticket).  If you still prefer
 this behavior and the diff is okay, I'll introduce it and complete the
 ticket; otherwise, if you rather defer the discussion in a generic
 context, I'll complete this ticket without applying it.

 (I believe we don't have any other open issue).

-- 
Ticket URL: <https://bind10.isc.org/ticket/1372#comment:11>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development