BIND 10 #1758: define DatabaseAccessor to get NSEC3 (and its RRSIGs) for a given hashed name

[BIND 10 Development]

#1758: define DatabaseAccessor to get NSEC3 (and its RRSIGs) for a given hashed
name
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  vorner
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120320
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  5
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:  NSEC3  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  UnAssigned => vorner


Comment:

 This mostly looks fine, but we do need one additional thing; either the
 doc of getNSEC3Records should say that the NSEC3 record it returns is the
 one that covers (or, of course, matches) the name, or we need to have a
 findPreviousName for NSEC3 as well (to keep get() itself simpler). If this
 is part of a different ticket already then n/m :)

 And with one eye on the future, I do have another caveat;

 depending on how we will approach #1438 this interface might need to
 change.

 (dumping half-formed thought alert)
 So at some point there may be multiple nsec3 chains in the zone, one of
 which will be 'active' as defined by the NSEC3PARAM record
 - we can either provide a private member 'nsec3-params-used' that is used
 by getNSEC3Records() to know *which* nsec3 records to return (set at
 whatever time isNSEC3Signed() is set, and maybe we can do something smart
 with that in the first place)
 - the alternative is to add the nsec3params we need to the getNSEC3Records
 call (getNSEC3Records(name, params)

 In the latter case this interface will change, but since the bigger
 interface may be changed for #1438 anyway, I am not sure if and how we
 should take that into account right now. Since we had already decided to
 first get things working for 1 nsec3 chain, I think this can go in as it
 is.

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