BIND 10 #1771: database datasource incorrectly rejects "on zonecut" glue

[BIND 10 Development]

#1771: database datasource incorrectly rejects "on zonecut" glue
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20120619
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:  data   |           Sub-Project:  DNS
  source                             |  Estimated Difficulty:  3
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jinmei):

 * owner:  muks => jinmei


Comment:

 Okay, on looking into it more closely, I've come up with a specific
 suggestion, implemented it in trac1771-2, and pushed it.

 My suggestion is to make it getRRsets() more dumb: it basically just
 sees whether the specified type of RR exists in the given context and
 returns it; it doesn't have to care about whether an NS and other
 type of RR coexist.

 Of course, we need to make sure that nothing on or under zone cut
 (except for the delegation information) would accidentally leak to the
 caller unless GLUE_OK is specified, but the existing code actually
 already ensures that.

 So, by making getRRsets() more dumb, the only question is whether we
 still want to catch such case explicitly and throw an exception.  This
 may be debatable, but in my personal opinion we don't have to do
 that.  Although it's a bit strange configuration and useless in
 practice (because it's hidden), it does not necessarily cause harmful
 result like ambiguity due to multiple CNAMEs.

 The initial commit ef571c2 implements this policy.  I think it's quite
 simple and straightforward.  Although we need to adjust an existing
 test case, the affected part is limited.  And, without changing any
 other part of the main implementation, the previously failing tests
 now pass.

 The rest of the branch is just for cleanup and documentation update
 (which will clarify the related issue a bit more).  But even including
 these, the entire branch should be pretty concise.

 So, in conclusion, my suggestion is to use this version of the change
 instead of current trac1771.  If we can agree that it's okay to not
 throw on seeing "NS+other", I believe this implementation is much
 simpler and easier to understand and maintain.

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