BIND 10 #2420: allow loading zones containing an orphan RRSIG

[BIND 10 Development]

#2420: allow loading zones containing an orphan RRSIG
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20121204
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:  data   |           Sub-Project:  DNS
  source                             |  Estimated Difficulty:  5
                   Keywords:         |           Total Hours:  0
            Defect Severity:  High   |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:13 vorner]:

 > > > I'm not sure it works with adding the RRset and RRSIG separately, as
 the
 > > > comment suggests. Won't it throw that such type is already there?

 > > Right now, this would result in an exception.  But as I noted at the
 > > beginning of this response, we'll need to be more flexible about as
 > > (advanced) part of generic zone parser/loader.  We could note that
 > > this behavior is for expected future changes if you want, but I
 > > thought it's okay to mention it at this stage.
 >
 > I think the documentation should match the behaviour as much as we can
 make it.
 > It is quite frustrating when one writes a code that should be correct by
 the
 > documentation, but it doesn't work. After all, it is said that a bug in
 > documentation is worth two in the code.

 Okay, I updated the documentation clarifying the point.

 > > > About the „tricky case“ with NSEC3 ‒ in the reality, there is no way
 to get
 > > > such RRSIG out, even if the adding was impemented, right? Wouldn't
 it be better
 > > > to just warn and ignore the RRSIG? And thinking about it, would it
 be worth
 > > > warning about the orphan RRSIGs?
 > >
 > > I actually thought about it, but again, NSEC3 and its RRSIG can be
 > > passed separately (interleaved with records of other names), so at
 > > least we cannot simply ignore such RRSIG.  Leaving a log might be
 > > okay, but a warning is probably too noisy as we cannot assume in which
 > > order the RRs are coming.
 >
 > But currently such scenario would throw anyway. I'm not saying this
 would be
 > for the long-term, since there'll be some substantial changes for
 merging
 > RRsets. I thought for now. But if you still think it is not worth it,
 then we
 > can probably leave it as it is.

 I wouldn't strongly oppose to logging it, but don't see the strong
 need for it either.  At least as long as we throw, it's effectively
 logged somewhere.  So I don't touch it for now.

 > > I think we can unify the call to destroy() and the check for memory
 > > leak in the destructor this way:
 >
 > I think this would look better.

 Updated that way.

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