BIND 10 #1587: auth::Query NSEC3 support: cleanup

[BIND 10 Development]

#1587: auth::Query NSEC3 support: cleanup
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20120221
                  Component:         |            Resolution:
  b10-auth                           |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5
Feature Depending on Ticket:  NSEC3  |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jelte):

 Another task for this ticket: we don't consistently check the results from
 findNSEC3(); in most cases we check 'matched', but not always. Also, we
 don't always check if next_proof is set when it should be. So if we would
 have a datasource that does not return the correct data, we might get
 errors like 'NULL RRset is given to addRRset()", which with a simple check
 could be 'no next_proof in result of findRRset() for NXDOMAIN case", for
 example. (Note: in both cases this will result in SERVFAIL, so there is no
 behavioural change, but IMO if we want to log this it's better to produce
 a helpful message).

 One example is the result of findNSEC3 in addNXDOMAINProofByNSEC3(), added
 in #1580; here neither 'matched' nor 'next_proof is not empty' are
 checked. But it's probably easiest to just walk through all the calls to
 findNSEC3()

 We should at least make the checking consistent (either check everywhere,
 or don't check and assume the datasource returns correct data, i
 personally prefer the former at this time) Perhaps this can be done with a
 helper function, but i'm not sure; this may lose to much context to
 produce informative errors.

 Also, we should probably check for run-time collisions (see 5155 section
 7.2.9).

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