BIND 10 #534: DNAME support in MemoryZone

[BIND 10 Development]

#534: DNAME support in MemoryZone
-------------------------------------+-------------------------------------
                 Reporter:  vorner   |                Owner:  jinmei
                     Type:  task     |               Status:  reviewing
                 Priority:  major    |            Milestone:  A-Team-
                Component:  data     |  Sprint-20110209
  source                             |           Resolution:
                 Keywords:           |            Sensitive:  0
Estimated Number of Hours:  3.0      |  Add Hours to Ticket:  0
                Billable?:  1        |          Total Hours:  0
                Internal?:  0        |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Replying to [comment:6 jinmei]:
 > Okay, but I found the comment about exception guarantee should now
 better
 > be in find().  I also found the new function can/should be a const
 member
 > function.  I've made these changes locally, and am going to push them.

 Thanks.

 > I didn't worry about performance, and, in fact, my main concern was
 > clarity/complexity.  Having more variables makes the code more
 > incomprehensible because the reader needs to think about combinations
 > of possible variable states (with two variables that can be NULL or
 > non NULL, we need to consider 4 cases, and if the code (seemingly)
 > ignores some of the cases we need to think about whether such a case
 > is really impossible or whether it's overlooked, etc.).  But at the
 > same time, I agree we should use separate variables to represent
 > different things and I also agree the semantics of zonecut_node_ and
 > dname_node_ would be different to some extent (while they also have
 > similarity).  So, to me, this is a tradeoff issue.

 That's probably dependant on point of view. I examine code not by variable
 states, but by the code flow.

 Anyway, I added a comment and tried to explain the situation.

 > Actually, the only real question is about the case where we have DNAME
 > under NS, and glue under DNAME:
 >
 > {{{
 > dchild.example.com.   IN      NS      ns.dname.dchild.example.com.
 > dname.dchild.example.com. IN  DNAME   example.org.
 > ns.dname.dchild.example.com. IN       A       192.0.2.39
 > }}}
 > and when we ask for the glue in the "glue OK mode".

 That situation is explicitly forbidden by RFC 2672, there must be nothing
 under the node with DNAME and we are required by RFC to reject loading
 such data. We don't reject it yet, but I will create a task in the backlog
 to do so.

 I created a test to check it returns the DNAME, but I didn't add the
 nested glue, as it would test the code in forbidden situation and would
 not check anything more (it will return NXDOMAIN instead of wrong answer
 if it passes trough the DNAME).

 > Ack.  I wonder we might want to create the node at the creation of the
 > zone (which is what BIND 9 does).  In any valid zone that node should
 > exist and should not be deleted throughout the lifetime of the zone,
 > so we should safely be able to do so, and it's slightly more
 > efficient (and makes the code a bit simpler).

 Done.

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