BIND 10 #249: review: auth server can return SERVFAIL with an answer

[BIND 10 Development]

#249: review: auth server can return SERVFAIL with an answer
-------------------------+--------------------------------------------------
 Reporter:  jinmei       |        Owner:  jinmei                                        
     Type:  defect       |       Status:  reviewing                                     
 Priority:  major        |    Milestone:  05. 3rd Incremental Release: Serious Secondary
Component:  data source  |   Resolution:                                                
 Keywords:               |    Sensitive:  0                                             
-------------------------+--------------------------------------------------
Changes (by each):

  * owner:  each => jinmei


Comment:

 Replying to [comment:5 jinmei]:
 > So, do you mean you now agree exceptions are (more) natural?

 Yes, I agree; from a coding perspective, these are totally natural uses
 for exceptions.  What I was trying to say was that I originally avoided
 exceptions in the data source code because of the performance issue, and I
 wanted to make sure this isn't something we need to concern ourselves
 with.

 I'm slightly concerned about the possibility of a bug turning up in the
 future that makes it possible to trigger a servfail on purpose.  If that
 happened, then the use exceptions might make that a little more of a DoS
 vector than otherwise.  But at present I don't know any way to get a
 servfail other than "the server is crazy", so I think your reasoning is
 valid.

 I'm not sure why you want to postpone converting the other servfails to
 exceptions in another ticket, though.  As it stands, the server can fail
 with an error code *or* an exception, and only one of those is handled
 correctly in b10-auth (i.e., explicitly clearing out partial answers).
 Shouldn't we either use exceptions in every case, or else handle both
 sorts of servfail condition?

 To be clear, I'm fine with merging the branch as it is now, I just wanted
 to discuss these things.

 (One minor note:  When we get the validating resolver written, it will be
 possible to trigger a servfail by sending a query that's known not to
 validate.  We'll definitely want to use the error code method then.)

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