BIND 10 #1307: auth NSEC support: Handle NXDOMAIN case

[BIND 10 Development]

#1307: auth NSEC support: Handle NXDOMAIN case
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20111025
                  Component:         |            Resolution:
  b10-auth                           |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:5 jelte]:

 Thanks for the prompt review.

 > (I've removed a little bit of whitespace in query.cc)

 Ack, thanks.

 > Not really relevant to this ticket, but just wondering, why are
 > the exceptions in query.cc structs and not classes? I know there
 > isn't that much of a difference really, but still.

 Ah...well I don't know why in this case:-) I simply copied other Query
 exception "structs" without even noticing they are structs and renamed
 it.

 Personally, when I intentionally use struct instead of class I mean
 that it's just a set of values rather than realizing some abstraction
 (and so all member variables are generally public, the default of
 struct, and as a consequence of that I don't expect any inter
 dependency between them).  I guess it's similar to what Stroustrup
 says in the C++ book: "I usually prefer to use struct for classes that
 have all data public.  I think of such classes as 'not quite proper
 types, just data structures'".

 For exception types, I'd actually use class, but for consistency I'll
 leave it for now.  (In fact, I suspect we are not so consistent about
 when to use struct instead of class throughout the source code).

 > Would we want to ensure and recheck on the query.cc level that the
 > nsecs we add actually do cover the queried name (and later, in the
 > noerror/nodata response, the type)? (if so, this could be a separate
 > ticket)

 I don't think so.  DataSourceClient::find() requires it should meet
 the requirement when it returns NXDOMAIN with an RRset.  I still added
 some validation for the things that a legitimate find() implementation
 shouldn't break, but that's basically limited to the case where the
 auth server could crash due to a buggy data source implementation.  If
 the server results in a bogus NSEC due to a buggy data source (client)
 implementation, it's embarrassing, but I'd let it happen and then fix
 the lower level implementation.  (Actually I felt even the validation
 I added for NSEC may be too much - for example, the case of a buggy
 implementation returning an empty RRset isn't specific to NSEC.  Maybe
 we'll loosen the check later.)

 > But the code looks ok, and can be merged

 Okay, will do, thanks.

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