BIND 10 #506: Analysis of Wildcard Processing

[BIND 10 Development]

#506: Analysis of Wildcard Processing
-------------------------------------+-------------------------------------
                 Reporter:  stephen  |                Owner:  jinmei
                     Type:           |               Status:  reviewing
  enhancement                        |            Milestone:  A-Team-
                 Priority:  major    |  Sprint-20110209
                Component:           |           Resolution:
  b10-auth                           |            Sensitive:  0
                 Keywords:           |  Add Hours to Ticket:  0
Estimated Number of Hours:  3.0      |          Total Hours:  0
                Billable?:  1        |
                Internal?:  0        |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:6 vorner]:

 Thanks for the review.

 > I didn't check it against RFC. Should I?

 I don't think so.  But I think anyone who actually picks up
 development (sub)task, except the "getting previous node" primitive,
 should read at least Section 4.3.3 of RFC1034 (which is short).

 > It mostly makes sense, but I have few questions.
 >  - What if we add "*.example.com." and "example.com." isn't there yet?
 Do we add it? Won't it change NXDOMAIN into NXRRSET?

 Ah, good point.  We need to explicitly create a node for "example.com"
 if it doesn't yet exist.  That doesn't change the semantics about NXDOMAIN
 vs NXRRSET: the existence of *.example.com automatically implies the
 existence
 of example.com.

 >  - The wildcards are handled inside MemoryZone? Including creation of
 the names?

 Yes (at least that's what BIND 9 does).

 >  - Do we store the „I met a wild node“ on the path here? The first part
 suggest yes, but the second doesn't mention it and it seems to me looking
 at the node we got from last partial match is enough.

 Do you mean that returned node should be marked as 'wild'?  Hmm, you're
 right (it looks like not (always) the case with BIND 9 due to other
 features of its rbtdb).  On rethinking about it in our simplified
 scenario,
 we probably don't need the "I met a wild node" flag in FindState or
 invoking
 the callback at the "wild" node.

 To reject wildcard match under a zone cut, however, we should be careful
 not to perform wildcard matching if the search also indicates it has
 encountered a zone cut.

 >  - How does the case with "foo.*.example.com." work while searching? We
 will encounter "example.com." and it is wild, therefore we would like to
 search for "*.example.com.", but that one isn't there. What we do then?
 (Provided we are looking for example for "foo.bar.example.com.")

 First off, foo.bar.example.com doesn't (shouldn't) match
 foo.*.example.com.
 Adding foo.*.example.com implicitly creates *.example.com.  As for the
 existence of *.example.com node, it's done in the second bullet of
 "Loading"
 part, i.e., we explictly add *.example.com, and mark example.com as
 'wild'.
 (From re-reading it, I see it was not clear that we add *.example.com.
 thanks for pointing it out).

 >  - The task for previous primitive for RBTree should list next as well?

 No, getting the next is necessary for general non empty terminal support,
 and it's already included in #517 (the interface should be consistent,
 so this subtask should be done after #517).

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