BIND 10 #3263: RRset::addRRset(ConstRdataPtr&) does not validate RDATA against RRset's class
BIND 10 Development
do-not-reply at isc.org
Wed Dec 11 13:30:06 UTC 2013
#3263: RRset::addRRset(ConstRdataPtr&) does not validate RDATA against RRset's
class
-------------------------------------+-------------------------------------
Reporter: muks | Owner: UnAssigned
Type: | Status: new
defect | Milestone: New Tasks
Priority: | Keywords:
medium | Sensitive: 0
Component: | Sub-Project: DNS
libdns++ | Estimated Difficulty: 0
CVSS Scoring: | Total Hours: 0
Defect Severity: N/A |
Feature Depending on Ticket: |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
There are two variants of `RRset::addRRset()`:
* `BasicRRset::addRRset(const Rdata&)`
* `BasicRRset::addRRset(ConstRdataPtr&)`
Both variants need to add the Rdata into an internal
`std::vector<ConstRdataPtr>` collection.
In the case of the first variant, it has to create another `Rdata`
instance with a `ConstRdataPtr` managing it. For the second one, it simply
pushes the passed `ConstRdataPtr` into the collection.
When RDATA of a type mismatching its RR class is added to the `RRset`
using the second interface above, it will add it without any validation.
The first will fail with a `bad_cast` when it tries to create a `Rdata`
copy.
An example is adding RDATA to an RRset with `class=NONE` (such as required
by UPDATE). The first method throws. The second method passes. This needs
to be made consistent or at least documented.
Apart from handing `class=NONE` specially, we should reject RDATA that
mismatch the class/type.
--
Ticket URL: <http://bind10.isc.org/ticket/3263>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list