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
 * totalhours:  0 => 8


Comment:

 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)
   both of these failed so are commented out for now (nsec3 is added twice
 - 2 cases for querying for wildcard name itself (either the NODATA or the
 wildcard record itself)
 - Case for a direct query of an NSEC3 record (which should result in
 denial of existence)

 As discussed on jabber, the first two failed, and are commented out. The
 last three succeed.

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

 > '''nsec3_auth.config'''
 > - Do we need an explicit Boss (components) configuration?
 >

 We don't *need* it, but when setting it up, I just disabled all modules we
 don't need (no need to start up xfrin, xfrout, etc. for each and every
 case)

 > '''terrain/querying.py'''
 >
 > - I'd say 'response message' instead of 'response packet':
 > {{{
 > # (flags and edns_flags are both one string with all flags, in the order
 > # in which they appear in the response packet.)
 > }}}
 >

 ok, done

 > - check_last_query_section: I'm afraid it's technically not correct to
 >   convert all inputs to lower-cased:
 > {{{#!python
 >     # replace whitespace of any length by one space
 >     response_string = re.sub("[ \t]+", " ", response_string)
 >     expect = re.sub("[ \t]+", " ", step.multiline)
 > }}}
 >   e.g., RDATA of TXT RR should be considered case sensitive.  But,
 >   assuming (or hoping) we'll make these checks more reliable in
 >   future, for now I'm okay with keeping this probably with some
 >   warning comments.

 True, it was a choice between not taking the examples from the rfc as
 literally as possible, or possibly missing things such as capitalization
 of TXT rdatas. I chose the latter. It's not too hard to do the former (i
 still had to edit them in some places, uppercasing hex and baseX output
 would also not be too much work).

 If we decide we do need it, we can remove the lowercasing, and update the
 data in the scenario's, or we can even make all three conversions optional
 on a per-scenario basis.

 Added a comment to the docstring of the step.

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