BIND 10 #1696: lettuce test for NSEC3 responses

[BIND 10 Development]

#1696: lettuce test for NSEC3 responses
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120306
  critical                           |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  6
            Defect Severity:  N/A    |           Total Hours:  8
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:11 jelte]:
 > Replying to [comment:9 jinmei]:
 > > '''general'''
 > > - considering future extensions, is it easy to share the same scenario
 > >   for in-memory and sqlite3 (or other database-based) data sources?
 > >   not requiring it be addressed in this ticket, though.
 >
 > I think we could use Outlines to 'loop' over a set of configurations if
 we want, but I haven't tried it out yet.
 >
 > http://lettuce.it/tutorial/scenario-outlines.html#tutorial-scenario-
 outlines
 >
 >
 > > - if it's not too hard, I'd like to add tests for uncovered cases (I
 > >   suspect there are some) of RFC5155 Sections 7.2.2 through 7.2.8.  We
 > >   may find some other bugs like #1701.
 > >
 >
 > Right, I've come up with 5 new tests:
 > - 2 cases where one NSEC3 covers multiple parts of the proof (closest
 enc, and wildcard match)

 This one seems to be using the same query name as the previous (non
 wildcard) test.  Is that correct?
 {{{
     #Scenario: 7.2.2 other; Name Error where one NSEC3 covers multiple
 parts of proof (wildcard)
 }}}

 > If you have any other cases I missed, let me know :)

 - Case for Section 7.2.4: no data, type DS (there's no test case for
   it, right?)
 - run-time collision, if possible (but I guess it's probably
   unrealistic)

 > > - check_last_query_section: I'm afraid it's technically not correct to
 > >   convert all inputs to lower-cased:

 > Added a comment to the docstring of the step.

 The last sentence didn't parse for me:

 {{{
     currently the checks are always case insensitive. Should we checks do
     need to be case sensitive, we can either remove it or make it
 optional.
 }}}

 Do you mean, "Should the checks do need..." or something?

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