BIND 10 #2905: buggy zone should result in SERVFAIL, not REFUSED

[BIND 10 Development]

#2905: buggy zone should result in SERVFAIL, not REFUSED
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |  jinmei
            Priority:  medium        |                       Status:
           Component:  data source   |  accepted
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130528
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  5             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 trac2905 is ready for review.

 In the end it became a bit more complicated than I originally
 expected, but hopefully it's still manageable:

 - I realized we cannot simply pass NULL to `addZone`, because it would
   create an empty node in the underlying domain tree, and for the zone
   table empty nodes cannot be found by the find() method.  So I
   introduced the concept of "empty zone", which is created a separate
   special factory method as a kind of null object.
 - At the higher level, I chose to signal the condition of "a matching
   zone is found but it's empty (broken)" through the return value
   of `ClientList::find()`, instead of throwing an exception.  This is
   because it wouldn't be so uncommon that we have this type of broken
   zones, and handling such a case via exception can be too expensive.
   As a result, I also ended up modifying the auth server code a bit.

 The branch consists of a set of relatively small changes so it covers
 this scenario as a whole.  I believe each chunk of set should be
 pretty straightforward, but there are several of them, so the branch
 may look a bit big.

 This is an overview of the changes:

 - update the `ZoneData` class to support the concept of empty zone
 - update the `ZoneTable` class to allow adding empty zone data
 - update the `ZoneWriter` class so it can catch zone loading
   exceptions internally and install empty zone data in that case.
   `ZoneWriter::load()` is also updated so the caller can get
   the loading error as a string to use for logging.
 - update `InMemoryClient` with the consideration of empty zones.
 - update `ClientList` so it will create `ZoneWriter` that would catch
   load errors internally
 - update the auth `Query` class to return SERVFAIL when it encounters
   an empty zone.

 There are some other small cleanups and updates, which should be
 straightforward.

 Proposed changelog entry:
 {{{
 617.?   [bug]           jinmei
         b10-auth now returns SERVFAIL to queries for a zone that is
         configured to be loaded in-memory but isn't due to load time
         errors (missing zone file or errors in the zone file, etc).
         Such zones were previously treated as non existent and would
         result in REFUSED or unintentional match against less specific
         zones.  The revised behavior is also compatible with BIND 9.
         (Trac #2905, git TBD)
 }}}

 Finally, while not related to this task, I'd note that the concept of
 "empty zone" would be useful when we want to support caching zone data
 for a subset of zones stored in the underlying data source while still
 recognizing all existent zones (so queries will be answered from
 either cache or the underlying data source, wherever available).
 That is, we'll be able to know whether zone exists only by accessing
 the in-memory cache (thus much faster), and do lookup in the
 underlying data source only when we know it exists but is not just
 cached.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2905#comment:5>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development