BIND 10 #1570: DS query handling in auth::Query

[BIND 10 Development]

#1570: DS query handling in auth::Query
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120221
  critical                           |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  6
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by stephen):

 * owner:  stephen => jinmei


Comment:

 >> dsBelowDelegation: although the check in this test is worthwhile, it is
 not clear why the nameserver should return a DS record when one does not
 exist.
 > I'm afraid I don't understand this comment..
 Sorry, my fault, misunderstood the contents of that test.  Ignore the
 comment.

 > In this sense, the following three are already covered in
 dsAboveDelegation and dsAboveDelegationNoData, and I don't think we need
 to explicitly reproduce the specific situations of the child zone. Is that
 acceptable for you?
 >
 >> DS record in parent but not child - DS record returned
 >> DS record in child but not in parent - nothing returned
 >> Parent and child each have a (different) DS record - DS from parent
 returned.
 OK


 >> Also, what about a test for the case of multiple DS records in the
 parent zone (as could be present in the case of a KSK rollover.)
 > I think it's out of scope of query logic tests. As long as the
 underlying data source (its find() method, specifically) handles DS as an
 RRset this should be ensured. The query logic should be able to rely on
 the abstraction of RRset.
 OK

 >> It would be helpful to explain how the case of a query for a grandchild
 zone with the server having authority for the child zone differs from the
 case of a query for the child zone with the server having authority for
 the parent.
 >I don't understand this comment...
 It was prompted by the comment above the test dsAtGrandParentAndChild,
 which says:
 {{{
 // DS query for a "grandchild" zone, and the server has authority of the
 // child zone, too.  In this case the query should be handled in the child
 // side and should result in no data with SOA.
 }}}
 The comment implies that the test is checking that a DS query to the child
 zone in a parent-child relationship is handled by the parent, a test that
 is done elsewhere.  I think the comment should be rephrased to say that
 the test is checking that the query is handled by the parent of the zone
 to which the query is directed, and not by any ancestors of the parent.

 Additional test in src/bin/auth/tests/query_unittest.cc is OK.

 Updated !ChangeLog is OK.

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