BIND 10 #551: wildcard handling for memory zone: find (main cases)

[BIND 10 Development]

#551: wildcard handling for memory zone: find (main cases)
-------------------------------------+-------------------------------------
                 Reporter:  jinmei   |                Owner:  jinmei
                     Type:           |               Status:  reviewing
  enhancement                        |            Milestone:  A-Team-
                 Priority:  major    |  Sprint-20110223
                Component:  data     |           Resolution:
  source                             |            Sensitive:  0
                 Keywords:           |  Add Hours to Ticket:  0
Estimated Number of Hours:  8.0      |          Total Hours:  0
                Billable?:  1        |
                Internal?:  0        |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Replying to [comment:7 jinmei]:
 >  - MemoryZoneImpl::find() now seems too big to understand.  I'd like
 >    to refactor it by (e.g) moving the PARTIALMATCH case outside the
 >    method.  But that would be beyond the scope of this ticket.  I'm
 >    okay with moving forward and leaving the refactoring to a separate
 >    task.

 OK, I'll create a task for it in the backlog.

 >  - as for the note about RRSIG:
 > {{{
 >             // TODO What about signatures? If we change the name, it
 would be
 >             // wrong anyway...
 > }}}
 >    I wouldn't worry about it for now.  My expectation is that the
 >    protocol wise consideration for wildcard + RRSIG will be naturally
 >    implemented.

 Should I remove it? It crossed my mind at the time, so I marked the place
 where the original signature is lost. I didn't really worry about it.

 > '''memory_datasrc_unittest.cc'''
 >   - shouldn't the value of gotIt be
 find_result.rrset->getRdataIterator()?
 >     if so, it makes me think the tests might not be developed with the
 >     spirit of "test driven" (i.e., starting with failures)

 It should. However, I developed it in two rounds. First, I implemented
 tests to see the wildcard RRset is returned unmodified. That did fail and
 I implemented finding it. In the second round, I modified the tests to
 check the name and content of the answer. It did fail with wrong name and
 I wasn't bothered that it doesn't fail with wrong content, because the
 content was there already because of the first round.

 >   - I guess we should generalize the RDATA check in
 >     lib/testutils/. (but that would better be deferred to a separate
 >     task)

 Another task to backlog?

 >  - emptyWildcard should check 'wild.bar.foo.example.org' doesn't match.
 >  - nestedEmptyWildcard should test match and unmatch cases:
 >    - baz.foo.*.bar.example.org (should match)
 >    - baz.foo.baz.bar.example.org (should not match)
 >    - *.foo.baz.bar.example.org (should not match)

 I take by doesn't match you mean NXDOMAIN, right? Because that fails and I
 think it should return NXRRSET, not NXDOMAIN. I reason this way:

 While the RFC recommends not having RRset with multiple * in the name, it
 doesn't forbid it. However, if we load wild.*.foo.example.org, then the
 *.foo.example.org domain exists as empty nonterminal domain. Therefore we
 should match against that one (with *=wild.bar) and return NXRRSET,
 because that domain is empty.

 Similarly with the baz.foo.baz.bar.example.org and
 *.foo.baz.bar.example.org.

 Is there a problem in the reasoning? Anyway, as BIND9 rejects loading such
 thing (as you mentioned), this explanation doesn't go against it. And the
 algorithm that you described works this way as well.

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