BIND 10 #1574: Add support for loading NSEC3 RRsets to in memory data source

[BIND 10 Development]

#1574: Add support for loading NSEC3 RRsets to in memory data source
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120207
  critical                           |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  7
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:  NSEC3  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by vorner):

 Hello

 I think a file is missing from git, because distcheck fails with:
 {{{
 make[4]: Entering directory
 `/home/vorner/work/bind10/src/lib/datasrc/tests'
 make[4]: *** No rule to make target `testdata/example.org.nsec3-signed',
 needed by `distdir'.  Stop.
 make[4]: Leaving directory
 `/home/vorner/work/bind10/src/lib/datasrc/tests'
 }}}

 and make check with this:
 {{{
 [ RUN      ] InMemoryZoneFinderTest.loadNSEC3Zone
 terminate called after throwing an instance of 'isc::dns::MasterLoadError'
  what():  Failed to open master file:
 /home/vorner/work/bind10/src/lib/datasrc/tests/testdata/example.org.nsec3-signed
 /bin/sh: line 5: 27193 Aborted                 (core dumped) ${dir}$tst
 FAIL: run_unittests_memory
 }}}

 Otherwise, I have just some nitpicking:

 Should this be "does request" instead of "doesn't"?
 {{{#!c++
         // NSEC3/NSEC3PARAM is not a "singleton" per protocol, but this
         // implementation doesn't request it be so at the moment.
 }}}

 Do it "now"?
 {{{#!c++
 // If we've not done any NSEC3 setup for the zone, do it know;
 }}}

 Could it happen we have empty origin? I mean, the zone file would not be
 valid, but it could happen, couldn't it? I think we should raise an
 exception instead of crash on assert in that situation. Or, should such
 case be rejected sooner than this? If so, a comment why this can't happen
 in practice would be nice:
 {{{#!c++
 // If the zone is NSEC3-signed, check if it has NSEC3PARAM
 if (tmp->nsec3_data_) {
     assert(!tmp->origin_data_->isEmpty());
     if (tmp->origin_data_->getData()->find(RRType::NSEC3PARAM()) ==
         tmp->origin_data_->getData()->end()) {
         LOG_WARN(logger, DATASRC_MEM_NO_NSEC3PARAM).
             arg(getOrigin()).arg(getClass());
     }
 }
 }}}

 The python documentation explicitly says there are no exceptions from the
 match method. It is true we don't have any special exceptions, but the
 common ones, like bad number of arguments or bad argument types can still
 happen.

 In both the C++ and python tests, the comment „Flags doesn't matter“
 should probably be „don't“.

 Thank you

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