BIND 10 #2267: new generateRRsetFromIterator doesn't handle RRSIGs correctly
BIND 10 Development
do-not-reply at isc.org
Tue Sep 18 17:41:20 UTC 2012
#2267: new generateRRsetFromIterator doesn't handle RRSIGs correctly
-------------------------------------+-------------------------------------
Reporter: | Owner:
jinmei | Status: new
Type: | Milestone:
defect | Sprint-20120925
Priority: | Resolution:
medium | Sensitive: 0
Component: data | Sub-Project: DNS
source | Estimated Difficulty: 6
Keywords: | Total Hours: 0
Defect Severity: N/A |
Feature Depending on Ticket: |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Description changed by jinmei:
Old description:
> The new (memory-efficient) version of in memory loader from another
> data source has a bug. It cannot load RRSIGs correctly if a single
> name has multiple types of RRsets and their RRSIGs.
>
> It can be confirmed by applying the following patch to the unit test.
> load() will fail with an exception.
>
> {{{#!diff
> const char* rrset_data[] = {
> "example.org. 3600 IN SOA ns1.example.org. bugs.x.w.example.org.
> 68 3600 300 3600000 3600",
> "a.example.org. 3600 IN A 192.168.0.1",
> + "a.example.org. 3600 IN RRSIG A 5 3 3600 20150420235959
> 20051021000000 "
> + "40430 example.org. FAKEFAKEFAKE",
> "a.example.org. 3600 IN MX 10
> mail.example.org.",
> NULL
> };
> }}}
>
> Even ignoring this bug, the current implementation doesn't seem to be
> very understandable due to the last_rrset_ member variable. It's
> quite difficult to keep track of this thing.
>
> My suggested fix is this:
>
> - simplify generateRRsetFromIterator() so it now just passes each
> RRset in the returned order.
> - implement the buffer logic in `InMemoryClientImpl::addFromLoad()`.
> it ensures a matched pair of RRset and (if signed) its RRSIG RRset
> is generated. (it can assume if the different names of RRsets aren't
> interleaved.) To implement this, it's probably better to introduce
> a helper `Loader` class.
> - revise `InMemoryClientImpl::addFromLoad()` so it takes RRset and its
> RRSIG. Then we won't need the `last_rrset_` magic.
> - `InMemoryClient::add()` (and maybe some tests) will need to be updated.
>
> Also, we should merge the older loadFromIterator test.
>
> I'd also deprecate the impl class. The in-memory client is now almost
> private itself, so the advantages of pimpl aren't that big.
New description:
The new (memory-efficient) version of in memory loader from another
data source has a bug. It cannot load RRSIGs correctly if a single
name has multiple types of RRsets and their RRSIGs.
It can be confirmed by applying the following patch to the unit test.
load() will fail with an exception.
{{{#!diff
const char* rrset_data[] = {
"example.org. 3600 IN SOA ns1.example.org. bugs.x.w.example.org. 68
3600 300 3600000 3600",
"a.example.org. 3600 IN A 192.168.0.1",
+ "a.example.org. 3600 IN RRSIG A 5 3 3600 20150420235959
20051021000000 "
+ "40430 example.org. FAKEFAKEFAKE",
"a.example.org. 3600 IN MX 10
mail.example.org.",
NULL
};
}}}
Even ignoring this bug, the current implementation doesn't seem to be
very understandable due to the last_rrset_ member variable. It's
quite difficult to keep track of this thing.
My suggested fix is this:
- simplify generateRRsetFromIterator() so it now just passes each
RRset in the returned order.
- implement the buffer logic in `InMemoryClientImpl::addFromLoad()`.
it ensures a matched pair of RRset and (if signed) its RRSIG RRset
is generated. (it can assume if the different names of RRsets aren't
interleaved.) To implement this, it's probably better to introduce
a helper `Loader` class.
- revise `InMemoryClientImpl::addFromLoad()` so it takes RRset and its
RRSIG. Then we won't need the `last_rrset_` magic.
- `InMemoryClient::add()` (and maybe some tests) will need to be updated.
Also, we should merge the older loadFromIterator test.
--
--
Ticket URL: <http://bind10.isc.org/ticket/2267#comment:4>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list