BIND 10 #1577: implement ZoneFinder::findNSEC3 in database data source

[BIND 10 Development]

#1577: implement ZoneFinder::findNSEC3 in database data source
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  vorner
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  low    |  Sprint-20120417
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  6
Feature Depending on Ticket:  NSEC3  |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => vorner


Comment:

 Replying to [comment:14 vorner]:
 > Hello
 >
 > Replying to [comment:13 jelte]:
 > > datasrc_messages.mes:
 > > I think the example in _TRYHASH should say label count of 2, not 3.
 (or I don't understand the explanation :))
 >
 > It should be 3, as the . at the end is also a label. This is copied as
 it is
 > from in-memory, so if this is a problem, both should be fixed.
 >

 hmm, never noticed or realized we count the root label as well. We'll need
 to remember that, as not everyone does (like the labels field in RRSIGS,
 and a number of other dns implementations).

 > > It could be a bit out of scope, but we are stripping labels until
 something is found, we have a nice class for that now :) Perhaps we should
 make the hash calculator be able to handle the data from the labelsequence
 class (and then use that instead of the copying Name::split())
 >
 > OK to create a new ticket? The in-memory does the same and it should
 probably be updated too.
 >

 ok, I created #1894

 > > Btw, I think I remember some talk about basic type initialization
 using () vs = (like those unsigneds there), not sure what the outcome was,
 if any. It's not in our guidelines, and I think both are fine. Just though
 I should mention it :)
 >
 > I don't know about the talk, but I think if objects can have
 constructors with paretheses, the primitive types deserve the right to
 have them too ;-).
 >

 ok, n/m :)

 > > comment mentions that some sharing might be in order. Not sure whether
 I think it is worth the trouble, but the fake_nsec3 stuff you pulled out
 there already contains a shared function findNSEC3Check. The findNSEC3
 tests themselves could probably do something similar.
 >
 > After thinking about it, it can quite easily be extracted. I was
 thinking about
 > too complicated solutions with templates and specializations of the
 > initialization parts, but that's too heavy tool for this.

 ack, looks good.

 please merge :)

 Jelte

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