BIND 10 #2503: Problem in inmem NSEC3 denial of existence handling

[BIND 10 Development]

#2503: Problem in inmem NSEC3 denial of existence handling
-------------------------------------+-------------------------------------
            Reporter:  jelte         |                        Owner:  jelte
                Type:  defect        |                       Status:
            Priority:  medium        |  reviewing
           Component:  data source   |                    Milestone:
            Keywords:                |  Sprint-20121218
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DNS           |                 CVSS Scoring:
Estimated Difficulty:  3             |              Defect Severity:  Low
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by muks):

 * owner:  muks => jelte


Comment:

 Hi Jelte

 Replying to [comment:10 jelte]:
 > Replying to [comment:6 muks]:
 > > I'm guessing the second `SOA` in the zone is also a copy-paste error.
 >
 > not related to the review or anything else in this ticket, but no, that
 was not a copy/paster error; the second SOA is part of the transfer
 protocol :)

 Aha. The zone data loader threw an exception when it hit the second SOA,
 so I thought it was a mistake. Didn't think of transfers then. :)

 > Like in 2504 I replaced the zone contents with a zone 'example.com'
 instead of my zone origin.

 Have you pushed this? I don't see it in the branch.

 > And some comments:
 > zone_data.h:
 > The new parameter (zone_name) has no doxygen description. (also, the
 parameter name is zone_name in the header, but zone_origin in the
 implementation. Not a problem in practice, but inconsistent and
 potentially confusing)

 *nod*. This happened because I blindly cut and pasted the args from the
 `ZoneData::create()` args which had this issue too. Updated both now.

 > I'm wondering if we shouldn't also test the case where the name exists
 but the type does not (in retrospect, maybe the same goes for 2504).

 Shall we do this as another ticket? It may involve code changes if there
 are bugs, and would be unrelated to this ticket.

 > Also, I think we should probably mention that this specifically fixes a
 bug in the case where the zone only contains one name (also
 retrospectively for 2504).

 I've updated the `ChangeLog` for #2504 in `master`.

 For this ticket, how about the following `ChangeLog` entry:
 {{{
 +XXX.   [bug]           muks
 +       Fixed a problem in inmem NSEC3 lookup which caused exceptions
 +       when the zone origin was not added as an explicit NSEC3 record.
 +       (Trac #2503, git ...)
 +
 }}}

 (Note that the cause for this ticket is different from the issue in
 #2504.)

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