BIND 10 #2420: allow loading zones containing an orphan RRSIG
BIND 10 Development
do-not-reply at isc.org
Fri Nov 2 06:50:06 UTC 2012
#2420: allow loading zones containing an orphan RRSIG
-------------------------------------+-------------------------------------
Reporter: | Owner:
jinmei | Status: new
Type: | Milestone: Next-Sprint-
defect | Proposed
Priority: high | Resolution:
Component: data | Sensitive: 0
source | Sub-Project: DNS
Keywords: | Estimated Difficulty: 0
Defect Severity: N/A | Total Hours: 0
Feature Depending on Ticket: |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Description changed by jinmei:
Old description:
> We currently reject loading (to memory) an entire zone if we find
> an RRSIG that doesn't have a covered RRset:
>
> {{{#!cpp
> // Right now, we don't accept RRSIG without covered RRsets (this
> // should eventually allowed, but to do so we'll need to update the
> // finder).
> }}}
>
> This is overkill, and won't become realistic check anyway when we
> support the complete zone parser/loader because we cannot tell when
> the covered RRSIG is added (unless we maintain a possibly huge size of
> intermediate storage for the "orphan" RRSIGs). The behavior is also
> incompatible with BIND 9.
>
> There's also a report from a user who is suffering from this behavior,
> so I suggest we should fix it now. In terms of data structures it
> should already be possible, so it shouldn't be so difficult.
New description:
We currently reject loading (to memory) an entire zone if we find
an RRSIG that doesn't have a covered RRset:
{{{#!cpp
// Right now, we don't accept RRSIG without covered RRsets (this
// should eventually allowed, but to do so we'll need to update the
// finder).
}}}
This is overkill, and won't become realistic check anyway when we
support the complete zone parser/loader because we cannot tell when
the covered RRSIG is added (unless we maintain a possibly huge size of
intermediate storage for the "orphan" RRSIGs). The behavior is also
incompatible with BIND 9.
There's also a report from a user who is suffering from this behavior,
so I suggest we should fix it now. In terms of data structures it
should already be possible, so it shouldn't be so difficult.
See also #2273.
--
--
Ticket URL: <http://bind10.isc.org/ticket/2420#comment:1>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list