BIND 10 #1583: auth::Query NSEC3 support: Wildcard no data case

[BIND 10 Development]

#1583: auth::Query NSEC3 support: Wildcard no data case
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20120221
                  Component:         |            Resolution:
  b10-auth                           |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by kevin_tes):

 * owner:  kevin_tes => jinmei


Comment:

 Replying to [comment:13 jinmei]:
 > Replying to [comment:11 kevin_tes]:
 > > Hello,
 > >
 > > All seems ok to me.except that:
 > {{{
 > >   +        // Construct the matched wildcard name and add NSEC3 for
 it.
 > >   +        const Name wname = Name("*").concatenate(
 > >   +            qname_.split(qname_.getLabelCount() -
 result.closest_labels));
 > >   +        const ZoneFinder::FindNSEC3Result
 wresult(finder.findNSEC3(wname,
 > >   +
 false));
 > >   +        if (wresult.matched) {
 > >   +            response_.addRRset(Message::SECTION_AUTHORITY,
 > >   +
 boost::const_pointer_cast<AbstractRRset>(
 > >   +                                   wresult.closest_proof),
 dnssec_);
 > >   +        } else {
 > >   +            isc_throw(BadNSEC3, "No matching NSEC3 found for
 existing domain "
 > >   +                      << wname);
 > >            }
 > }}}
 >
 > >  Does these mean in WILDCARD_NXRRSET, there must be 3 NSEC3 RRs to
 prove this case?
 >
 > Normally, yes, as specified in 7.2.5 of RFC5155.
 >
 > > Though i have not get one example,but i think may be in some case
 next_proof equals this wresult.closest_proof.
 >
 > Good point.  That can happen if the NSEC3 that covers the next
 > closer of the closest encloser is either the NSEC3 for the closet
 > encloser or the NSEC3 for the wildcard.
 >
 > While I didn't explicitly note that in the ticket/branch, I personally
 > think we should handle such cases as more generic duplicate RR
 > suppression.  We did check duplicate NSECs because it was explicitly
 > specified in the RFC, but that should also be integrated into that
 > generic framework.  If that approach is okay I'll create a separate
 > ticket for that.
 Yes, it makes sense to create a separate ticket for this.
 All is ok to me now, please merge.

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