BIND 10 #1310: auth NSEC support: Handle WILDCARD_NXRRSET case

BIND 10 Development do-not-reply at isc.org
Sat Nov 19 02:28:52 UTC 2011


#1310: auth NSEC support: Handle WILDCARD_NXRRSET case
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  kevin_tes
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20111122
                  Component:         |            Resolution:
  b10-auth                           |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  3
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:         |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by kevin_tes):

 Replying to [comment:13 stephen]:
 > '''src/bin/auth/query.cc'''[[BR]]
 > Indentation of addWildcardNxrrsetProof() uses tabs - it should use
 spaces.
 I set my vim editor that a tabs equals four spaces,,,is it ok? Otherwise i
 'll change it.

 >
 > The first block of comments in addWildcardNxrrsetProof() do not apply to
 the immediately following statements, but to the block of statements after
 that - the one starting:
 > {{{
 > const ZoneFinder::FindResult fresult =
 > }}}
 >
 > As far as I can determine, the first "if" block:
 > {{{
 > if (nsec->getRdataCount() == 0) {
 > }}}
 > is a check that the the first NSEC RR in 3.1.3.4 - the one that proves
 there are no RRsets of the STYPE requested at the name that matched
 <SNAME, SCLASS> via wildcard expansion - is present in the "nsec" RRset.
 The reason for this check should be commented.

 good advice, i'll add it.

 >
 > Adding the NSEC RRsets to the Authority section is done via the
 construct:
 > {{{
 > if names are equal {
 >    add fresult.rrset
 > } else {
 >    add nsec
 >    add fresult.rrset
 > }
 > }}}
 > The "add fresult rrset" is common to both branches of the "if" statement
 and so can be outside it.
 >
 > If the above change is made, then part of the processing in
 addWildcardNxrrsetProof() is identical to the processing in
 addWildcardProof().  It suggests that the two could be combined: add a
 second argument to addWildcardProof() that defaults to an empty
 ConstRRsetPtr.  The code would then:
 > * add the standard wildcard NSEC record
 > * if "nsec" is not null:
 >   * test if it contains any NSEC records; if not, thrown an exception
 >   * add to the Authority section if the name is different from the
 standard wildcard record
 >
 good advice, i'll changed it.
 >
 > '''src/bin/auth/query.h'''[[BR]]
 > The header for addWildcardNxrrsetProof() should include Doxygen tags
 describing the arguments.
 >
 > Although not really part of this ticket, while addressing the above
 comment the opportunity should be taken to add Doxygen tags to the headers
 of the other "addXxx()" methods.
 >
 > The headers of these methods should be expanded to do a better
 description as to how the methods are used.  It took quite a bit of
 searching (and reading [http://tools.ietf.org/hrml/rfc4035 RFC 4035]) to
 find out how the logic worked (i.e. that addWildcardNxrrsetProof() depends
 on the fact that ZoneFinder::find() in this case - Wildcard No Data -
 returns the NSEC that covers the interval where the empty non-terminal
 lives, but not the NSEC for the wildcard demanded by
 [http://tools.ietf.org/hrml/rfc4035 RFC 4035], thus requiring the addition
 of the wildcard NSEC).
 >
 good advice,i'll fix it.
 >
 > '''src/bin/auth/tests/query_unittest.cc'''[[BR]]
 > There should be two tests: one for the case that returns two NSEC
 records, and one that returns a single NSEC record (to prove that the
 duplicate NSEC is not included in the Authority section).
 >

 say my comment http://bind10.isc.org/ticket/1310?replyto=11#comment

 but i'll fixed it.

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


More information about the bind10-tickets mailing list