BIND 10 #2165: update Message::addRRset() to be unaware of signedness
BIND 10 Development
do-not-reply at isc.org
Fri Aug 24 12:30:12 UTC 2012
#2165: update Message::addRRset() to be unaware of signedness
-------------------------------------+-------------------------------------
Reporter: | Owner: muks
jinmei | Status: reviewing
Type: task | Milestone:
Priority: | Sprint-20120904
medium | Resolution:
Component: | Sensitive: 0
libdns++ | Sub-Project: DNS
Keywords: | Estimated Difficulty: 5
Defect Severity: N/A | Total Hours: 0
Feature Depending on Ticket: |
scalable inmemory |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by vorner):
* owner: vorner => muks
Comment:
Hello
I'll answer both tickets here, I reviewed it as one diff.
Regarding style, you use `rr` as the name for an RRset in many places.
Isn't that misleading little bit? RR usually means single Resource Record.
Or is it really so the RRset contains only one?
It is not related to this ticket much, but it reminded me of the problem.
There are many calls like this:
{{{#!c++
boost::const_pointer_cast<AbstractRRset>(rrset));
}}}
This is bad, but there was some problem with some method of rrset not
being const even if it was a getter method and there was some technical
reason for it inside the implementation. I think it was related to the
signatures. Would you know by any chance if it is still a problem?
In this code, it seems to me if the RRset has no RRSIG, it is still
„stripped“. That is probably a needless work (query unittests, somewhere
below line 711):
{{{#!c++
if (found_rrset != found_domain->second.end()) {
ConstRRsetPtr rrset;
// Strip whatever signature there is in case DNSSEC is not required
// Just to make sure the Query asks for it when it is needed
if ((options & ZoneFinder::FIND_DNSSEC) != 0 &&
found_rrset->second->getRRsig()) {
rrset = found_rrset->second;
} else {
RRsetPtr noconst(new RRset(found_rrset->second->getName(),
found_rrset->second->getClass(),
found_rrset->second->getType(),
found_rrset->second->getTTL()));
for (RdataIteratorPtr
i(found_rrset->second->getRdataIterator());
!i->isLast(); i->next()) {
noconst->addRdata(i->getCurrent());
}
rrset = noconst;
}
return (createContext(options, SUCCESS, rrset));
}}}
You disabled the tests for the old API. If I leave aside the fact we still
have the API in our tree, even if it is not used (I think it is not used),
why are the files listed in EXTRA_DIST? If the test files are not
compiled, is there a reason to include them in the tarball?
The `stripRRsigs` function, should the whole (nontrivial) implementation
be in header file? And, is the ZoneFinder the best place for it? Doesn't
the function work on any RRset?
Looking at the code of `toWire(AbstractMessageRenderer, …)`, can it happen
that the real RR is not rendered, because it does not fit (64k long TXT
record, for example), but then the signatures fit, so they are included?
If so, is it OK?
Both toWire methods would probably deserve a description about what is
being returned. If I didn't read the code, I'd ask if it was number of
bytes, number of records or some status code.
This comment isn't true any more (or, it is probably true in some sense,
but still very misleading) ‒ the removed one lowers the count by 2, not 1:
{{{#!c++
// Locate the AAAA RRset and remove it; this has one RR in it.
}}}
Regarding this:
{{{#!c++
#if (0)
// Disabled by #2165. The RRSIG RRsets are no longer directly
// stored in the Message's rrsets, so the iterator will not find
// them. The expected text used in many tests are flattened,
// where the RRSIGs are inline. In other words, RRSIGs may occur
// between (expected_begin, expected_end) but not between
// (actual_begin, actual_end).
// make sure rrsets only contains expected RRsets
EXPECT_EQ(std::distance(expected_begin, expected_end),
std::distance(actual_begin, actual_end));
#endif
}}}
First, I don't like to see any code commented out without any FIXME or
TODO mark besides it (these allow for easy grepping for problems).
However, the more serious concern is, when do we fix the test to test what
it did before? Is there a ticket for it? Will it be deprecated? If not,
maybe rendering it to text, sorting both texts by lines and comparing as
strings? Would that work? Or, we need to see they are the same size, so
actually comparing only the lengths of the strings?
Thank you
--
Ticket URL: <http://bind10.isc.org/ticket/2165#comment:10>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list