BIND 10 #2659: handle empty-nonterminal name with opt-outed NSEC3

[BIND 10 Development]

#2659: handle empty-nonterminal name with opt-outed NSEC3
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |  jinmei
            Priority:  low           |                       Status:
           Component:  b10-auth      |  accepted
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130205
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  0             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 trac2659 is ready for review.

 I've re-read the BIND 9 implementation, but was not sure how we
 introduced the difference.  Our findNSEC3 design is quite different
 from BIND 9's underlying NSEC3 API, so we probably simply missed this
 particular case.

 Anyway, fixing this itself is easy, and the branch is pretty small
 and (I believe) straightforward.

 Proposed changelog entry:
 {{{
 564.?   [bug]           jinmei
         b10-auth now returns closest encloser NSEC3 proof to queries for
         an empty non terminal derived from an Opt-Out NSEC RR, as
 clarified
         in errata 3441 for RFC5155.  Previously it regarded such case as
         broken zone and returned SERVFAIL.
         (Trac #2659, git TBD)
 }}}

 p.s. I guess a similar issue exits for empty non terminal wildcard,
 I was not sure whether but the dnsext discussion covered that topic.
 I plan to ask about it at dnsext, but in any case I suggest excluding
 it from this task; even if it was also clarified in the discussion, it
 will be highly rare in practice so it should be okay to fix it
 separately and later.

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