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

[BIND 10 Development]

#249: auth server can return SERVFAIL with an answer
--------------------------+-------------------------------------------------
 Reporter:  jinmei        |        Owner:  jinmei                                        
     Type:  defect        |       Status:  new                                           
 Priority:  major         |    Milestone:  05. 3rd Incremental Release: Serious Secondary
Component:  Unclassified  |   Resolution:                                                
 Keywords:                |    Sensitive:  0                                             
--------------------------+-------------------------------------------------

Comment(by jinmei):

 branches/trac249 is ready for review.

 The proposed changelog entry is:
 {{{
   59.?  [bug]           jinmei
         lib/datasrc,bin/auth: The authoritative server could return a
         SERVFAIL with a partial answer if it finds a data source broken
         while looking for an answer.  This can happen, for example, if a
         zone that doesn't have an NS RR is configured and loaded as a
         sqlite3 data source. (Trac #249, rTBD)
 }}}

 An initial note to reviewer: to add test cases for this bug, I decided to
 fundamentally refactor the test data source mock.  So far, it hardcoded
 the test data within the method logic and was very difficult to maintain
 if you want to add data.  Ideally, this refacotring should go to a
 separate ticket, but since the bug fix itself is a pretty easy I merged
 these sets of changes in a single branch.  The refactor part of diff is
 r2272; the rest of the changes in the branch are for tests and bug fixes.

 If combining these two changes isn't acceptable please say so.

 Notes on the bug and fix themselves:

 I'd rather see this as a data source bug than an authoritative server
 issue, so I solely fixed it in the data source library.

 If a zone doesn't have an apex SOA/NS, the zone is broken (for example,
 BIND 9 refuses to load such zones.  Even our loadzone tool doesn't allow a
 no SOA zone).  So, I believe it's acceptable and even more sensible to
 throw an exception rather than making an error message.

 This observation leads to broader discussions.  First, I suspect other
 internal SERVFAIL cases should actully be changed to exceptions.  But I
 was not so sure if they are due to something like a broken database or an
 unsual, but not necessarily broken error.  So I didn't touch them.  We
 should revisit these cases, too, and, whatever the conclusion is, we
 should avoid SERVFAIL+answer for these cases.

 Second, this problem suggests we need to clarify which data is safe in the
 data source module.  In a "captive" world like BIND 9, we can basically
 assume that the data parser performs necessary validation and once the
 data is successfully loaded it's valid.  In a more open world like BIND
 10, however, we cannot naively assume that.  The data source may be "non
 captive" and bogus data may be inserted via an out-of-band interface, or
 the data source may be dynamically linked buggy implementation provided by
 a third party.

 So, in a longer term, I think we need to define a border in the top level
 data source, under which we cannot assume the validity of the data and the
 module must perform validation.  Then, other BIND 10 modules
 (specifically, the auth server) can assume it only handles valid data
 above the border line.

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