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      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => jinmei


Comment:

 > >
 > > 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)
 > }}}
 >

 ack, should've been a.w.example, fixed (the intention is that it is the
 'other' NSEC3 that is added twice here)

 > > 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?)

 added two cases; DS for just some name that exists in the zone, and direct
 DS query for an opt-out delegation.

 > - run-time collision, if possible (but I guess it's probably
 >   unrealistic)
 >

 quite :) should we come across a collision we can of course add it, but
 unless we already know of one, they tend to be quite hard to find :)

 > > > - 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?

 Actually I meant 'should we decide the checks do need'. Amended (as well
 as an extra comment that some tests need updating then).

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