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      |
-------------------------------------+-------------------------------------

Comment (by 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.

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